@@ -198,14 +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, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you.
202
- Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
203
- it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
204
-
205
- Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
206
- i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
207
- The reason this doesn't work is that when rolling update creates a new replication controller,
208
- the Horizontal Pod Autoscaler will not be bound to the new replication controller.
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).
209
212
210
213
## Support for cooldown/delay
211
214
0 commit comments