Skip to content

Canary Deployment Lifecycle

Canary Deployment is a release strategy that gradually shifts traffic from an old version (v1) to a new version (v2) to minimize the risk of introducing failures^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]. Unlike blue-green deployments, which switch traffic entirely at once, the canary approach allows for a phased rollout where the impact of new software is limited to a small subset of users initially^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

This method is often implemented using an Ingress controller, such as Nginx Ingress, which provides fine-grained traffic control mechanisms^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

Workflow

The lifecycle of a Canary Deployment can be broken down into the following steps^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]:

  1. Deployment of v1: Start the existing version (v1) of the application and bind it to the main Ingress resource, making it the only publicly accessible version^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  2. Deployment of v2: Start the new version (v2) and wait for it to become fully ready. At this stage, both v1 and v2 are running simultaneously^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  3. Traffic Splitting: Introduce a "Canary Ingress" resource configured with specific rules (e.g., weight or header matching) to divert a small percentage of traffic to the v2 service^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  4. Verification: Monitor the v2 version to ensure it functions correctly under the partial load^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  5. Migration: Once the v2 version is confirmed to be stable, update the main Ingress to point all traffic to v2 and remove the Canary Ingress configuration^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  6. Cleanup: Terminate the old v1 resources^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

Traffic Routing Strategies

Nginx Ingress supports specific annotations to control how traffic is routed to the canary version^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]. These rules are prioritized in the following order:

  1. Header-based: Traffic is diverted if a specific HTTP header matches a defined value or pattern^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  2. Cookie-based: Traffic is diverted if a specific cookie matches a defined value^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].
  3. Weight-based: A specific percentage of traffic (0-100) is diverted to the canary version^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

To enable canary-specific routing, the annotation nginx.ingress.kubernetes.io/canary: "true" must be set^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

Comparison with Blue-Green Deployment

The primary distinction between canary and blue-green deployments lies in the traffic transition model^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]. Blue-green deployments typically operate on a binary "switch" mechanism (all traffic to v1 or all to v2), whereas canary deployments allow for a smooth, partial transition between versions^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]. This smooth transition helps lower the risk of directly introducing new features to the entire user base^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md].

Sources

^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]