Canary with Traffic Management using Nginx Controller

In Part 3 of Argo Rollout, we have seen the Canary deployment strategy with analysis and deployed a sample app using the Argo Rollout controller in the Kubernetes cluster. In this hands-on lab, we will be going to explore the canary deployment strategy with traffic management using the Nginx controller via deploying a sample app using the Argo Rollouts.

Traffic Management in Kubernetes

Traffic management becomes vital when discussing progressive delivery and a strategy like canary deployment. The key here is to ensure that we can correctly shift traffic to respective application versions. We want the right set of users to receive the version that was intended for them. Further, the data plane should be intelligent enough to route incoming traffic to the intended version.

Traffic routing can be achieved using multiple methods, some of the common ones being:

• Raw Routing: you mention a percentage, and that amount of users will be routed to the new version while the rest will be sent to the stable version.
• Header-based Routing: Route traffic based on certain headers sent as part of a request

When it comes to Kubernetes, it doesn’t offer any traffic management capabilities. At the most, you can create a service object that will provide you with some features but not all. That’s where service meshes come in. By using CRDs, service meshes add traffic management capabilities to Kubernetes.

Agro Rollouts come with multiple options for traffic management. It allows you to choose from a suite of service meshes. It modifies the service mesh to match the requirement of a rollout. In this hands-on lab, we’ll look into using Nginx Ingress to route traffic for our canary deployment.

Lab of Argo Rollout with Canary Deployment And Traffic Management using Nginx Controller

As we triggered the lab through the LAB SETUP button, a terminal, and an IDE comes for us which already have a Kubernetes cluster running in it. This can be checked by running the kubectl get nodes command.

• Clone the Argo Rollouts example GitHub repo or preferably, please fork this  

git clone https://github.com/NiniiGit/argo-rollouts-example.git

• Install Helm3as it would be needed later during the demo

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
helm version

Installation of Argo Rollouts controller

• Create the namespace for installation of the Argo Rollouts controller and Install the Argo Rollout through the below command, more about the installation can be found here.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

You will see that the controller and other components have been deployed. Wait for the pods to be in the Running state.

kubectl get all -n argo-rollouts

• Install Argo Rollouts Kubectl plugin with curl for easy interaction with Rollout controller and resources.

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
kubectl argo rollouts version

• Argo Rollouts comes with its own GUI as well that you can access with the below command

kubectl argo rollouts dashboard

and now by clicking on the available argo-rollout-app URL  on the right side under the LAB-URLs section.

you would be presented with UI as shown below(currently it won’t show you anything since we are yet to deploy any Argo Rollouts based app)

Now, let’s go ahead and deploy the sample app using the Canary Deployment strategy and traffic management using nginx controller.

Canary Deployment And Traffic Management With Argo Rollouts

You must be wondering how we should test internally if my canary or blue-green version of service is really working and handling traffic i.e client requests well or not before we release it as a beta feature or subsequently to a larger audience.

For this, we would play around with using Nginx-controller and passing additional header values with our client requests, which would make sure that all our client requests would always route to the canary version of our sample Nginx service.  

We have created a sample Nginx service which is wrapped up as a helm chart and available inside the folder argo-traffic-management-demo which you will find in the cloned repo.

• We will be running this demo in ic-demo namespace, so lets create the same namespace

kubectl create ns ic-demo

• Before deploying the helm chart; Let’s update the ingress controller hostname value in values.yaml. Please access the OPEN IDE, which will open the VS code-like editor in another tab, and then access the argo-traffic-management-demo/values.yaml file.

Update the below entry:

• Deploy the helm chart, which will eventually  create all the necessary Kubernetes objects in ic-demo namespace

cd argo-rollouts-example
helm install demo-nginx -n ic-demo ./argo-traffic-management-demo

• Verify the deployment status by running the following.

helm list -n ic-demo

• Now, you can check the status of your rollouts using the following command.

kubectl argo rollouts get rollout demo-nginx -n ic-demo

• If you look at the above command output, you can see the rollout object has been created with the given replicas (1). Since this is the first revision, there will not be any canary ReplicaSet. Now you can update the image tag in values.yaml and run a helm upgrade to update the rollout object.

Please access the OPEN IDE, which will open the VS code like editor in another tab and then access the argo-traffic-management-demo/values.yaml file and update the image tag from the existing 1.19.1 to 1.20.0 as shown below:  

• Now, let’s run a helm upgrade to update the rollout object

cd argo-rollouts-example
helm upgrade demo-nginx -n ic-demo ./argo-traffic-management-demo

• Now watch the rollout object status

kubectl argo rollouts get rollout demo-nginx -n ic-demo

You should be able to see something like the stable and canary sections . A new replica set has been created for the new canary pods.

Now please access the OPEN IDE, which will open the VS code like editor in another tab, and then access splitted terminal.

Now in one of the terminals, run the below command, which will tail live logs of pods running as canary service. Replace <canary-pod-name> with your canary pod name.

kubectl logs -f <canary-pod-name> -n ic-demo

Now in another terminal, access the app URL using the exposed ingress URL and pass the custom header values. Replace <your-host-name> with the hostname of the URL.

curl -H "canary: yep" -IL http://<your-host-name>/helloe/jsbdsdsd.html

you would be able to see our curl request (which we are mimicking as a client request) are always landing on our canary version of service only as shown below screenshot:

• Now, you need to promote the rollout object after manual verification

kubectl argo rollouts promote demo-nginx -n ic-demo

• Now let’s delete this test setup

helm delete demo-nginx -n ic-demo

Conclusion

In this blog, we saw how we could add traffic management capabilities to Argo Rollouts using Nginx ingress. Achieving canary deployment using fine-grained traffic management capabilities with Argo Rollouts is simple and provides much better-automated control on rolling out a new version of your application.

What Next?

That brings us to the end of the 4 part series around Progressive Delivery with Argo Rollouts. We explored the basics of deployment strategies, followed by hands-on examples of using blue-green & canary rollouts. We also looked into complex concepts like Analysis with canary deployments and finally ended with traffic management using Nginx Ingress.

You can find all the parts of this Argo Rollouts Series below:

• Part 1: Progressive Delivery With Argo Rollouts: Blue-Green Deployment
• Part 2: Progressive Delivery With Argo Rollouts: Canary Deployment
• Part 3: Progressive Delivery With Argo Rollouts: Canary with Analysis
• Part 4: Progressive Delivery With Argo Rollouts: Canary & Traffic Management

References and further reading:

• Argo Rollouts
• Kubernetes Bangalore workshop on Argo Rollouts
• Argo Rollouts – Kubernetes Progressive Delivery Controller
• CICD with Argo