When you create a deployment it triggers a rollout a new rollout creates a new deployment revision. In the future, when the application is upgraded meaning when the container version is updated to a new one a new rollout is triggered and a new deployment. This helps us keep track of the changes made to our deployment and enables us to roll back to a previous version of deployment if necessary
$ kubectl rollout status deployment nginx-deployment deployment "nginx-deployment" successfully rolled out
By default ‘rollout status’ will watch the status of the latest rollout until it’s done.
$ kubectl rollout history deployment nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 <none>
There are two types of deployment strategies.
1. recreate strategy: Imagine, you have three replicas of the application instance deployed. One way to upgrade these to a newer version is to destroy all of these and then create a newer version of application instances. First, destroy the three running instances and then deploy three new instances of the new application version. The problem with this that during the period after the older version is down and before a newer version is up the application is down and inaccessible to users. This strategy is known as the recreate strategy and this is not the default deployment strategy.
2. rolling update strategy: we do not destroy all of the running applications at once. Instead, we take down the older version and bring up a newer version one by one This way the application never goes down and the upgrade is seamless. If you do not specify a strategy while creating the deployment it will assume it to be a rolling update.
How exactly do you update the deployment.
When I say update it could be different things such as updating the application version by updating the version of docker containers used updating their labels or updating the number of replicas etc. Since we already have a deployment definition file it is easy for us to modify these files. Once we make the necessary changes we run the kubectl apply command to apply the changes. A new rollout is triggered and a new revision of the deployment is created.
Edited image version
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: name: nginx-pod labels: app: nginx spec: containers: - name: nginx-container image: nginx:1.7.1 ports: - containerPort: 80 protocol: TCP
$ kubectl apply -f nginx-deployment.yaml --record deployment.apps/nginx-deployment configured
$ kubectl rollout history deployment nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 2 <none> 3 kubectl apply --filename=nginx-deployment.yaml --record=true $ kubectl rollout status deployment apple-deployment deployment "apple-deployment" successfully rolled out
The old replicaSets are down and the new replicaSets are running
$ kubectl get replicaset NAME DESIRED CURRENT READY AGE nginx-deployment-5b4596cf84 3 3 3 74m nginx-deployment-747d496675 0 0 0 10m
$ kubectl rollout undo deployment nginx-deployment --to-revision=2 deployment.apps/nginx-deployment rolled back $ kubectl rollout history deployment nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 3 kubectl apply --filename=nginx-deployment.yaml --record=true 4 <none> $ kubectl get replicaset NAME DESIRED CURRENT READY AGE nginx-deployment-5b4596cf84 0 0 0 80m nginx-deployment-747d496675 3 3 3 16m
The older replicaSets are running.