Install a Demo App

In this Chapter

In this chapter, you'll:

• Create a namespace myapps on each Edge Gateway cluster, and install the httpbin application
• Configure the TSB Workspace and Gateway Group needed for TSB operation
• Deploy an Gateway resource to publish the application through its local Edge Gateway

Step 1: Create the application namespace

On each cluster, perform the following steps to create and label a myapps namespace, and to deploy the httpbin application within:

kubectl config use-context aks-glbdemo01-eastus-0

kubectl create namespace myapps
kubectl label namespace myapps istio-injection=enabled

kubectl apply -n myapps -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

Step 2: Apply the TSB configuration

Create a TSB workspace that spans all Edge Gateway clusters on the myapps namespaces.

Edit the following configuration to use appropriate cluster names, and use either the tctl method or apply configuration via kubectl:

Option: Create TSB myapps-ws Workspace using tctl

cat <<EOF > tsb-myapps-configuration.yaml
apiversion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  organization: tetrate
  tenant: glbdemo01
  name: myapps-ws
spec:
  namespaceSelector:
    names:
      - "aks-glbdemo01-eastus-0/myapps"
      - "aks-glbdemo01-eastus-1/myapps"
      - "aks-glbdemo01-centralus-2/myapps"
      - "aks-glbdemo01-centralus-3/myapps"
EOF

tctl apply -f tsb-myapps-configuration.yaml

Option: Create TSB myapps-ws Workspace using kubectl (GitOps)

cat << EOF > tsb-myapps-configuration.yaml
apiVersion: tsb.tetrate.io/v2
kind: Workspace
metadata:
  name: myapps-ws
  namespace: tsb-gitops
  annotations:
    tsb.tetrate.io/organization: tetrate
    tsb.tetrate.io/tenant: glbdemo01
spec:
  namespaceSelector:
    names:
      - "aks-glbdemo01-eastus-0/myapps"
      - "aks-glbdemo01-eastus-1/myapps"
      - "aks-glbdemo01-centralus-2/myapps"
      - "aks-glbdemo01-centralus-3/myapps"
EOF

# apply in a TSB GitOps-enabled cluster
kubectl apply -f tsb-myapps-configuration.yaml

Step 3: Publish the application

Finally, we will deploy Ingress resources to publish each application through its local Ingress Gateway:

• We publish the application through the Ingress Gateway using a 'friendly' DNS name, such as httpbin.example.com
• We publish two Gateway resources, one for each Gateway Group (edge-gw-eastus and edge-gw-centralus)

Edit the following configuration to use appropriate cluster names, and use either the tctl method or apply configuration via kubectl:

Option: Publish the Application using tctl

cat <<EOF > tsb-gateways.yaml
apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
  organization: tetrate
  tenant: glbdemo01
  workspace: edge-ws
  group: edge-gw-eastus
  name: edge-ingress-eastus
spec:
  workloadSelector:
    namespace: edge
    labels:
      app: edge-gw
  http:
    - name: httpbin
      port: 80
      hostname: 'httpbin.example.com'
      routing:
        rules:
          - route:
              serviceDestination:
                host: 'myapps/httpbin.myapps.svc.cluster.local'
                port: 8000
---
apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
  organization: tetrate
  tenant: glbdemo01
  workspace: edge-ws
  group: edge-gw-centralus
  name: edge-ingress-centralus
spec:
  workloadSelector:
    namespace: edge
    labels:
      app: edge-gw
  http:
    - name: httpbin
      port: 80
      hostname: 'httpbin.example.com'
      routing:
        rules:
          - route:
              serviceDestination:
                host: 'myapps/httpbin.myapps.svc.cluster.local'
                port: 8000
EOF

tctl apply -f tsb-gateways.yaml

Option: Publish the Application using kubectl (GitOps)

cat << EOF > tsb-gw-configuration.yaml
---
apiVersion: v1
kind: List
items:
  - apiVersion: gateway.tsb.tetrate.io/v2
    kind: Gateway
    metadata:
      name: edge-ingress-eastus
      namespace: tsb-gitops
      annotations:
        tsb.tetrate.io/organization: tetrate
        tsb.tetrate.io/tenant: glbdemo01
        tsb.tetrate.io/workspace: edge-ws
        tsb.tetrate.io/gatewayGroup: edge-gw-eastus
    spec:
      workloadSelector:
        namespace: edge
        labels:
          app: edge-gw
      http:
        - name: httpbin
          port: 80
          hostname: 'httpbin.example.com'
          routing:
            rules:
              - route:
                  serviceDestination:
                    host: 'myapps/httpbin.myapps.svc.cluster.local'
                    port: 8000
  - apiVersion: gateway.tsb.tetrate.io/v2
    kind: Gateway
    metadata:
      name: edge-ingress-centralus
      namespace: tsb-gitops
      annotations:
        tsb.tetrate.io/organization: tetrate
        tsb.tetrate.io/tenant: glbdemo01
        tsb.tetrate.io/workspace: edge-ws
        tsb.tetrate.io/gatewayGroup: edge-gw-centralus
    spec:
      workloadSelector:
        namespace: edge
        labels:
          app: edge-gw
      http:
        - name: httpbin
          port: 80
          hostname: 'httpbin.example.com'
          routing:
            rules:
              - route:
                  serviceDestination:
                    host: 'myapps/httpbin.myapps.svc.cluster.local'
                    port: 8000
EOF

# apply in a TSB GitOps-enabled cluster
kubectl apply -f tsb-gw-configuration.yaml

Step 4: Test that the Application is Reachable

Verify that the httpbin service is reachable through the Ingress Gateway; repeat for each cluster to test against the public IP address:

kubectl config use-context aks-glbdemo01-eastus-0

export GATEWAY_IP=$(kubectl -n edge get service edge-gw -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")

echo $GATEWAY_IP

curl -s -v --connect-to httpbin.example.com:80:$GATEWAY_IP "http://httpbin.example.com/"

You can also test quickly against all active endpoints by looking up the global-edge-internal name as follows:

for IP in `dig +noall +answer global-edge-internal.global.example.com | cut -f 2` ; do \
    echo ... \ 
    curl -s -v -o /dev/null --connect-to httpbin.example.com:80:$IP "http://httpbin.example.com/" ; \
done

Step 5: Configure the 'friendly' DNS name

Finally, you should configure the friendly DNS name for each service published from the edge-internal gateways. The 'friendly' DNS name should be an alias to the Global Gateway name, and should match the name used in the Gateway resource above:

dig +noall +answer httpbin.example.com
# httpbin.example.com. 600 IN	CNAME	edge-internal.global.example.com.

This will allow clients in supported, routable regions to access the service via the GSLB gateways, using a simple DNS name.

IMPORTANT: It is the administrator's responsibility to ensure that:

• The friendly DNS name is aliased to the Global Gateway name;
• The service is published using a Gateway resource through each of the Edge Gateways;
• The Edge Gateways are each annotated (gslb.tetrate.io/name) with the correct name.

In normal operation, testing from the R_E_CLIENT resource group (or clients in the appropriate AWS region), we get the following response, which contains the active Edge Gateway IPs in region eastus (recall that in the RG_E_CLIENT resource group, the local.example.com Zone was linked from RG_E_DNS):

dig +noall +answer edge-internal.global.example.com

# edge-internal.global.example.com. 2 IN	CNAME	edge-internal.local.example.com.
# edge-internal.local.example.com. 2 IN	A	20.242.239.35
# edge-internal.local.example.com. 2 IN	A	20.232.235.7

We can also get a list of all healthy gateways (across all regions) by resolving the Failover Gateway name:

dig +noall +answer global-edge-internal.global.example.com

# global-edge-internal.global.example.com. 2 IN	A	20.242.239.35
# global-edge-internal.global.example.com. 2 IN	A	20.232.235.7
# global-edge-internal.global.example.com. 2 IN A	52.230.239.36
# global-edge-internal.global.example.com. 2 IN A	52.230.239.11