Application Deployment in a Kubernetes Environment
Implementing Kubernetes into your engineering workflows can drastically improve 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.
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:
Recommended by LinkedIn
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.
Veera Venkata Kiran
Solution Architect
Kudos