From 7a145852b9aff00dfccfd6aaca61219743acd837 Mon Sep 17 00:00:00 2001 From: Michail Kargakis Date: Wed, 9 Nov 2016 16:39:48 +0100 Subject: [PATCH] Proportional scaling in Deployments --- docs/user-guide/deployments.md | 69 ++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 84ea561bf4..8f138459d0 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -395,6 +395,75 @@ Events: You can set `.spec.revisionHistoryLimit` field to specify how much revision history of this deployment you want to keep. By default, all revision history will be kept; explicitly setting this field to `0` disallows a deployment being rolled back. +## Scaling a Deployment + +You can scale a Deployment by using the following command: + +```shell +$ kubectl scale deployment nginx-deployment --replicas 10 +deployment "nginx-deployment" scaled +``` + +Assuming [horizontal pod autoscaling](/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md) is enabled +in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of +Pods you want to run based on the CPU utilization of your existing Pods. + +```shell +$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 +deployment "nginx-deployment" autoscaled +``` + +RollingUpdate Deployments support running multitple versions of an application at the same time. When you +or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress +or paused), then the Deployment controller will balance the additional replicas in the existing active +ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*. + +For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surge)=3, and [maxUnavailable](#max-unavailable)=2. + +```shell +$ kubectl get deploy +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 10 10 10 10 50s +``` + +You update to a new image which happens to be unresolvable from inside the cluster. + +```shell +$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag +deployment "nginx-deployment" image updated +``` + +The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191 but it's blocked due to the +maxUnavailable requirement that we mentioned above. + +```shell +$ kubectl get rs +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 5 5 0 9s +nginx-deployment-618515232 8 8 8 1m +``` + +Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas +to 15. The Deployment controller needs to decide where to add these new 5 replicas. If we weren't using +proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, we +spread the additional replicas across all ReplicaSets. Bigger proportions go to the ReplicaSets with the +most replicas and lower proportions go to ReplicaSets with less replicas. Any leftovers are added to the +ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled up. + +In our example above, 3 replicas will be added to the old ReplicaSet and 2 replicas will be added to the +new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming +the new replicas become healthy. + +```shell +$ kubectl get deploy +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +$ kubectl get rs +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + ## Pausing and Resuming a Deployment You can also pause a Deployment mid-way and then resume it. A use case is to support canary deployment.