Performing a Rolling Update

    Updating an application

    Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allow Deployments’ update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

    In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.

    • Updating an app

    Rolling updates allow Deployments’ update to take place with zero downtime by incrementally updating Pods instances with new ones.

    Performing a Rolling Update - 图2

    Performing a Rolling Update - 图4

    Previous

    Similar to application Scaling, if a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update. An available Pod is an instance that is available to the users of the application.

    Rolling updates allow the following actions:

    • Promote an application from one environment to another (via container image updates)
    • Rollback to previous versions

    If a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update.

    In the following interactive tutorial, we’ll update our application to a new version, and also perform a rollback.

    Update the version of the app

    To list your Deployments, run the subcommand: **kubectl get deployments**

    To list the running Pods, run the get pods subcommand:

    **kubectl get pods**

    To view the current image version of the app, run the describe pods subcommand and look for the Image field:

    **kubectl describe pods**

    **kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2**

    The command notified the Deployment to use a different image for your app and initiated a rolling update. Check the status of the new Pods, and view the old one terminating with the get pods subcommand:

    **kubectl get pods**

    First, check that the app is running. To find the exposed IP address and port, run the describe service command:

    **kubectl describe services/kubernetes-bootcamp**

    Create an environment variable called NODE_PORT that has the value of the Node port assigned:


    **echo "NODE_PORT=$NODE_PORT"**

    Next, do a curl to the the exposed IP and port:

    **curl http://"$(minikube ip):$NODE_PORT"**

    Every time you run the curl command, you will hit a different Pod. Notice that all Pods are now running the latest version (v2).

    You can also confirm the update by running the rollout status subcommand:

    **kubectl rollout status deployments/kubernetes-bootcamp**

    To view the current image version of the app, run the describe pods subcommand:

    **kubectl describe pods**

    In the Image field of the output, verify that you are running the latest image version (v2).

    Roll back an update

    Let’s perform another update, and try to deploy an image tagged with v10:

    **kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10**

    Notice that the output doesn’t list the desired number of available Pods. Run the get pods subcommand to list all Pods:

    **kubectl get pods**

    Notice that some of the Pods have a status of ImagePullBackOff.

    To get more insight into the problem, run the describe pods subcommand:

    **kubectl describe pods**

    In the Events section of the output for the affected Pods, notice that the v10 image version did not exist in the repository.

    To roll back the deployment to your last working version, use the rollout undo subcommand:

    **kubectl rollout undo deployments/kubernetes-bootcamp**

    The rollout undo command reverts the deployment to the previous known state (v2 of the image). Updates are versioned and you can revert to any previously known state of a Deployment.

    Use the get pods subcommand to list the Pods again:

    **kubectl get pods**

    Four Pods are running. To check the image deployed on these Pods, use the describe pods subcommand:

    The Deployment is once again using a stable version of the app (v2). The rollback was successful.

    Remember to clean up your local cluster

    **kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp**