Testing traffic routing

In the real world, canary deployments are regularly used to release a feature to a subset of users. In this scenario, we are artificially routing 75% of traffic to the new version of the checkout service. Completing the checkout procedure multiple times with different objects in the cart should present the users with the 2 version of the application.

First lets use Kubernetes exec to check that the Lattice service URL works from the UI pod. We'll obtain this from an annotation on the HTTPRoute resource:

~$export CHECKOUT_ROUTE_DNS="http://$(kubectl get httproute checkoutroute -n checkout -o json | jq -r '.metadata.annotations["application-networking.k8s.aws/lattice-assigned-domain-name"]')"

~$echo "Checkout Lattice DNS is $CHECKOUT_ROUTE_DNS"

~$POD_NAME=$(kubectl -n ui get pods -o jsonpath='{.items[0].metadata.name}')

~$kubectl exec $POD_NAME -n ui -- curl -s $CHECKOUT_ROUTE_DNS/health

{"status":"ok","info":{},"error":{},"details":{}}

Now we have to point the UI service to the VPC Lattice service endpoint by patching the ConfigMap for the UI component:

Kustomize Patch
ConfigMap/ui
Diff

~/environment/eks-workshop/modules/networking/vpc-lattice/ui/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: ui
  namespace: ui
data:
  ENDPOINTS_CHECKOUT: "${CHECKOUT_ROUTE_DNS}"

apiVersion: v1
data:
  ENDPOINTS_ASSETS: http://assets.assets.svc:80
  ENDPOINTS_CARTS: http://carts.carts.svc:80
  ENDPOINTS_CATALOG: http://catalog.catalog.svc:80
  ENDPOINTS_CHECKOUT: ${CHECKOUT_ROUTE_DNS}
  ENDPOINTS_ORDERS: http://orders.orders.svc:80
kind: ConfigMap
metadata:
  name: ui
  namespace: ui

 data:
   ENDPOINTS_ASSETS: http://assets.assets.svc:80
   ENDPOINTS_CARTS: http://carts.carts.svc:80
   ENDPOINTS_CATALOG: http://catalog.catalog.svc:80
-  ENDPOINTS_CHECKOUT: http://checkout.checkout.svc:80
+  ENDPOINTS_CHECKOUT: ${CHECKOUT_ROUTE_DNS}
   ENDPOINTS_ORDERS: http://orders.orders.svc:80
 kind: ConfigMap
 metadata:
   name: ui

Make this configuration change:

~$kubectl kustomize ~/environment/eks-workshop/modules/networking/vpc-lattice/ui/ \

| envsubst | kubectl apply -f -

Let's ensure that the UI pods are restarted and then port-forward to the preview of your application with Cloud9.

~$kubectl rollout restart deployment/ui -n ui

~$kubectl rollout status deployment/ui -n ui

Let us try to access our application using the browser. A LoadBalancer type service named ui-nlb is provisioned in the ui namespace from which the application's UI can be accessed.

~$kubectl get service -n ui ui-nlb -o jsonpath='{.status.loadBalancer.ingress[*].hostname}{"\n"}'

k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com

Access this in your browser and try to checkout multiple times (with different items in the cart):

Example Checkout

You'll notice that the checkout now uses the "Lattice checkout" pods about 75% of the time:

Lattice Checkout