Home / 

Implementing Kubernetes into your engineering workflows can drastically improve the overall productivity. It is particularly helpful when a customer requires a shorter and reliable deployment approach to reduce the time to market.

It is essential to choose the right deployment strategy for your Kubernetes application for a reliable infrastructure during an application update. You can consider using tools like Spinnaker when adopting a Kubernetes environment. In this document, you will find 4 strategies that you can use to deploy an application in Kubernetes.

  • Blue-Green Strategy: This strategy runs two identical environments called Blue and Green. Here, only one environment serves the traffic at a time.
  • Recreate Strategy: In this strategy, an old instance is terminated to create a new instance. The older version is removed only when the new version is rolled out and tested successfully.
  • Ramped Strategy: This strategy slowly rolls-out the new version of an application before removing its previous version.
  • Canary Strategy: This strategy allows only selective members or audiences to access the new version while others will still be accessing the previous version.

Let’s look at each strategy in detail.

Blue-Green Strategy

The blue-green deployment strategy for Kubernetes deploys different versions of an application parallelly. One of the deployed versions serves as a testing environment for the QA team and the other version serves the traffic. After testing and ensuring that the new version meets the requirements, you can update a service in Kubernetes that acts as a load balancer to send traffic to the new version by replacing the version label in the selector field.

Deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-app1
spec:
  template:
    metadata:
      labels:
        app: new-app
        version: "02"
    spec:
      containers:
      - name: webserver1
        image: vilasmankala/my-repo-test:webserver1
        ports:
        - containerPort: 80


Service.yml:

apiVersion: v1
kind: Service
metadata:
 name: new-app
 labels:
   app: new-app
spec:
 type: NodePort
 ports:
 - name: http
   port: 8080
   targetPort: 8080
 selector:
   app: new-app
   version: “02”


You can update the label version with an appropriate value, i.e., 02, while switching traffic. This strategy allows you to instantly roll-out and rollback your application. Talking about the limitations, this strategy may prove to be expensive since it requires double the resources, and managing stateful applications may be challenging.

Recreate Strategy

The recreate deployment strategy for Kubernetes is very straight-forward – it merely terminates the running instances to recreate them with a new version. This technique involves the downtime for both shutdown and boot periods of an application. Here, the state of an application is renewed entirely at all times.

Deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate
spec:
  selector:
    matchLabels:
      app: recreate
  replicas: 3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: recreate
        image: vilasmankala/my-repo-test:webserver2
        ports:
        - containerPort: 80


Service.yml:

apiVersion: v1
kind: Service
metadata:
  name: recreate-service
  labels:
    app: recreate
spec:
  selector:
    app: recreate
  type: NodePort
  ports:
  - port: 80
    nodePort: 31001
    targetPort: 80


Ramped Strategy

The ramped deployment strategy for Kubernetes could be considered as a default deployment strategy. This technique slowly rolls out the new version of an application by replacing the instances one after another until all instances are rolled out. This strategy is also called a rolling update strategy since it waits for the new pods to become active via the readiness probe before it starts to scale down the older pods.

Deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deploy
spec:
  selector:
    matchLabels:
      app: webserver1
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: webserver1
    spec:
      containers:
      - name: webserver1
        image: vilasmankala/my-repo-test:webserver2
        ports:
        - containerPort: 80 


Service.yml:

apiVersion: v1
kind: Service
metadata:
  name: rolling-update
  labels:
    app: webserver1
spec:
  selector:
    app: webserver1
  type: NodePort
  ports:
  - port: 80
    nodePort: 31000
    targetPort: 80


Canary Strategy

This deployment strategy allows you to route a subset of users to new functionality. It gives you two identical environments, one that serves all the users and the other includes new features that are rolled out to only a subset of users. If there are no reported errors in the new version, then that version is rolled out gradually to the rest of the infrastructure.

Deployment1.yml:

[...]
kind: Deployment
metadata:
 name: my-app-1
spec:
 replicas: 4
 template:
 labels:
   app: my-app
   version: v1
[...]


Deployment2.yml:

[...]
kind: Deployment
metadata:
 name: my-app-2
spec:
 replicas: 1
 template:
 labels:
   app: my-app
   version: v2
[...]


Service.yml:

[...]
kind: Service
metadata:
 name: my-app
spec:
   selector:
   app: my-app
[...]


This involves a slow roll-out where the version is released only for a subset of users. You can use this strategy to conveniently monitor the app performance and error rate.

Here is an overall comparison table.

Strategy Blue-Green Recreate Ramped Canary
Efforts for Setup Moderately high efforts Less efforts Moderately less efforts Moderately high efforts
Downtime No Downtime Requires Downtime No Downtime No Downtime
Rollback rate Very low High High Moderate
Cloud Expense High Low Low Low
Real Traffic testing No No No Yes

Conclusion

You must select the right deployment strategy for your Kubernetes app based on your application use-case. For example, when deploying a Kubernetes application on the staging or development environment, using a recreate or ramped deployment strategy would be a good choice. For production, you can either use ramped or blue-green deployment strategy.

If you are not aware of your platform stability after deployment or if you want to test some application features or functionalities, then canary deployment strategy would be the best option for you. However, you must make the selection only after considering your business requirement and application behavior.