For a deployment, all we have to do is change the values that we want to change using the kubectl edit command as follows:
kubectl edit <resource>
The deployment detects the changes (if any) and matches the running state to the desired state. Lets see how its done:
- We start with our guestbook application to demonstrate this example:
curl -O -L https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/guestbook-all-in-one.yaml
kubectl create -f guestbook-all-in-one.yaml
- After few minutes, all the pods should be running. Let's do our first upgrade by changing the service from ClusterIP to LoadBalancer:
code guestbook-all-in-one.yaml
#change the frontend service section from ClusterIP to LoadBalancer
# refer the previous sections if you are not sure how to change it
- Apply the change as shown in the following code:
kubectl apply -f guestbook-all-in-one.yaml
- You should see the external IP pending message (you can ignore the warnings about using the saveconfig option):
ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.0.247.224 <pending> 80:30886/TCP 7m
Normally, it would be the reverse, but for demonstration purposes imagine that we are upgrading the frontend version.
- Change the frontend image line from image: gcr.io/google-samples/gb-frontend:v4 to the following:
image: gcr.io/google-samples/gb-frontend:v3
- Run the following command:
kubectl apply -f guestbook-all-in-one.yaml
- You should see the following output:
ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl apply -f guestbook-all-in-one.yaml
service/redis-master unchanged
deployment.apps/redis-master unchanged
service/redis-slave unchanged
deployment.apps/redis-slave unchanged
service/frontend unchanged
deployment.apps/frontend configured
- Running kubectl gets events will show the rolling update strategy that the Deployment uses to update the frontend images:
12s 12s 1 frontend.157557b31a134dc7 Deployment Normal ScalingReplicaSet deployment-controller Scaled down replica set frontend-56f7975f44 to 2
12s 12s 1 frontend-5785f8455c.157557b31e83d67a ReplicaSet Normal SuccessfulCreate replicaset-controller Created pod: frontend-5785f8455c-z99v2
12s 12s 1 frontend-5785f8455c-z99v2.157557b31f68ac29 Pod Normal Scheduled default-scheduler Successfully assigned default/frontend-5785f8455c-z99v2 to aks-agentpool-18506452-1
12s 12s 1 frontend.157557b31be33765 Deployment Normal ScalingReplicaSet deployment-controller Scaled up replica set frontend-5785f8455c to 2
12s 12s 1 frontend-56f7975f44.157557b31bce2beb ReplicaSet Normal SuccessfulDelete replicaset-controller Deleted pod: frontend-56f7975f44-rfd7w
11s 11s 1 frontend-5785f8455c-z99v2.157557b35b5176f7 Pod spec.containers{php-redis} Normal Pulling kubelet, aks-agentpool-18506452-1 pulling image "gcr.io/google-samples/gb-frontend:v3"
11s 11s 1 frontend-56f7975f44-rfd7w.157557b32b25ad47 Pod spec.containers{php-redis} Normal Killing kubelet, aks-agentpool-18506452-1 Killing container with id docker://php-redis:Need to kill Pod
You will also see two replica sets for the frontend, the new one replacing the other one pod at a time:
ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kc get rs
NAME DESIRED CURRENT READY AGE
frontend-56f7975f44 0 0 0 19m
frontend-5785f8455c 3 3 3 4m
- 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!