Spinnaker CD Pipeline – Blue/Green strategy with external versioning and Kubernetes Deployment object

Introduction and Scope

Spinnaker supports multiple deployment strategies for deployments to Kubernetes. Among them, Canary Analysis and Blue-Green are popular and widely used. In Canary Analysis, an application or a service is incrementally released to a subset of users. All infrastructure in a target environment is updated in small phases (e.g: 2%, 25%, 75%, 100%). A canary release is the lowest risk-prone, compared to all other deployment strategies, because of this control.

The blue-green deployment strategy for production environments reduces downtime as well as a risk by running two identical deployments called Blue and Green. At any given time, there is only one live deployment serving complete production traffic. This technique enables development teams to achieve continuous deployment with the final stage of testing on production-ready newer versions (say Blue) before making it live and once passed, then complete incoming traffic switched using a Load Balancer from existing deployment (say Green) to Blue. This strategy supports:

1. 1. Faster rollouts for businesses to release new features on demand.
   2. Easier rollback to an older version of deployment in case of something unexpected identified in newer deployment.
   3. The simultaneous rollout of deployments with multi-service dependencies.

Blue-Green deployment strategy in Spinnaker for Kubernetes deployments

Spinnaker natively supports the Blue-Green deployment strategy with the Kubernetes ReplicaSet object and has a spinnaker managed versioning system for rolling forward and rollback. However, Spinnaker (till 1.19.x) does not support Blue-Green natively for Deployment objects and in certain use cases organizations want to maintain versions out of Spinnaker.

In this blog we will focus on the following requirements:

1. 1. Use the Kubernetes Deployment object for the blue-green strategy.
   2. Passing the version of blue deployment from externally managed source as pipeline parameter.
   3. Pipeline designs to achieve the above requirement and the possibility to extend it as a pipeline template for various teams.

From this blog, you can explore options to implement an externally versioned or managed blue-green strategy for application deployment using the Spinnaker pipeline.

Possible approaches to design Blue-Green strategy for Kubernetes deployments

Spinnaker pipeline deployment on Kubernetes with Nginx server used for routing traffic

In my scenario, I will design the sample Spinnaker pipelines using the “Nginx” image for simplicity. And here we are going to use the Spinnaker expressions feature on Spinnaker, to develop this solution. This solution uses Kubernetes service object as Load Balancer to switch traffic from blue to green or vice versa, based on matching selector labels in service object to that of spec.template.metadata.labels in deployment object.

Implementation

• To manage versions, use of parameterized deployment manifest such as given below:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: 'nginx-deployment-${parameters.release}'
spec:
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
        release: '${parameters.release}'
    spec:
      containers:
        - image: 'nginx:1.7.9'
          name: nginx
          ports:
            - containerPort: 80

• • Assuming service object pre-exist with “release” as one of the selector labels such as given below, and holding the “release” value same as mentioned in first deployment release:

apiVersion: v1
kind: Service
metadata:
    name: nginx-svc
    namespace: default
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
    release: '${parameters.release}'

Step By Step Guidelines to Design Spinnaker Pipeline for Blue-Green

• Spinnaker Pipeline – 1:
  • The Spinnaker pipeline should consist of all required parameters for release and 2 stages
  • Deploy Stage for Blue Deployment

Deploy Stage in Spinnaker for Blue Deployment on Kubernetes

• • Patch Stage for service to switch traffic on Blue deployment.
    

    Patch Stage in Spinnaker for service to switch traffic on Blue deployment on Kubernetes

• Spinnaker Pipeline – 2:
  • In this scenario, the Spinnaker pipeline should consist of 3 stages
  • Patch Stage for service to share traffic between existing green and upcoming blue.
    

    Patch Stage in Spinnaker for service to share traffic between existing green and upcoming blue deployments on Kubernetes

• • Deploy Stage for Blue deployment.
  • Patch Stage for service to switch traffic completely on Blue deployment.
    

    Patch Stage for service to switch traffic completely on Spinnaker Blue deployments to Kubernetes

• With both approaches, rollout and rollback can be achieved with parameters of the given choice. While going for the second design, we can achieve a blue-green strategy with smooth transitioning of traffic as well as non-live deployment to achieve a quick rollback.
• However, there is a challenge in specific conditions, if more than 1 release (including green) version exists in the environment. Then traffic will be bound to share in all of them after the first stage. This will pose an issue in the production environment.
• The above-discussed pipelines can be extended to use Git/Bitbucket-based Kubernetes artifacts instead of text-based. And further can be parameterized to use as a pipeline template for different teams.

Possibilities of Improvement using Spinnaker pipeline 

• The above-suggested approaches do not clean up any of those existing non-live/older deployments. The older deployments can be removed by executing either of the below two options:
  • By deleting Deployments from UI (Infrastructure tab > Clusters sub-tab)
  • By creating a separate pipeline, which contains delete manifest stage and release parameter.
• This approach also assumes a robust external versioning system for release management.

Conclusion

The deployment strategies play a vital role in achieving faster continuous delivery (CD). The blue-green strategy is one of the prominent production deployment strategies, used by organizations. The above steps help in understanding as well as achieving a blue-green strategy in a containerized production environment using Kubernetes objects and Spinnaker pipelines. Follow the OpsMx blog for more such enterprise-grade solutions for Spinnaker.

If you want to know more about the Spinnaker or request a demonstration, please book a meeting with us.

OpsMx is a leading provider of Continuous Delivery solutions that help enterprises safely deliver software at scale and without any human intervention. We help engineering teams take the risk and manual effort out of releasing innovations at the speed of modern business. For additional information, contact us