Add Kuar web app as another demo application

Makefile

@@ -203,6 +203,10 @@ deploy-test-apps: ## Deploy Podinfo (example app) and Apply Gslb Custom Resource
 		podinfo/podinfo \
 		--version 5.1.1
 
+.PHONY: deploy-kuar-app
+deploy-kuar-app:
+	./deploy/test-apps/kuar/deploy.sh $(CLUSTERS_NUMBER)
+
 .PHONY: upgrade-candidate
 upgrade-candidate: release-images deploy-test-version
 

README.md

@@ -106,6 +106,7 @@ Internal k8gb architecture and its components are described [here](/docs/compone
 * [AWS based deployment with Route53 integration](/docs/deploy_route53.md)
 * [AWS based deployment with NS1 integration](/docs/deploy_ns1.md)
 * [Local playground for testing and development](/docs/local.md)
+* [Local playground with Kuar web app](/docs/local-kuar.md)
 * [Metrics](/docs/metrics.md)
 * [Ingress annotations](/docs/ingress_annotations.md)
 * [Integration with Admiralty](/docs/admiralty.md)

deploy/test-apps/kuar/deploy.sh

@@ -0,0 +1,33 @@
+#!/bin/sh
+
+N=${N:-$1}
+N=${N:-2}
+UPDATE_NGINX=${UPDATE_NGINX:-1}
+DIR="${DIR:-$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )}"
+[[ ! "$N" =~ ^[0-9]{1,2}$ ]] && echo "error: Not a number: ${N}" >&2 && exit 1
+[[ "$DEBUG" == 1 ]] && set -x
+
+for c in $(seq 1 $N); do
+  echo "\nCluster ${c}:"
+  # deploy kuar app and svc
+  kubectl --context k3d-test-gslb$c -n test-gslb apply -f ${DIR}/kuar.yaml
+
+  # add custom dns server
+  DNS_IP=$(kubectl --context k3d-test-gslb$c get svc k8gb-coredns -n k8gb -o custom-columns='IP:spec.clusterIP' --no-headers)
+  kubectl --context k3d-test-gslb$c -n test-gslb patch deployment kuar \
+    -p "{\"spec\":{\"template\":{\"spec\":{\"dnsConfig\":{\"nameservers\":[\"${DNS_IP}\"]},\"dnsPolicy\":\"None\"}}}}"
+
+  if [ "$UPDATE_NGINX" == 1 ] ; then
+    # update the daemonset with nginx to use the kuar as the default backend (if no Host header is provided)
+    helm --kube-context=k3d-test-gslb$c -n k8gb upgrade -i nginx-ingress nginx-stable/ingress-nginx \
+        --version 4.0.15 -f ${DIR}/../../ingress/nginx-ingress-values.yaml \
+        --set controller.extraArgs.default-backend-service=test-gslb/kuar \
+        --set controller.extraArgs.default-server-port=8080 \
+        --wait --timeout=2m0s
+  fi
+
+  # create gslb for the app (ingress will be created)
+  kubectl --context k3d-test-gslb$c -n test-gslb apply -f ${DIR}/kuar_failover.yaml
+done
+
+echo "\n\nDone. Continue with opening http://localhost\n\n"

deploy/test-apps/kuar/kuar.yaml

@@ -0,0 +1,50 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: kuar
+  name: kuar
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: kuar
+  template:
+    metadata:
+      labels:
+        app: kuar
+    spec:
+      containers:
+      - image: gcr.io/kuar-demo/kuard-amd64:blue
+        imagePullPolicy: Always
+        name: kuar
+        ports:
+        - containerPort: 8080
+          protocol: TCP
+        livenessProbe:
+          httpGet:
+            path: /healthy
+            port: 8080
+          initialDelaySeconds: 3
+          periodSeconds: 5
+          failureThreshold: 1
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: 8080
+          initialDelaySeconds: 3
+          periodSeconds: 5
+          failureThreshold: 1
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: kuar
+  name: kuar
+spec:
+  ports:
+  - port: 8080
+  selector:
+    app: kuar

deploy/test-apps/kuar/kuar_failover.yaml

@@ -0,0 +1,22 @@
+apiVersion: k8gb.absa.oss/v1beta1
+kind: Gslb
+metadata:
+  name: kuar-failover
+  namespace: test-gslb
+spec:
+  ingress:
+    ingressClassName: nginx
+    rules:
+      - host: kuar.cloud.example.com
+        http:
+          paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: kuar
+                port:
+                  number: 8080
+  strategy:
+    type: failover
+    primaryGeoTag: eu

docs/local-kuar.md

@@ -0,0 +1,41 @@
+# Local playground with Kuar web app
+
+Kuar is a web based (SPA) application that contains a couple of handy features that can verify the k8gb functionality. It can resolve DNS names, simulate probe failures, can simulate a CPU-intensive workload by generating RSA key pairs, and also contains a simple API for the queue (push & pop strings).
+
+Make sure you have all the tools mentioned in [this section](./local.md#environment-prerequisites) installed.
+
+First, spin up two local k3s clusters:
+
+```sh
+make deploy-full-local-setup
+```
+
+Again, you can verify that everything is up and running by following [the steps here](./local.md#verify-installation).
+
+## Deploy the Kuar app
+
+```sh
+make deploy-kuar-app
+```
+
+This task will deploy Kuar into both clusters and exposes it. It also patches the installed nginx controller to serve the app even if the `Host` header is not provided in the request. This way you can access the application in your browser under http://localhost:80 for cluster 1 and http://localhost:81 for cluster 2.
+
+Make sure the app on http://localhost is responding, it may take a minute for the nginx ingress controller to restart with the correct parameters.
+
+The make target also modified the deployment of the Kuar application to use our core DNS servers. To verify that this was done, one can open the Kuar's file system browser tab and [open](http://localhost/fs/etc/resolv.conf) `/etc/resolv.conv`. It should contain the same IP as cluster-IP assigned to `k8gb-coredns` service.
+
+Together with Kuar, we also prepared the failover gslb resource for k8gb. Where the first cluster (geotag = `eu`) is the primary one.
+
+## Simulate failure
+
+Before we do that, we can visit Kuar on [cluster 2](http://localhost:81) and verify that hostname `kuar.cloud.example.com` is correctly resolved IPs corresponding to nodes in the primary cluster - which is the cluster 1. This DNS resolution will work the same way on both clusters, but we will be simulating the failure on cluster 1 soon so the web API will not respond on cluster 1.
+
+![Kuar dns resolution](/docs/images/kuar1.png)
+
+Now we can open a new tab with Kuar on cluster one and simulate the readiness probe failure for the next 10 checks - http://localhost/-/readiness.
+
+![Kuar probes](/docs/images/kuar2.png)
+
+Once we do that, the web API on cluster 1 will become unavailable. So we can switch to cluster 2 and run the web-based dig again. This time it should respond with IPs from cluster two. However, once the readiness probe will start succeeding again, it will switch back to cluster 1.
+
+![Kuar dns resolution again](/docs/images/kuar3.png)