docs(workloads): add in-place Pod resize guidance#824
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAdds a dedicated in-place Pod CPU/memory resizing guide, links it from the Pod CLI docs, and updates VPA docs to document ChangesIn-place Pod Resource Resizing Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx (1)
5-5: ⚡ Quick winClarify the title to avoid overpromising zero disruption.
The page title implies no disruption, but the page also documents
RestartContainerbehavior. Consider wording this as “without Pod recreation” to align expectations.✏️ Suggested wording
-# Adjust Pod Resource Levels Without Pod Disruption +# Adjust Pod Resource Levels Without Pod Recreation🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx` at line 5, Update the page title "Adjust Pod Resource Levels Without Pod Disruption" to avoid overpromising zero disruption—change it to something like "Adjust Pod Resource Levels Without Pod Recreation" (or "without recreating the Pod") and update any matching headings; also ensure any explanatory text mentions that RestartContainer behavior may still cause container restarts, referencing the RestartContainer behavior so readers understand the potential for restart without full pod recreation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx`:
- Line 5: Update the page title "Adjust Pod Resource Levels Without Pod
Disruption" to avoid overpromising zero disruption—change it to something like
"Adjust Pod Resource Levels Without Pod Recreation" (or "without recreating the
Pod") and update any matching headings; also ensure any explanatory text
mentions that RestartContainer behavior may still cause container restarts,
referencing the RestartContainer behavior so readers understand the potential
for restart without full pod recreation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: bf5dda30-7297-48f4-8a07-a68249c391c2
📒 Files selected for processing (3)
docs/en/developer/building_application/application_workloads/pod.mdxdocs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdxdocs/en/developer/building_application/operation_maintaining/add_vpa.mdx
Deploying alauda-container-platform with
|
| Latest commit: |
3e0e69d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e72efa88.alauda-container-platform.pages.dev |
| Branch Preview URL: | https://feat-add-inplace-doc.alauda-container-platform.pages.dev |
Document Pod resize workflows and related VPA links. Verified with lint, build, and live-cluster e2e checks.
yinshuxun
force-pushed
the
feat/add-inplace-doc
branch
from
cda10ef to
fa6361a
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx`:
- Around line 59-64: Add a note that the Kubernetes API server must support the
pods/resize subresource (in addition to using kubectl v1.32.0+); update the
paragraph to explicitly say "The Kubernetes API server must expose the
pods/resize subresource" and include a short verification hint such as using
kubectl api-resources or checking the API discovery (e.g., kubectl api-resources
| grep resize or curl the API discovery for pods/resize) so readers know how to
confirm their control plane supports the resize subresource.
- Around line 128-134: The doc incorrectly places the `Error` reason under
`PodResizePending`; update the snippet so `Error` is listed under
`PodResizeInProgress` (or add an explicit citation if you verify `Error` can
also appear under `PodResizePending`); specifically modify the bullets around
`PodResizeInProgress` and `PodResizePending` to show `Infeasible` and `Deferred`
as reasons for `PodResizePending` and move `Error` into the
`PodResizeInProgress` section (referencing the condition names
`PodResizeInProgress`, `PodResizePending`, and the reasons `Infeasible`,
`Deferred`, `Error`).
- Around line 141-142: Replace the two bullets with precise Kubernetes
conditions: state that Kubernetes does NOT support in-place CPU/memory resize
for Guaranteed Pods when cpuManagerPolicy=static or memoryManagerPolicy=Static
(mention both keys exactly: cpuManagerPolicy=static and
memoryManagerPolicy=Static and the term "Guaranteed Pods"), and note that if a
Pod/container is using swap memory then memory resize requires specifying
resizePolicy: { restartPolicy: RestartContainer } so the memory change is not
applied purely in-place (include the exact field name resizePolicy and
restartPolicy value RestartContainer).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 271ad332-8720-4be3-89ed-c9366a68b1b9
📒 Files selected for processing (3)
docs/en/developer/building_application/application_workloads/pod.mdxdocs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdxdocs/en/developer/building_application/operation_maintaining/add_vpa.mdx
✅ Files skipped from review due to trivial changes (1)
- docs/en/developer/building_application/application_workloads/pod.mdx
| Resize conditions include: | ||
|
|
||
| - `PodResizeInProgress`: kubelet can allocate the requested resources and is applying the change. | ||
| - `PodResizePending`: kubelet cannot apply the change immediately. | ||
| - `Infeasible`: The requested resize cannot be executed on the current node. | ||
| - `Deferred`: The requested resize is not currently possible, but might become possible later. | ||
| - `Error`: kubelet reports an error during resource allocation. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Kubernetes Pod resize conditions PodResizeInProgress PodResizePending Infeasible Deferred
💡 Result:
In Kubernetes, the status of in-place Pod resizing is managed through two primary Pod conditions: PodResizePending and PodResizeInProgress [1][2]. This mechanism replaces the older, deprecated status.resize field [1][3]. PodResizePending This condition indicates that the Kubelet has received a request to resize a Pod but cannot immediately grant the resources [3][2]. The reason and message fields provide specific details [3]: 1. Infeasible: The requested resize is impossible to fulfill on the current node [4][3]. This occurs if the node lacks total capacity, the Pod is a static Pod, or the requested configuration (such as certain combinations of swap or static resource manager policies) is not supported [4]. Once marked Infeasible, the Kubelet will not re-evaluate the request [4]. 2. Deferred: The resize is theoretically feasible on the node but cannot be granted at the moment, typically due to temporary resource contention [4][3]. The Kubelet will periodically re-evaluate these requests, prioritizing them based on Pod priority (PriorityClass), Quality of Service (QoS) class, and the duration the request has been in the Deferred state [5][3]. PodResizeInProgress This condition indicates that the Kubelet has accepted the resize request and is in the process of applying the changes [3][2]. It is active whenever the allocated resources differ from the actuated (applied) resources [4]. If an error occurs during the actuation phase, this condition is set with reason: Error, and the message field contains the specific error details [4][3]. Under normal operations, this condition is typically short-lived while the runtime applies the new resource limits [3]. Summary of Key States: - PodResizePending: Kubelet cannot resize now. - Reason: Infeasible (permanent, will not retry) [4][3]. - Reason: Deferred (temporary, will retry) [4][3]. - PodResizeInProgress: Kubelet has accepted and is applying the resize [3][2]. - Reason: Error (actuation failure) [4][3].
Citations:
- 1: [FG:InPlacePodVerticalScaling] Move pod resize status to pod conditions kubernetes/kubernetes#130733
- 2: https://kubernetes.io/blog/2025/05/16/kubernetes-v1-33-in-place-pod-resize-beta/
- 3: https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
- 4: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/1287-in-place-update-pod-resources/README.md
- 5: https://palark.com/blog/in-place-pod-resizing-kubernetes/
Fix/verify Error reason placement for Pod resize conditions.
Kubernetes in-place Pod resizing documents PodResizePending with reasons Infeasible and Deferred, while Error is associated with PodResizeInProgress when actuation fails. Update the doc snippet so Error is under PodResizeInProgress (or add an explicit citation if Error can also apply to PodResizePending).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx`
around lines 128 - 134, The doc incorrectly places the `Error` reason under
`PodResizePending`; update the snippet so `Error` is listed under
`PodResizeInProgress` (or add an explicit citation if you verify `Error` can
also appear under `PodResizePending`); specifically modify the bullets around
`PodResizeInProgress` and `PodResizePending` to show `Infeasible` and `Deferred`
as reasons for `PodResizePending` and move `Error` into the
`PodResizeInProgress` section (referencing the condition names
`PodResizeInProgress`, `PodResizePending`, and the reasons `Infeasible`,
`Deferred`, `Error`).
| - Pods managed by static `cpuManagerPolicy` or `memoryManagerPolicy` cannot be resized in place. | ||
| - Pods that use swap memory must use `RestartContainer` for memory requests. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Kubernetes in-place Pod resize cpuManagerPolicy memoryManagerPolicy swap memory limitations
💡 Result:
Kubernetes in-place Pod resize (CPU/memory) behavior with cpuManagerPolicy, memoryManagerPolicy, and swap is constrained as follows. 1) What “in-place Pod resize” can change - Kubernetes supports in-place resizing of CPU and memory resources for running Pods (Pod vertical scaling). Pod-level aggregate CPU/memory in spec.resources can be updated in place without requiring a restart; container-level resizePolicy still governs whether the specific container is restarted for the resource change. [1] 2) cpuManagerPolicy (CPU Manager static policy) limitations - In-place resize is not supported for Guaranteed Pods when CPU Manager policy is set to static. This is explicitly called out by the in-place resize KEP logic via a “guaranteed_pod_cpu_manager_static_policy” condition. [2] - Practical implication: if you run Guaranteed pods (i.e., meet Guaranteed QoS conditions) with cpuManagerPolicy=static, Kubernetes will mark the resize as infeasible rather than trying to update cpusets live. [2][3] 3) memoryManagerPolicy (Memory Manager static policy) limitations - In-place resize is not supported for Guaranteed Pods when Memory Manager static policy is configured. This is explicitly called out via “guaranteed_pod_memory_manager_static_policy” condition. [2] - Practical implication: if you run Guaranteed pods with memoryManagerPolicy=Static, Kubelet will treat resize requests as unsupported/infeasible for those pods. [2][4] 4) Swap limitations for in-place resize - Kubernetes explicitly limits memory resizing for Pods that use swap: Pods utilizing swap memory cannot resize memory requests unless the memory resizePolicy restartPolicy is RestartContainer. [5] - If swap is enabled/used in the pod/container, in-place memory resize without a container restart is not allowed because swap settings (cgroup memory.swap.max) must be recalculated/aligned with updated memory requests. [6][5] 5) ResizePolicy details that drive restarts - Container spec.containers[*].resizePolicy controls restart behavior per resource type. - resizePolicy restartPolicy NotRequired applies the resource change without restarting the container. [5] - resizePolicy restartPolicy RestartContainer restarts the container when applying the new resource values (often required for memory). [5] - If both CPU and memory are being resized and memory’s policy requires a restart, the container will be restarted. [7] 6) Memory limit decrease behavior (additional relevant limitation) - For memory limit decreases, Kubernetes enforces that memory limits cannot be decreased unless the memory resize policy is RestartContainer. (So NotRequired is not sufficient for shrinking memory limits.) [8] Bottom line / quick matrix - cpuManagerPolicy=static + Guaranteed pod: in-place resize is not supported. [2] - memoryManagerPolicy=Static + Guaranteed pod: in-place resize is not supported. [2] - swap enabled (Pod “utilizing swap”): memory resize requires memory resizePolicy restartPolicy=RestartContainer (can’t be done purely in-place). [5] - Otherwise: container resizePolicy determines whether CPU/memory changes are applied live or via container restart. [1][5]
Citations:
- 1: https://kubernetes.io/docs/tasks/configure-pod-container/resize-pod-resources/
- 2: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/1287-in-place-update-pod-resources/README.md
- 3: https://kubernetes.io/docs/concepts/workloads/resource-managers/
- 4: https://kubernetes.io/docs/tasks/administer-cluster/memory-manager/
- 5: https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
- 6: [KEP-1287] [InPlacePodVerticalScaling] Ensure swap limitations are handled as part of in-place pod resize kubernetes/kubernetes#130111
- 7: https://github.com/kubernetes/website/blob/dev-1.27/content/en/docs/tasks/configure-pod-container/resize-container-resources.md
- 8: [FG:InPlacePodVerticalScaling] Forbid memory limit decrease kubernetes/kubernetes#130183
Update the wording to match Kubernetes’ exact conditions for in-place resize (CPU/memory managers + swap)
- For
cpuManagerPolicy=static/memoryManagerPolicy=Static, Kubernetes does not support in-place Pod CPU/memory resize for Guaranteed Pods. - If the Pod/container is using swap memory, Kubernetes requires
resizePolicy: { restartPolicy: RestartContainer }for the memory resize (so memory changes aren’t applied purely in-place).
docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx (lines 141-142)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/developer/building_application/application_workloads/resize_pod_resources_in_place.mdx`
around lines 141 - 142, Replace the two bullets with precise Kubernetes
conditions: state that Kubernetes does NOT support in-place CPU/memory resize
for Guaranteed Pods when cpuManagerPolicy=static or memoryManagerPolicy=Static
(mention both keys exactly: cpuManagerPolicy=static and
memoryManagerPolicy=Static and the term "Guaranteed Pods"), and note that if a
Pod/container is using swap memory then memory resize requires specifying
resizePolicy: { restartPolicy: RestartContainer } so the memory change is not
applied purely in-place (include the exact field name resizePolicy and
restartPolicy value RestartContainer).
1 participant
Document Pod resize workflows and related VPA links. Verified with lint, build, and live-cluster e2e checks.
Summary by CodeRabbit