25 ‐ Deployments Types - CloudScope/DevOpsWithCloudScope GitHub Wiki

What is a Canary Deployment?

A Canary Deployment is a release strategy where new software versions are deployed incrementally to a small subset of users or servers before being rolled out to the entire infrastructure. This allows for real-time testing in a production environment, enabling monitoring of the release’s performance and the ability to easily rollback if necessary.

Example Scenario:

Consider an e-commerce website that wants to deploy a new feature allowing users to submit product reviews. The team uses a Canary Deployment strategy to:

  1. Deploy the new version on a small set of servers, routing only a small percentage of user traffic to it.
  2. Monitor the behavior of the new version, focusing on performance, stability, and user feedback.
  3. Gradually increase traffic to the new version if it performs well.
  4. Rollback quickly if any issues arise to minimize the impact on users.

How to Use Canary Deployment in Kubernetes

  1. Define Deployment Strategy:
    • Create a Kubernetes Deployment manifest for both the stable and canary versions, specifying the number of replicas and other deployment settings.
  2. Implement Traffic Splitting:
    • Use a service mesh like Istio or an Ingress controller to split traffic between the stable and canary deployments, often using weighted routing.
  3. Monitor Metrics:
    • Set up monitoring tools to collect performance, resource usage, and behavior data for both versions of the application.
  4. Gradually Increase Traffic:
    • Start by routing a small percentage of traffic (e.g., 5% or 10%) to the canary version. Gradually increase the traffic as performance improves.
  5. Evaluate and Iterate:
    • Analyze the metrics and user feedback to evaluate the performance of the canary deployment. Adjust the traffic distribution accordingly.
  6. Rollback or Promotion:
    • If issues are detected, rollback the canary deployment. If the canary deployment performs well, promote it to the stable version.
  7. Cleanup and Repeat:
    • After completing or rolling back the deployment, clean up unused resources and repeat for future updates.

Kubernetes Request Flow in Canary Deployment

In a Canary deployment, selectors and labels are used to differentiate between stable and canary versions.

  1. Deployment: Use labels and selectors to distinguish between the stable and canary versions of your application.
  2. Service: A Kubernetes Service abstracts pod addresses and routes traffic based on the defined rules.
  3. Ingress: Configure the Ingress resource to direct traffic to the canary or stable deployments based on set criteria (e.g., path, hostname).

Example Configuration:

  • Stable Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
        - name: my-app-container
          image: my-app:stable
          ports:
            - containerPort: 8080
  • Service Configuration:
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  • Ingress Configuration:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

Canary Deployment Example in Kubernetes

To set up a canary deployment, create a new deployment and service object for the canary version:

  1. Canary Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app-canary
  template:
    metadata:
      labels:
        app: my-app-canary
    spec:
      containers:
      - name: my-app-container
        image: my-app:canary
        ports:
        - containerPort: 8080
  1. Canary Service:
apiVersion: v1
kind: Service
metadata:
  name: my-app-canary-service
spec:
  selector:
    app: my-app-canary
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  1. Ingress for Canary:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-canary-service
                port:
                  number: 80

A Canary Deployment is a strategy where a new version of the application is rolled out incrementally to a small subset of users (the "canaries"). This allows you to monitor the new version with limited exposure and reduce the impact of potential issues. If the new version performs well with the canary users, it can be gradually rolled out to the rest of the users.

Key Steps in Canary Deployment:

  1. Deploy New Version: The new version of the application is deployed alongside the current version (existing version is still active).
  2. Gradual Rollout: A small percentage of traffic is routed to the new version, while the majority of users continue to access the old version.
  3. Monitor Performance: The new version is monitored closely for errors, performance issues, or any other problems.
  4. Increase Traffic: If the canary release is successful, more traffic is gradually routed to the new version.
  5. Complete Rollout or Rollback: Once the canary version is fully validated, the rollout can be completed. If any issues are detected, the deployment can be rolled back.

Advantages:

  • Gradual Rollout: The new version is gradually tested with a small subset of users, reducing risk and making it easier to detect problems early.
  • Minimal Risk: Only a small portion of traffic is affected at first, so any issues can be isolated quickly without impacting all users.
  • Scalable: The deployment can be adjusted to release to different portions of the user base, which is useful for scaling deployments.

Disadvantages:

  • Complexity: Managing the percentage of traffic going to different versions and monitoring the new version can be complex.
  • Testing: It may take longer to fully test the new version, as traffic is gradually rolled out instead of switching all at once.

Example of Canary Deployment in Kubernetes:

  • Deployment with Canary Strategy:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 6  # Total number of replicas for the canary deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1  # Max new pods to create
      maxUnavailable: 1  # Max old pods to be unavailable during update
  template:
    spec:
      containers:
      - name: myapp-container
        image: myapp:v2  # Canary version
  • Service Routing Traffic: To route traffic to both the old and new versions, Kubernetes Services can be configured with label selectors and traffic splitting.

For example, you could update the label selector to direct a small percentage of traffic to the new version (v2) while keeping the majority on the old version (v1).

2. Blue-Green Deployment

A Blue-Green Deployment is a strategy that reduces downtime and risk by running two identical production environments, named Blue and Green. Only one of the environments (e.g., Blue) is live at any time. When it's time to deploy a new version of the application, it is deployed to the inactive environment (Green), and then traffic is switched to the new environment.

Key Steps in Blue-Green Deployment:

  1. Blue Environment (Current Version): The live environment running the current version of the application.
  2. Green Environment (New Version): A clone of the Blue environment, where the new version of the application is deployed.
  3. Switch Traffic: After the new version is fully deployed and tested in the Green environment, traffic is switched from the Blue environment to the Green environment.
  4. Rollback: If something goes wrong with the Green environment after the switch, traffic can be redirected back to the Blue environment, providing a quick rollback option.

Advantages:

  • Zero Downtime: Since both environments are running simultaneously, users don’t experience downtime during the deployment.
  • Easy Rollback: You can easily revert to the Blue environment if issues arise with the Green deployment.
  • Minimal Risk: Full testing of the new version happens in the Green environment before any traffic is switched.

Disadvantages:

  • Resource Intensive: Running two environments means that you need twice the resources (CPU, memory, etc.), which can be costly.
  • Slow to Scale: This method may not be as flexible or scalable compared to other strategies, as you are essentially maintaining two complete environments.

Example of Blue-Green Deployment in Kubernetes:

  • Blue Environment (Current Deployment):
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1
  • Green Environment (New Version):
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: myapp-container
        image: myapp:v2
  • Service (Routes Traffic to Blue or Green):
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp-green # initially points to the Green deployment
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Key Differences Between Blue-Green and Canary Deployments

Aspect Blue-Green Deployment Canary Deployment
Deployment Strategy Full switch from old version (Blue) to new version (Green). Gradual rollout of the new version to a small subset of users.
Risk Level Low risk after switching traffic (instant switch). Low risk with gradual exposure.
Resource Usage Requires double the resources (two environments running at once). More efficient in resource usage (incremental scaling).
Rollback Easy to rollback (simply switch back to Blue). Rollback can be complex, but issues can be isolated early.
Traffic Management All traffic switched at once. Traffic is split between the old and new version.
Use Case Suitable for applications with well-defined release cycles. Best for applications requiring gradual or A/B testing.

Choosing Between Blue-Green and Canary Deployments

  • Blue-Green: Choose this strategy if you want a simpler approach with the ability to instantly switch traffic from the old version to the new one, providing fast rollback. This is ideal for applications where downtime is not acceptable, and you want to minimize risks.
  • Canary: Choose this strategy if you prefer to test the new version incrementally, exposing it to a smaller subset of users first. This method works well for applications that require gradual exposure and for catching issues early without affecting the entire user base.