Kubernetes Deployment Strategies
- Rolling Deployment
- Blue-Green Deployment
- Canary Deployment
1. Rolling Deployment.
Kubernetes rolling deployment is a strategy for updating and deploying new versions of software in a controlled and gradual manner. Instead of deploying updates all at once, Kubernetes rolls out changes incrementally, reducing the risk of downtime and allowing for easy rollbacks in case of errors. Rolling deployment involves creating a new replica set with the updated version of the software while gradually scaling down the old replica set. This allows for the new version to be deployed while the old version is still running, ensuring that there is no interruption to service. Once the new version is fully deployed, the old replica set is deleted, and the deployment is complete. Kubernetes rolling deployment is essential for ensuring high availability and reliability in complex distributed systems.
Here is an example of a rolling deployment YAML file in Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: rolling-update-deployment
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: rolling-update
template:
metadata:
labels:
app: rolling-update
spec:
containers:
– name: spring-boot
image:
ports:
– containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: rolling-update-service
spec:
type: LoadBalancer
selector:
app: rolling-update
ports:
port: 80
targetPort: 8080
After executing this yml in Kubernetes it will create a new version of pod first once it was ready it will delete one old version pods has shown in above figure.
2. Blue/Green Deployment.
Blue/Green deployment methodology
Blue/green deployments provide releases with near zero-downtime and rollback capabilities. The fundamental idea behind blue/green deployment is to shift traffic between two identical environments that are running different versions of your application. The blue environment represents the current application version serving production traffic. In parallel, the green environment is staged running a different version of your application. After the green environment is ready and tested, production traffic is redirected from blue to green. If any problems are identified, you can roll back by reverting traffic back to the blue environment.
Benefits of blue/green
Traditional deployments with in-place upgrades make it difficult to validate your new application version in a production deployment while also continuing to run the earlier version of the application. Blue/green deployments provide a level of isolation between your blue and green application environments. This helps ensure spinning up a parallel green environment does not affect resources underpinning your blue environment. This isolation reduces your deployment risk.
Here is an example of a Blue/green deployment YAML file in Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: blue-deployment
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: blue
template:
metadata:
labels:
app: blue
spec:
containers:
– name: spring
image: 8897256640/docker-spring-boot:2
ports:
– containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: green-deployment
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: green
template:
metadata:
labels:
app: green
spec:
containers:
– name: spring
image: 8897256640/docker-spring-boot:3
ports:
– containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: blue-green-service
spec:
type: LoadBalancer
selector:
app: blue
ports:
port: 80
targetPort: 8080
In blue-green deployment to update the application means we created the same environment for new version application and shift the traffic to new version application, if in case the new version has bugs immediately shift the traffic to old version.
3. Canary Deployment.
Kubernetes canary deployment is a technique for rolling out new features or changes to a small subset of users or servers before releasing the update to the entire system. This is done by creating a new replica set with the updated version of the software while keeping the original replica set running. A small percentage of traffic is then routed to the new replica set, while the majority of the traffic continues to be served by the original replica set. This allows for the new version to be tested in a live environment while minimizing the risk of issues affecting the entire system. If issues are detected during the canary deployment, it can be quickly rolled back to the original replica set. Canary deployments are a valuable tool for minimizing risk and ensuring high availability in complex distributed systems, by allowing for controlled testing of changes before they are released to the entire system.
Here is an example of a Canary deployment YAML file in Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: v1-deployment
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: canary
template:
metadata:
labels:
app: canary
spec:
containers:
– name: canary-old
image: 8897256640/docker-spring-boot:2
ports:
– containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: v2-deployment
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: canary
template:
metadata:
labels:
app: canary
spec:
containers:
– name: canary-new
image: 8897256640/docker-spring-boot:3
ports:
– containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: canary-service
spec:
type: LoadBalancer
selector:
app: canary
ports:
port: 80
targetPort: 8080
Canary deployment means slowly increasing the new version as show in above figure.