2. Scale and upgrade your application
Part of Running an application is being able to scale it to meet traffic demands, and to upgrade it when new versions of the software is available.
Thankfully Kubernetes makes both of these things really easy. In the previous steps we ran an application by creating a Deployment. A Deployment is a Controller with special properties to help you both scale and upgrade your workload.
Validate your running workload
We currently have a matching set of a Deployment, a ReplicaSet and a Pod in our cluster. Run
kubectl get all:
Note: If these resources are missing you can go back to the previous step and rerun the commands to deploy an application.
$ kubectl get all NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/first 1/1 1 1 15h NAME DESIRED CURRENT READY AGE replicaset.apps/first-7f77d57ccc 1 1 1 15h NAME READY STATUS RESTARTS AGE pod/first-7f77d57ccc-8gwkp 1/1 Running 0 15h
You can see that the ReplicaSet shows a
DESIRED and a
CURRENT count of pods under its control. The ReplicaSet is managed by the Deployment, and is itself managed by the Deployment. The ReplicaSet will create or destroy Pods in order to make the current state match the desired state.
Scale your application out
You can run
kubectl scale to change the desired state like so:
Note: since the ReplicaSet is managed by the Deployment we actually want to point the scale command at the Deployment resource.
$ kubectl scale --replicas=3 deployment/first deployment.extensions/first scaled
Since our image is quite small, it should take just a few seconds for the scale event to occur which we can check with another
kubectl get all:
$ kubectl get all NAME READY STATUS RESTARTS AGE pod/first-7f77d57ccc-7h9ch 1/1 Running 0 4s pod/first-7f77d57ccc-8gwkp 1/1 Running 0 20h pod/first-7f77d57ccc-c2j4x 1/1 Running 0 4s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 20h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/first 3/3 3 3 20h NAME DESIRED CURRENT READY AGE replicaset.apps/first-7f77d57ccc 3 3 3 20h
You can see that the Deployment was updated to expect 3, which updated the ReplicaSet which created two more pods.
Note: If we had scaled the ReplicaSet directly, it would immediately be changed back to the original size as the reconciliation loop of the Deployment controller would see the actual state of the ReplicaSet no longer matches the Desired state. Try it and see what happens if you run
kubectl scale --replicas=5 rs/first-7f77d57ccc(change the name to match your output).
Upgrade your application
If you remember that very first command we used to create this Deployment (
kubectl create deployment first image=nginx) you’ll note that we didn’t specify a version of nginx to run.
It’s always a good idea to be as specific as possible, so lets upgrade our application to be a very specific version of nginx. We can do this with the
kubectl set command:
$ kubectl set image deployment/first nginx=nginx:1.17.2 deployment.extensions/first image updated
kubectl get all and if you’re fast enough you’ll catch the Deployment mid-upgrade:
Note: if you’re fast enough you’ll see new Pods starting to run, and you’ll see the old Pods being Terminated as the Deployment controller juggles a pair of ReplicaSets.
$ kubectl get all NAME READY STATUS RESTARTS AGE pod/first-765d49ddcb-f6hb4 1/1 Running 0 3s pod/first-765d49ddcb-gcgkn 0/1 ContainerCreating 0 1s pod/first-844f75c9b8-4cvgv 1/1 Running 0 4m10s pod/first-844f75c9b8-kzzhs 1/1 Running 0 4m17s pod/first-844f75c9b8-wwmkg 0/1 Terminating 0 4m7s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 21h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/first 3/3 2 3 20h NAME DESIRED CURRENT READY AGE replicaset.apps/first-765d49ddcb 2 2 1 3s replicaset.apps/first-844f75c9b8 2 2 2 4m17s
In this Lesson you utilized the scaling and upgrade capabilities of the Deployment controller. By changing the image version in the Deployment you signaled to the Deployment controller that you had a new desired state. In order to bring the actual state into line with the desired state the Deployment controller creates a second ReplicaSet and it scales that new ReplicaSet up as it scales the old ReplicaSet down in a way to ensure that the actual number of Pods running always matches the desired number (in this case 3).
This rolling upgrade of your application is completely transparent to you, the Deployment controller manages it for you, and it does it in a way to ensure as little disruption to end users as possible.
Speaking of end users, wouldn’t it be nice if you could set up access to the application? We can’t expect everyone to run
kubectl port-forward to access our app.
Next Creating services to provide access into your application.