You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -198,8 +198,17 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe
198
198
199
199
## Autoscaling during rolling update
200
200
201
-
Currently in Kubernetes, a rolling update is performed using a deployment object, which manages the underlying replica sets for you.
202
-
A Horizontal Pod Autoscaler is bound to a single deployment object - it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
201
+
Kubernetes lets you perform a rolling update on a Deployment. In that
202
+
case, the Deployment manages the underlying ReplicaSets for you.
203
+
When you configure autoscaling for a Deployment, you bind a
204
+
HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler
205
+
manages the `replicas` field of the Deployment. The deployment controller is responsible
206
+
for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable
207
+
number during the rollout and also afterwards.
208
+
209
+
If you perform a rolling update of a StatefulSet that has an autoscaled number of
210
+
replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
211
+
similar to ReplicaSet).
203
212
204
213
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
205
214
i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
0 commit comments