feat(blog): Add new blog featuring adoption of in-place Pod resource updates#976
Conversation
… updates This commit features a blog post about the adoption of in-place Pod resource updates in Gardener.
… section This commit updates the Vertical Pod Autoscaler section with few wording improvements. Also: - Fix graph edges titles to reflect logic operation rather than technical endpoint/function calls. - Rewording in the in-place updates benefits section.
✅ Deploy Preview for gardener-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (2)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Pod resource updates
n-boshnakov
left a comment
There was a problem hiding this comment.
Thank you for the blog, @vitanovs! I only have a minor suggestion to leave.
Co-authored-by: Nikolay Boshnakov <nikolay.boshnakov@sap.com>
|
/assign |
ialidzhikov
left a comment
There was a problem hiding this comment.
Thanks for taking the time write a blog pod about the biggest achievement in VPA since its introduction - in-place updates! 🎉
Suggestions inline ⬇️
|
|
||
|  | ||
|
|
||
| With sections covering `VerticalPodAutoscaler` resource overviews (segregated by _update mode_) and panels displaying success rates per resource, the new dashboard can be used for both monitoring and generating status reports on applied resource recommendations. |
There was a problem hiding this comment.
We could add a section with the achievements on our side. We together checked with you that in dev environments 90% of the Pod evictions were replaced with in-place updates.
We should share this success story with concrete numbers and screenshots from the monitoring dashboard. Maybe the number is even bigger now.
There was a problem hiding this comment.
I suggest adding a sentence about it.
Concrete suggestion:
diff --git a/website/blog/2026/05/05-19-in-place-pod-resource-updates.md b/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
index 43d9e5b7..7dcde589 100644
--- a/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
+++ b/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
@@ -83,6 +83,8 @@ An identical situation can be witnessed in the Gardener _monitoring_ and _loggin
Another good example of a Kubernetes flaw that could have been resolved by using _in-place_ resources _update mode_ has to do with the `kube-scheduler` and its prior behavior of getting `Pod`s, with volumes, scheduled on `Node`s that have already reached their volume attachment limit. Documented in a dedicated Kubernetes [issue](https://github.com/kubernetes/kubernetes/issues/126921), this problem had appeared when the CSI `Node` plugin `Pod` gets restarted during _eviction_, exactly how VPA was configured to do at the time of reporting it.
During the gap between the deletion and the new `Pod` creation, the `CSINode` object temporarily has an empty drivers section. The `kube-scheduler`'s `NodeVolumeLimits` plugin treated this missing information as "no limit" and incorrectly scheduled volume-backed pods to fully-saturated `Node`s.
+The impact of adopting _in-place_ resource updates is best illustrated by the numbers: enabling the feature on the `Seed` clusters and the runtime cluster results in roughly 98% of the `Pod` resource updates being applied _in-place_, drastically reducing the amount of disruptive `Pod` recreations across the Gardener landscape. The exact ratio may vary from one Seed or runtime cluster to another, depending on its configuration.
+
## Monitoring
Performing configuration migrations can become an exhausting task without a convenient dashboard to evaluate the process state. For this reason, as part of the effort to support _in-place_ Pod resource updates, we introduced a brand new _dashboard_ for the `vpa-updater` component.
There was a problem hiding this comment.
Thanks for the suggestion, pushed it with the latest commits.
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
ialidzhikov
left a comment
There was a problem hiding this comment.
Final 2 suggestions, rest lgtm
|
|
||
|  | ||
|
|
||
| With sections covering `VerticalPodAutoscaler` resource overviews (segregated by _update mode_) and panels displaying success rates per resource, the new dashboard can be used for both monitoring and generating status reports on applied resource recommendations. |
There was a problem hiding this comment.
I suggest adding a sentence about it.
Concrete suggestion:
diff --git a/website/blog/2026/05/05-19-in-place-pod-resource-updates.md b/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
index 43d9e5b7..7dcde589 100644
--- a/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
+++ b/website/blog/2026/05/05-19-in-place-pod-resource-updates.md
@@ -83,6 +83,8 @@ An identical situation can be witnessed in the Gardener _monitoring_ and _loggin
Another good example of a Kubernetes flaw that could have been resolved by using _in-place_ resources _update mode_ has to do with the `kube-scheduler` and its prior behavior of getting `Pod`s, with volumes, scheduled on `Node`s that have already reached their volume attachment limit. Documented in a dedicated Kubernetes [issue](https://github.com/kubernetes/kubernetes/issues/126921), this problem had appeared when the CSI `Node` plugin `Pod` gets restarted during _eviction_, exactly how VPA was configured to do at the time of reporting it.
During the gap between the deletion and the new `Pod` creation, the `CSINode` object temporarily has an empty drivers section. The `kube-scheduler`'s `NodeVolumeLimits` plugin treated this missing information as "no limit" and incorrectly scheduled volume-backed pods to fully-saturated `Node`s.
+The impact of adopting _in-place_ resource updates is best illustrated by the numbers: enabling the feature on the `Seed` clusters and the runtime cluster results in roughly 98% of the `Pod` resource updates being applied _in-place_, drastically reducing the amount of disruptive `Pod` recreations across the Gardener landscape. The exact ratio may vary from one Seed or runtime cluster to another, depending on its configuration.
+
## Monitoring
Performing configuration migrations can become an exhausting task without a convenient dashboard to evaluate the process state. For this reason, as part of the effort to support _in-place_ Pod resource updates, we introduced a brand new _dashboard_ for the `vpa-updater` component.
Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
…ce updated Co-authored-by: Ismail Alidzhikov <9372594+ialidzhikov@users.noreply.github.com>
|
@ialidzhikov: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this:
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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ialidzhikov, n-boshnakov The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
LGTM label has been added. DetailsGit tree hash: 8942ac00c0babc57eb2521760652023a25d046d3 |
How to categorize this PR?
/kind enhancement
What this PR does / why we need it:
This PR features a new brief blog post about the adoption of in-place Pod resource updates in Gardener.
Which issue(s) this PR fixes:
Part of gardener/gardener#12955