Add blog for Pod Level In Place resize beta phase

Signed-off-by: Dixita <ndixita@google.com>

Author: ndixita

content/en/blog/_posts/2026/inplace-pod-level-resources-beta.md

@@ -0,0 +1,112 @@
+---
+layout: blog
+title: "Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta"
+draft: true
+slug: kubernetes-v1-36-inplace-pod-level-resources-beta
+author: Narang Dixita Sohanlal (Google)
+---
+
+Following the graduation of Pod-Level Resources to Beta in v1.34 and the General Availability (GA) of In-Place Pod Vertical Scaling in v1.35, the Kubernetes community is thrilled to announce that **In-Place Pod-Level Resources Vertical Scaling has graduated to Beta in v1.36!**
+
+This feature is now enabled by default via the `InPlacePodLevelResourcesVerticalScaling` feature gate. It allows users to update the aggregate Pod resource budget (`.spec.resources`) for a running Pod, **often without requiring a container restart.**
+
+## Why Pod-level in-place resize?
+
+The Pod-level resource model simplified management for complex Pods (such as those with sidecars) by allowing containers to share a collective pool of resources. In v1.36, you can now adjust this aggregate boundary on-the-fly.
+
+This is particularly useful for Pods where containers do not have individual limits defined. These containers automatically scale their effective boundaries to fit the newly resized Pod-level dimensions, allowing you to expand the shared pool during peak demand without manual per-container recalculations.
+
+## Resource inheritance and the `resizePolicy`
+
+When a Pod-level resize is initiated, the Kubelet treats the change as a resize event for every container that inherits its limits from the Pod-level budget. To determine whether a restart is required, the Kubelet consults the `resizePolicy` defined within individual containers:
+
+*   **Non-disruptive Updates:** If a container's `restartPolicy` is set to `NotRequired`, the Kubelet attempts to update the cgroup limits dynamically via the Container Runtime Interface (CRI).
+*   **Disruptive Updates:** If set to `RestartContainer`, the container will be restarted to apply the new aggregate boundary safely.
+
+> **Note:** Currently, `resizePolicy` is not supported at the Pod level. The Kubelet always defers to individual container settings to decide if an update can be applied in-place or requires a restart.
+
+## Example: ccaling a shared resource pool
+
+In this scenario, a Pod is defined with a 2 CPU pod-level limit. Because the individual containers do not have their own limits defined, they share this total pool.
+
+### 1. Initial Pod specification
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: shared-pool-app
+spec:
+  resources: # Pod-level limits
+    limits:
+      cpu: "2"
+      memory: "4Gi"
+  containers:
+  - name: main-app
+    image: my-app:v1
+    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
+  - name: sidecar
+    image: logger:v1
+    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
+```
+
+### 2. The resize operation
+
+To double the CPU capacity to 4 CPUs, apply a patch using the `resize` subresource:
+
+```bash
+kubectl patch pod shared-pool-app --subresource resize --patch \
+  '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'
+```
+
+## Node-Level reality: feasibility and safety
+
+Applying a resize patch is only the first step. The Kubelet performs several checks and follows a specific sequence to ensure node stability:
+
+### 1. The feasibility check
+
+Before admitting a resize, the Kubelet verifies if the new aggregate request fits within the Node's allocatable capacity. If the Node is overcommitted, the resize is not ignored; instead, the `PodResizePending` condition will reflect a `Deferred` or `Infeasible` status, providing immediate feedback on why the "envelope" hasn't grown.
+
+### 2. Update sequencing
+
+To prevent resource "overshoot," the Kubelet coordinates the cgroup updates in a specific order:
+*   **When Increasing:** The Pod-level cgroup is expanded first, creating the "room" before the individual container cgroups are enlarged.
+*   **When Decreasing:** The container cgroups are throttled first, and only then is the aggregate Pod-level cgroup shrunken.
+
+## Observability: tracking resize status
+
+With the move to Beta, Kubernetes uses **Pod Conditions** to track the lifecycle of a resize:
+
+*   **`PodResizePending`**: The spec is updated, but the Node hasn't admitted the change (e.g., due to capacity).
+*   **`PodResizeInProgress`**: The Node has admitted the resize (`status.allocatedResources`) but the changes aren't yet fully applied to the cgroups (`status.resources`).
+
+```yaml
+status:
+  allocatedResources:
+    cpu: "4"
+  resources:
+    limits:
+      cpu: "4"
+  conditions:
+  - type: PodResizeInProgress
+    status: "True"
+```
+
+## Constraints and requirements
+
+*   **cgroup v2 Only:** Required for accurate aggregate enforcement.
+*   **CRI Support:** Requires a container runtime that supports the `UpdateContainerResources` CRI call (e.g., containerd v2.0+ or CRI-O).
+*   **Feature Gates:** Requires `PodLevelResources`, `InPlacePodVerticalScaling`, `InPlacePodLevelResourcesVerticalScaling`, and `NodeDeclaredFeatures`.
+*   **Linux Only:** Currently exclusive to Linux-based nodes.
+
+## What's next?
+
+As we move toward General Availability (GA), the community is focusing on **Vertical Pod Autoscaler (VPA) Integration**, enabling VPA to issue Pod-level resource recommendations and trigger in-place actuation automatically.
+
+## Getting started and providing feedback
+
+We encourage you to test this feature and provide feedback via the standard Kubernetes communication channels:
+
+*   Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
+*   [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
+*   [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/sig%2Fnode)