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.
Let’s look at each strategy in detail.
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.
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
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.
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.
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
apiVersion: v1 kind: Service metadata: name: recreate-service labels: app: recreate spec: selector: app: recreate type: NodePort ports: - port: 80 nodePort: 31001 targetPort: 80
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.
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
apiVersion: v1 kind: Service metadata: name: rolling-update labels: app: webserver1 spec: selector: app: webserver1 type: NodePort ports: - port: 80 nodePort: 31000 targetPort: 80
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.
[...] kind: Deployment metadata: name: my-app-1 spec: replicas: 4 template: labels: app: my-app version: v1 [...]
[...] kind: Deployment metadata: name: my-app-2 spec: replicas: 1 template: labels: app: my-app version: v2 [...]
[...] 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.
|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|
|Real Traffic testing||No||No||No||Yes|
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.