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.
Latest posts by admin (see all)
- Install and Running Supervisord in virtualenv python 2.7 - January 24, 2019
- Urgent fix: Briefly unavailable for scheduled maintenance. Check back in a minute. - January 22, 2019
- Change WordPress post date format to time ago - January 21, 2019
Also published on Medium.