Kubernetes 1.35: In-Place Pod Resource Updates and AI Model Image Volumes

Kubernetes 1.35, released in January 2026 and now supported on Amazon EKS and EKS Distro, marks a significant milestone in container orchestration—particularly for AI/ML workloads. This release introduces In-Place Pod Resource Updates, allowing you to resize CPU and memory without restarting pods, and Image Volumes, a game-changer for delivering large AI models using OCI container images. In this exhaustive guide, we’ll explore these features with production-ready patterns, performance benchmarks, and architectural considerations for enterprise deployments.

Executive Summary: What’s New in Kubernetes 1.35

Before diving deep, here’s what platform engineers and architects need to know:

• In-Place Pod Resource Updates (GA): Change CPU/memory requests and limits on running pods without restarts
• PreferSameNode Traffic Distribution: Optimize service-to-service latency by preferring local endpoints
• Node Topology Labels via Downward API: Expose node labels to pods for topology-aware scheduling decisions
• Image Volumes for AI Models: Mount OCI container images as read-only volumes—perfect for multi-gigabyte AI models
• Enhanced Sidecar Container Support: Native lifecycle management for sidecar patterns

In-Place Pod Resource Updates: The End of Restart-Driven Scaling

Historically, changing a pod’s resource requests or limits required deleting and recreating the pod. For stateful workloads, long-running batch jobs, or latency-sensitive services, this was unacceptable. Kubernetes 1.35 finally graduates In-Place Pod Vertical Scaling to General Availability (GA), allowing you to resize pods dynamically.

How It Works Under the Hood

When you update a pod’s resource spec, the kubelet coordinates with the container runtime (containerd/CRI-O) to resize the cgroup limits without stopping the container process. The container’s PID 1 continues running uninterrupted.

sequenceDiagram
    participant User as kubectl/API
    participant API as Kube API Server
    participant Kubelet as Kubelet
    participant CRI as Container Runtime
    participant Container as Container Process
    
    User->>API: PATCH pod resources
    API->>Kubelet: Watch detects change
    Kubelet->>CRI: UpdateContainerResources()
    CRI->>Container: Update cgroup limits
    Note over Container: Process continues running
    CRI-->>Kubelet: Success
    Kubelet-->>API: Update pod status

Enabling In-Place Resource Resize

The feature requires explicit opt-in via the resizePolicy field in your container spec:

apiVersion: v1
kind: Pod
metadata:
  name: ml-inference-server
spec:
  containers:
  - name: model-server
    image: myregistry/llm-server:v2.1
    resources:
      requests:
        cpu: "2"
        memory: "8Gi"
      limits:
        cpu: "4"
        memory: "16Gi"
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired  # Resize without restart
    - resourceName: memory
      restartPolicy: RestartContainer  # Memory changes require restart

Important: Memory resizing often requires RestartContainer because many applications allocate memory pools at startup (e.g., JVM heap, Go runtime). CPU resizing is typically safe without restarts.

Resizing a Running Pod

Use kubectl patch to update resources on the fly:

# Scale up CPU during peak traffic
kubectl patch pod ml-inference-server --subresource=resize -p '{
  "spec": {
    "containers": [{
      "name": "model-server",
      "resources": {
        "requests": {"cpu": "4"},
        "limits": {"cpu": "8"}
      }
    }]
  }
}'

# Verify the resize status
kubectl get pod ml-inference-server -o jsonpath='{.status.resize}'
# Output: "InProgress" then "Completed"

Production Use Cases

PreferSameNode Traffic Distribution: Reducing Cross-Node Latency

In multi-replica deployments, Kubernetes services distribute traffic across all endpoints regardless of their node location. This can introduce unnecessary network hops. Kubernetes 1.35 introduces PreferSameNode traffic distribution, which prioritizes endpoints on the same node as the caller.

apiVersion: v1
kind: Service
metadata:
  name: cache-service
spec:
  selector:
    app: redis-cache
  ports:
  - port: 6379
  trafficDistribution: PreferSameNode  # New in 1.35!

This is particularly valuable for:

• Sidecar-to-main-container communication: Envoy proxies calling local application pods
• Caching layers: Prefer local Redis/Memcached replicas
• Logging collectors: FluentBit sending to local aggregators

Image Volumes: Delivering AI Models at Scale

This is the feature AI/ML platform teams have been waiting for. Image Volumes allow you to package AI models (often 10-100+ GB) as OCI container images and mount them as read-only volumes in your pods. The model image is pulled separately from the application image, enabling independent versioning and caching.

The Problem with Traditional Model Delivery

Before Image Volumes, teams struggled with model delivery:

• Baking models into application images: 50GB+ images, slow pulls, version coupling
• S3/GCS download at startup: Cold start delays, network bandwidth costs
• Persistent Volumes: Complex provisioning, no immutability guarantees
• Init containers: Serial download delays, no caching across nodes

Image Volumes Architecture

graph TB
    subgraph Registry ["OCI Registry"]
        AppImg["App Image (500MB)"]
        ModelImg["Model Image (50GB)"]
    end
    
    subgraph Node ["Kubernetes Node"]
        Cache["Image Cache"]
        Pod["Inference Pod"]
        AppContainer["App Container"]
        ModelVol["Model Volume (Read-Only)"]
    end
    
    AppImg --> Cache
    ModelImg --> Cache
    Cache --> AppContainer
    Cache --> ModelVol
    ModelVol --> AppContainer
    
    style ModelImg fill:#E1F5FE,stroke:#0277BD
    style ModelVol fill:#C8E6C9,stroke:#2E7D32

Creating a Model Image

Package your model as an OCI artifact using a minimal Dockerfile:

# Dockerfile.model
FROM scratch
COPY ./llama-70b-q4/ /models/llama-70b/

# Build and push
# docker build -f Dockerfile.model -t myregistry/models/llama-70b:v1 .
# docker push myregistry/models/llama-70b:v1

Mounting the Model Image as a Volume

apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
  - name: inference-server
    image: myregistry/inference-server:v2
    volumeMounts:
    - name: model-volume
      mountPath: /models
      readOnly: true
    env:
    - name: MODEL_PATH
      value: /models/llama-70b
  volumes:
  - name: model-volume
    image:
      reference: myregistry/models/llama-70b:v1
      pullPolicy: IfNotPresent  # Leverage node-level caching!

Benefits for AI/ML Workloads

• Decoupled versioning: Update model or app independently
• Node-level caching: Model pulled once per node, shared across pods
• Immutability: OCI content-addressable storage guarantees consistency
• Registry integration: Use existing ACR/ECR/GCR infrastructure
• Parallel pulls: Model and app images pulled simultaneously

Node Topology Labels via Downward API

Applications can now access node topology labels (zone, region, instance type) via the Downward API without querying the Kubernetes API server:

apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-app
spec:
  containers:
  - name: app
    image: myapp:v1
    env:
    - name: NODE_ZONE
      valueFrom:
        fieldRef:
          fieldPath: metadata.annotations['topology.kubernetes.io/zone']
    - name: NODE_INSTANCE_TYPE
      valueFrom:
        fieldRef:
          fieldPath: metadata.annotations['node.kubernetes.io/instance-type']

Use cases include locality-aware caching, zone-specific configurations, and cost attribution in multi-tenant clusters.

Migration and Upgrade Considerations

When upgrading to Kubernetes 1.35, consider the following:

Pre-Upgrade Checklist

• Audit deprecated API usage with kubent tool
• Test In-Place Resource Resize with non-production workloads first
• Verify container runtime supports cgroup v2 (required for resize)
• Update Helm charts and operators to 1.35-compatible versions
• Review PodDisruptionBudgets—resize operations don’t trigger disruption

Performance Benchmarks

Our testing on EKS 1.35 with c6i.8xlarge nodes showed:

Key Takeaways

• In-Place Pod Resource Updates eliminate the restart tax for vertical scaling—essential for stateful and latency-sensitive workloads.
• Image Volumes solve AI model delivery at scale with immutable, cacheable, independently versioned model artifacts.
• PreferSameNode traffic distribution reduces cross-node latency for sidecar and caching patterns.
• Node Topology Labels via Downward API enable topology-aware applications without API server queries.
• Start planning Ingress NGINX migration now—security patches end March 2026.

Conclusion

Kubernetes 1.35 is a landmark release for AI/ML infrastructure. The combination of In-Place Resource Updates and Image Volumes addresses two of the most painful operational challenges in running inference workloads at scale. Platform teams should prioritize adoption of these features, particularly Image Volumes for model delivery, as they fundamentally simplify MLOps pipelines. As always, test thoroughly in non-production environments before rolling out to critical workloads.

References

• Kubernetes 1.35 Release Announcement
• Amazon EKS Support for Kubernetes 1.35
• In-Place Pod Resource Update Documentation
• Image Volumes Documentation