Effortless Robust Canary Deployment on Kubernetes with Nginx Ingress Controller

John Abhilash

Canary deployments are a powerful technique for safely rolling out new versions of applications in production. They allow you to gradually release the new version to a small subset of users, monitor its performance, and then roll it out to the rest of your users if everything is working as expected.

Canary deployments can be implemented on Kubernetes using a variety of tools and techniques. One popular approach is to use Nginx Ingress Controller. Nginx Ingress Controller is a load balancer for Kubernetes that can be used to route traffic to different versions of your application.

To implement a canary deployment on Kubernetes with Nginx Ingress Controller, you will need to:

Create a deployment for the new version of your application.
Create a service for the new version of your application.
Create an Ingress rule for the new version of your application.
Deploy the new version of your application.
Monitor the canary deployment.

In the following sections, we will explain each line of the canary deployment on Kubernetes with Nginx Ingress Controller

1.Create a deployment for the new version of your application:

The first step is to create a deployment for the new version of your application. This deployment will be used to run the new version of your application in a canary environment.

Here is an example deployment manifest for an Nginx application:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: canary
  template:
    metadata:
      labels:
        app: nginx
        version: canary
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

This deployment will create a single pod running the latest version of the Nginx image.

2.Create a service for the new version of your application:

Next, you need to create a service for the new version of your application. This service will be used to expose the new version of your application to the rest of your cluster.

Here is an example service manifest for an Nginx application:

YAML

apiVersion: v1
kind: Service
metadata:
  name: nginx-canary
spec:
  selector:
    app: nginx
    version: canary
  ports:
  - port: 80
    targetPort: 80

This service will expose the new version of your application on port 80.

3.Create an Ingress rule for the new version of your application:

Finally, you need to create an Ingress rule for the new version of your application. This Ingress rule will be used to route traffic to the new version of your application.

Here is an example Ingress rule manifest for an Nginx application:

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
  - host: nginx.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-canary
            port: 80

This Ingress rule will route all traffic to the nginx-canary service, which will expose the new version of your application.

4.Deploy the new version of your application:

Once you have created the deployment, service, and Ingress rule for the new version of your application, you can deploy the new version by creating a new pod annotation.

Here is an example command to create a pod annotation that will deploy the new version of your application:

Bash

kubectl annotate pod nginx-deployment version=canary

This command will add a version=canary annotation to the nginx-deployment pod. The Ingress controller will use this annotation to route traffic to the nginx-canary service.

5.Monitor the canary deployment:

Once you have deployed the canary version of your application, you need to monitor its performance to ensure that it is working as expected. You can use metrics such as CPU and memory usage, error rates, and response times to monitor the performance of the canary version.

If the canary version of your application is working as expected, you can roll it out to the rest of your users. To do this, you can remove the version=canary annotation from the nginx-deployment pod.

Scaling the canary deployment:

Once you have deployed the canary version of your application, you may want to scale it up or down to see how it performs under different load conditions. You can use the Kubernetes HorizontalPodAutoscaler (HPA) to automatically scale the canary deployment based on CPU or memory usage.

To do this, you will need to create a HorizontalPodAutoscaler manifest. The following is an example manifest for an Nginx application:

YAML

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-canary
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-canary
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

This HPA will scale the canary deployment up to 10 replicas if the CPU usage of the canary deployment reaches 80%.

- Rolling back the canary deployment:

If you are not satisfied with the performance of the canary version of your application, you can roll it back to the previous version. To do this, you can remove the version=canary annotation from the nginx-deployment pod.

- Using a canary testing tool:

There are a number of canary testing tools available that can help you to automate the canary deployment process and monitor the performance of the canary version of your application. One popular canary testing tool is CanaryKit.

CanaryKit can help you to:

* Create and manage canary deployments.
* Monitor the performance of canary deployments.
* Roll back canary deployments if necessary.

By using a canary testing tool, you can make it easier to implement and manage canary deployments on Kubernetes.

If you are looking for an easy way to manage and automate your cloud infrastructure, Sailor Cloud is a good option to consider. To learn more about Sailor Cloud, please visit the Sailor Cloud website: https://www.sailorcloud.io/