Deployments allow for updating in a few different ways. First, there is the kubectl set command, which allows us to change the deployment configuration without redeploying manually. Currently, it only allows for updating the image, but as new versions of our application or container image are processed, we will need to do this quite often.
Let's take a look using our deployment from the previous section. We should have three replicas running right now. Verify this by running the get pods command with a filter for our deployment:
$ kubectl get pods -l name=node-js-deploy
We should see three pods similar to those listed in the following screenshot:
Take one of the pods listed on our setup, replace it in the following command where it says {POD_NAME_FROM_YOUR_LISTING}, and run this command:
$ kubectl describe pod/{POD_NAME_FROM_YOUR_LISTING} | grep Image:
We should see an output like the following screenshot with the current image version of 0.1:
Now that we know what our current deployment is running, let's try to update to the next version. This can be achieved easily using the kubectl set command and specifying the new version, as shown here:
$ kubectl set image deployment/node-js-deploy node-js-deploy=jonbaier/pod-scaling:0.2
$ deployment "node-js-deploy" image updated
If all goes well, we should see text that says deployment "node-js-deploy" image updated displayed on the screen.
We can double–check the status using the following rollout status command:
$ kubectl rollout status deployment/node-js-deploy
Alternatively, we can directly edit the deployment in an editor window with kubectl edit deployment/node-js-deploy and change .spec.template.spec.containers[0].image from jonbaier/pod-scaling:0.1 to jonbaier/pod-scaling:0.2. Either of these methods will work to update your deployment, and as a reminder you can check the status of your update with the kubectl status command:
$ kubectl rollout status deployment/node-js-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "node-js-deployment" successfully rolled out
We should see some text saying that the deployment successfully rolled out. If you see any text about waiting for the rollout to finish, you may need to wait a moment for it to finish, or alternatively check the logs for issues.
Once it's finished, run the get pods command as earlier. This time, we will see new pods listed:
Once again, plug one of your pod names into the describe command we ran earlier. This time, we should see the image has been updated to 0.2.
What happened behind the scenes is that Kubernetes has rolled out a new version for us. It basically creates a new ReplicaSet with the new version. Once this pod is online and healthy, it kills one of the older versions. It continues this behavior, scaling out the new version and scaling down the old versions, until only the new pods are left. Another way to observe this behavior indirectly is to investigate the ReplicaSet that the Deployment object is using to update your desired application state.
Remember, you don't interact directly with ReplicaSet, but rather give Kubernetes directives in the form of Deployment elements and let Kubernetes make the required changes to the cluster object store and state. Take a look at the ReplicaSets quickly after running your image update command, and you'll see how multiple ReplicaSets are used to effect the image change without application downtime:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
node-js-deploy-1556879905 3 3 3 46s
node-js-deploy-4657899444 0 0 0 85s
The following diagram describes the workflow for your reference:
It's worth noting that the rollback definition allows us to control the pod replace method in our deployment definition. There is a strategy.type field that defaults to RollingUpdate and the preceding behavior. Optionally, we can also specify Recreate as the replacement strategy and it will kill all the old pods first before creating the new versions.