-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Improve docs for HorizontalPodAutoscaler #30711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve docs for HorizontalPodAutoscaler #30711
Conversation
👷 Deploy Preview for kubernetes-io-vnext-staging processing. 🔨 Explore the source changes: e1bf8f2 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/61aa0996b1d31400089d51a1 |
/sig autoscaling |
Relevant to issue #4493 |
/assign @chrisnegus |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice job cleaning up this document. I like the addition of glossary terms and the use of exact object names. Side note: The some of the official autoscaling reviewers are no longer active. I had trouble finding a reviewer from one of the other PRs I was following. We might want to see about getting that list cleaned up.
|
||
Roughly speaking, the HPA {{<glossary_tooltip text="controller" term_id="controller">}} will increase and decrease | ||
the number of replicas (by updating the Deployment) to maintain an average CPU utilization across all Pods of 50%. | ||
The Deployment then updates the ReplicaSet - this is part of how all Deployments work in Kubernetes - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Deployment then updates the ReplicaSet - this is part of how all Deployments work in Kubernetes - | |
The Deployment then updates the ReplicaSet---this is part of how all Deployments work in Kubernetes---and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mean an em dash here, which I believe is typically used without spaces before and after it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant an en dash with spaces round it (but, I'm not very familiar with American-style punctuation). Could we tweak the punctuation in a follow up PR though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you like. We Americans do things a little different sometimes.
Roughly speaking, the HPA {{<glossary_tooltip text="controller" term_id="controller">}} will increase and decrease | ||
the number of replicas (by updating the Deployment) to maintain an average CPU utilization across all Pods of 50%. | ||
The Deployment then updates the ReplicaSet - this is part of how all Deployments work in Kubernetes - | ||
and then the ReplicaSet either adds or removes Pods based on the change to its `.spec`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and then the ReplicaSet either adds or removes Pods based on the change to its `.spec`. | |
then the ReplicaSet either adds or removes Pods based on the change to its `.spec`. |
I added the "and" to the previous line so the em dash could butt up against it.
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
Outdated
Show resolved
Hide resolved
|
||
```shell | ||
# You can use "hpa" or "horizontalpodautoscaler"; either name works OK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# You can use "hpa" or "horizontalpodautoscaler"; either name works OK. | |
# You can use "hpa" or "horizontalpodautoscaler"; either name will work. |
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
Outdated
Show resolved
Hide resolved
4440c7d
to
6c9456c
Compare
/lgtm |
LGTM label has been added. Git tree hash: aab5f2877f79ff9678d852c851253a0e0e4399c7
|
@gjtempleton could you give this one a quick tech review? thanks! |
Co-authored-by: Chris Negus <[email protected]>
6c9456c
to
e1bf8f2
Compare
I fixed a spelling mistake I'd accidentally missed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly nits, but a number of minor suggestions/queries, generally looks like a significant improvement though, thanks!
the HorizontalPodAutoscaler instructs the workload resource (the Deployment, StatefulSet, | ||
or other similar resource) to scale back down. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably end up referring to any object implementing the scale subresource
, but I don't think we currently have any great place to link users to for more information on this, so best to leave it as is, and make improving the docs on the scale subresource a follow-up action.
Finally, to use metrics not related to any Kubernetes object you must have a | ||
Kubernetes cluster at version 1.10 or later, and you must be able to communicate | ||
with the API server that provides the external Metrics API. | ||
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we move this anywhere else as this still applies given custom and external metrics continue to be entirely optional?
[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) subcommand, | ||
part of `kubectl`, that helps you do this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) subcommand, | |
part of `kubectl`, that helps you do this. | |
the [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) subcommand, | |
part of `kubectl`, which helps you do this. |
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods | ||
controlled by the php-apache deployment we created in the first step of these instructions. | ||
Roughly speaking, HPA will increase and decrease the number of replicas | ||
(via the deployment) to maintain an average CPU utilization across all Pods of 50%. | ||
Since each pod requests 200 milli-cores by `kubectl run`, this means an average CPU usage of 100 milli-cores. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this not via kubectl apply
rather than kubectl run
at this point?
and isn't usually a problem). | ||
|
||
Please note that the current CPU consumption is 0% as there are no clients sending requests to the server | ||
(the ``TARGET`` column shows the average across all the Pods controlled by the corresponding deployment). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an area we might need to expand on given the support for container-based scaling, though I don't think it should block this PR, especially given they're still in alpha.
value as a percentage of the equivalent | ||
[resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) | ||
on the containers in each Pod. If a target raw value is set, the raw metric values are used directly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another point where we should likely call out the alpha support for container metrics.
The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from | ||
{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}} | ||
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is | ||
usually provided by an add on named Metrics Server, which needs to be launched separately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually provided by an add on named Metrics Server, which needs to be launched separately. | |
usually provided by an add-on named Metrics Server, which needs to be launched separately. |
Maybe personal preference, I'm not certain.
The autoscaler accesses corresponding scalable controllers (such as replication controllers, deployments, and replica sets) | ||
by using the scale sub-resource. Scale is an interface that allows you to dynamically set the number of replicas and examine | ||
each of their current states. More details on scale sub-resource can be found | ||
[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, we need to improve our documentation of the scale subresource in general and link to it in a number of places, not a blocker though.
action if the ratio is sufficiently close to 1.0 (within a globally-configurable | ||
tolerance, 0.1 by default). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does feel like we're forcing users to take an extra hop by removing the name of the flag here.
You specify these behaviours by setting `scaleUp` and / or `scaleDown` | ||
under the `behavior` field. | ||
|
||
You can specify a _stabilization window_ that prevents [flapping](#flapping) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe mitigates
or lessens
is better here, as we can't guarantee preventing any scaling flapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, do we need this segment given largely restating it ~40 lines below?
/lgtm |
LGTM label has been added. Git tree hash: f3d5bbd8dc0384f7fcb01b197856b463e2ea2ee2
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jlbutler The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
After the v1.23 release I'll see about nudging folk to improve this further. |
(What I hope are) better docs for HPA, following on from PR #30547.
Preview, preview.