Kubernetes – Choose your own deployment strategies

In Kubernetes, there are lots of ways to deploy an application to production, it depends on your strategy so you can choose the best one that fit your needs, that is reliable.

Some of the possible strategies to adopt

  • recreate: terminate the old version and release the new one
  • ramped: release a new version on a rolling update fashion, one after the other
  • blue/green: release a new version alongside the old version then switch traffic
  • canary: release a new version to a subset of users, then proceed to a full rollout
  • a/b testing: release 2 version concurrently based on HTTP headers, cookie, weight…This technique required more setup on infra side with Istio, Traefik, custom nginx/haproxy …

Recreate – best for development environment

A deployment defined with a strategy of type Recreate will terminate all the running instances then recreate them with the newer version.

spec:
  replicas: 3
  strategy:
    type: Recreate

 

Ramped – slow rollout

How it works:  2nd ReplicaSet is created with the new version of the application, then the number of replicas of the old version is decreased and the new version is increased until the correct number of replicas is reached.

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2      # how many pods we can add at a time
      maxUnavailable: 0  
      # maxUnavailable define how many pods can be unavailable

      # during the rolling update

 

Blue/Green – best to avoid API versioning issues

A blue/green deployment differs from a ramped deployment because the “green” version of the application is deployed alongside the “blue” version. After testing that the new version meets the requirements, we update the Kubernetes Service object that plays the role of the load balancer to send traffic to the new version by replacing the version label in the selector field.

apiVersion: v1
kind: Service
metadata:
 name: my-app
 labels:
   app: my-app
spec:
 type: NodePort
 ports:
 - name: http
   port: 8080
   targetPort: 8080
 # Note here that we match both the app and the version.
 # When switching traffic, we update the label “version” with
 # the appropriate value, ie: v2.0.0
 selector:
   app: my-app
   version: v1.0.

 

Canary – let the consumer do the testing

A canary deployment can be done using two Deployments with common pod labels. One replica of the new version is released alongside the old version. Then after some time and if no error is detected, scale up the number of replicas of the new version and delete the old deployment.

References

  • https://github.com/ContainerSolutions/k8s-deployment-strategies
  • https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Presentation-Template-K8s-Deployment.pdf

Also published on Medium.

Leave a Reply

Your email address will not be published. Required fields are marked *