Upgrade Azure Kubernetes Service Application Using The YAML Files

Prerequisites

• Azure Subscription Account
• AKS Cluster
• Basic Knowledge of Kubernetes Concepts if not please read this article
• Basic Knowledge of YAML
• Application Deployment on AKS | Part One
• Application Deployment on AKS | Part Two
• Application Deployment on AKS | Part Three
• Scale Azure Kubernetes Service Cluster Using Azure Portal

After the Deployment and Scaling of the Azure Kubernetes service application, now we have to Upgrade the application, Using deployments in Kubernetes makes upgrading an application a straightforward operation. As with any upgrade, you should have good failbacks in case something goes wrong. Most of the issues you will run into will happen during upgrades. Cloud-native applications are supposed to make dealing with this relatively easy, which is possible if you have a very strong development team that embraces DevOps principles.

There are multiple ways we can make updates in a Kubernetes cluster. In this article, we will use the YAML file to upgrade the Azure Kubernetes resources,

In order to upgrade a Kubernetes service or deployment, we can update the actual YAML definition file and apply that to the currently deployed application. Typically, we use Kubectl create to create resources. Similarly, we can use Kubectl apply to make changes to the resources. The deployment detects the changes (if any) and matches the Running state to the desired state. Let's see how this is done,

Step 1. Open the Cloudshell from Azure Portal, and Clone the GitHub repository using the following command. I have placed all the files there,

1. git clone https://github.com/RumeelHussain/Azure-K8s
2. cd Scale-Upgrade.

Step 2. We start with our guestbook application to demonstrate this example,

kubectl create -f guestbook-all-in-one.yaml

Step 3. After a few minutes, all the Pods should be running. Let's perform our first upgrade by changing the service from ClusterIP to LoadBalancer, as we did earlier in the previous article. However, now we will edit our YAML file rather than using Kubectl edit. Edit the YAML file using this.

code guestbook-all-in-one.yaml.

Uncomment line 108 in this file to set the type as LoadBalancer and save the file, as shown in the screenshot.

Step 4. Apply the change as shown in the following code.

kubectl apply -f guestbook-all-in-one.yaml

Step 5. You can now get the public IP of the service using the following command.

kubectl get svc

Give it a few minutes, and you should be shown the IP as displayed in the screenshot.

Step 6. We will now make another change. We'll downgrade the front-end image line on line 133 from the image: gcr.io/google-samples/gb-frontend:v4 to the following,

image: gcr.io/google-samples/gb-frontend:v3

This change can be made by opening the guestbook application in the editor by using this familiar command,

code guestbook-all-in-one.yaml

Step 7. Run the following command to perform the update and watch the Pods change.

kubectl apply -f guestbook-all-in-one.yaml && kubectl get pods -w

What you can see here is that the old version of the Pods (based on the old ReplicaSet) gets terminated, while the new version gets created.

Step 8. Running kubectl get events | grep ReplicaSet will show the rolling update strategy that the deployment uses to update the front-end images as follows,

kubectl get events | grep ReplicaSet

Note. In above step 8, we are making use of a pipe shown by the | sign and the grep command. A pipe in Linux is used to send the output of one command to the input of another command. In our case, we are sending the output of kubectl get events to the grep command. grep is a command in Linux that is used to filter text. In our case, we are using the grep command to only show us lines that contain the word ReplicaSet.

You can see in the screenshot that the new ReplicaSet gets scaled up, while the old one gets scaled down. You will also see two ReplicaSets for the front end, the new one replacing the other one Pod at a time.

kubectl get replicaset

Step 9. Kubernetes will also keep a history of your rollout. You can see the rollout history using this command,

kubectl rollout history deployment frontend

Step 10. Since Kubernetes keeps a history of our rollout, this also enables rollback. Let's do a rollback of our deployment,

kubectl rollout undo deployment frontend

This will trigger a rollback. This means that the new ReplicaSet will be scaled down to zero instances, and the old one will be scaled up to three instances again. We can verify this using the following command.

kubectl get replicaset

This shows us, as expected, that the old ReplicaSet is scaled back to three instances and the new one is scaled down to zero instances.

Step 11. Finally, let's clean up again by running the kubectl delete command.

kubectl delete -f guestbook-all-in-one.yaml

Congratulations!

You have completed the upgrade of an application and a rollback to a previous version. In this example, you have used Kubectl Apply to make changes to your application. You can similarly also use Kubectl edit to make changes, which will be explored in the next article.