website
website copied to clipboard
[FG:InPlacePodVerticalScaling] Umbrella issue for InPlacePodVerticalScaling documentation changes
- [ ] Update https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/ with v1.33 user-facing changes
- [ ] Switch to conditions for tracking resize status
- [ ] ~~PreferNoRestart policy (alpha)~~ Deferred to v1.34
- [ ] Using ObservedGeneration to deterministically track resizes (alpha)
- [ ] https://kubernetes.io/docs/reference/node/kubelet-files/ update with new checkpoint paths
- [ ] Ensure limitations are clear
- [ ] Only CPU & Memory are mutable
- [ ] Cannot decrease memory limits, unless resize policy is RestartContainer
- [ ] Cannot resize swap → cannot resize memory request on swap-enabled pods
- [ ] Cannot resize Windows pods
- [ ] Cannot resize static CPU or static Memory resources
- [ ] Cannot remove resource requirements
- [ ] Cannot change pod QoS
- Guaranteed: requests must equal limits
- Burstable: cannot set both CPU & memory requests equal to limits
- Best effort: cannot add resource requirements
- [ ] Feature naming consistency, centered around "Resizing CPU and Memory Resources in-place"
- [ ] Describe relationship to "Vertical Pod Autoscaling"
- [ ] Cross reference from relevant pages
- [ ] https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/
- [ ] https://kubernetes.io/docs/concepts/workloads/autoscaling/#scaling-workloads-vertically
- [ ] https://kubernetes.io/docs/concepts/workloads/pods/
- [ ] https://kubernetes.io/docs/concepts/workloads/pods/downward-api/#downwardapi-resourceFieldRef - https://github.com/kubernetes/kubernetes/issues/130801
- [ ] Add debugging & troubleshooting documentation
/sig node /milestone v1.33
@tallclair: You must be a member of the kubernetes/website-milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Website milestone maintainers and have them propose you as an additional delegate for this responsibility.
In response to this:
- [ ] Update https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/ with v1.33 user-facing changes
- [ ] Switch to conditions for tracking resize status
- [ ] Forbid downscaling memory limits
- [ ] PreferNoRestart policy (alpha)
- [ ] Using ObservedGeneration to deterministically track resizes (alpha)
- [ ] Feature naming consistency, centered around "Resizing CPU and Memory Resources in-place"
- [ ] Describe relationship to "Vertical Pod Autoscaling"
- [ ] Cross reference from relevant pages
- [ ] https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/
- [ ] https://kubernetes.io/docs/concepts/workloads/autoscaling/#scaling-workloads-vertically
- [ ] Add debugging & troubleshooting documentation
/sig node /milestone v1.33
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
This issue is currently awaiting triage.
SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
/assign @tallclair
@tallclair we should have some changes to https://kubernetes.io/docs/concepts/workloads/pods/ too - especially if there's a plan to move this to enabled-by-default and / or to beta.
Feature naming consistency, centered around "Resizing CPU and Memory Resources in-place"
We document concepts and tasks much more than features. We should write the docs mostly as if Kubernetes has had this since 1.0, and then add little notices to make it clear that actually you need a recent enough release.
(why? we like our documentation timeless)
/close
I don't think we need this cover-bug anymore. We should file individual issues for any outstanding in-place resize documentation issues.
@tallclair: Closing this issue.
In response to this:
/close
I don't think we need this cover-bug anymore. We should file individual issues for any outstanding in-place resize documentation issues.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.