Share CPU and memory across containers in a Pod

A model server spends CPU on preprocessing while a helper handles request metadata. Their busiest periods do not always coincide. Giving each container a fixed budget sized for its individual peak can leave capacity unused inside the same Pod.

Kubernetes Pod-level resources let you declare an aggregate resource budget under spec.resources. The feature is beta since Kubernetes 1.34 and enabled by default through PodLevelResources. Containers can share idle resources within that budget. This article covers CPU and host memory on Linux, not GPU allocation or GPU memory. Resource management documentation.

The design question is whether the containers form one resource-sharing unit. Sharing a budget makes sense only when the team understands how they compete.

Model concurrent demand

Imagine a service with a main process that briefly needs one CPU and a helper that briefly needs half a CPU. If those peaks rarely overlap, the observed Pod peak may be lower than the sum of their separate peaks. If every request triggers both processes together, the opposite assumption is more realistic.

Use a representative traffic trace to compare concurrent demand. Record per-container usage and total Pod usage at the same timestamps. Summing unrelated maximum values from different periods is not a measurement of simultaneous demand.

Memory needs extra care. Two containers may retain caches after a burst even when their CPUs become idle. A shared memory ceiling does not coordinate cache eviction or protect the main process from a helper that keeps allocating.

These measurements build on right-sizing resource requests and limits.

Inspect a Pod-wide budget

This disposable example requires Kubernetes 1.34 or later on Linux, PodLevelResources enabled on the relevant components, permissions to create Pods, and access to the Python image. It has two sleeping containers so you can inspect the resource configuration without running a load test.

Save it as pod-budget-demo.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: pod-budget-demo
---
apiVersion: v1
kind: Pod
metadata:
  name: shared-budget
  namespace: pod-budget-demo
spec:
  restartPolicy: Never
  resources:
    requests:
      cpu: "500m"
      memory: "256Mi"
    limits:
      cpu: "1"
      memory: "512Mi"
  containers:
    - name: main
      image: python:3.12-slim
      command: ["python", "-c", "import time; time.sleep(300)"]
    - name: helper
      image: python:3.12-slim
      command: ["python", "-c", "import time; time.sleep(300)"]

The values describe the Pod as a whole: this is not a one-CPU allowance for each container. The image tag is a convenience for the fixture; use approved digests for reproducible workloads.

kubectl apply -f pod-budget-demo.yaml
kubectl get pod shared-budget -n pod-budget-demo -o yaml
kubectl describe pod shared-budget -n pod-budget-demo

Inspect the stored spec.resources and the actual container specifications. Namespace defaults or admission policies may add container settings, so inspect the admitted object rather than assuming the submitted YAML is the complete result. The Pod-level resource task guide covers the field hierarchy and prerequisites.

This fixture demonstrates configuration only. A low CPU reading from sleeping processes would say nothing about the budget needed by a real inference server.

Preserve the boundaries that matter

Pod-level budgets can coexist with container-level settings. Keep an explicit container bound where a helper must not consume too much of the shared envelope, and review the combined configuration against the cluster's validation rules. An individual container limit remains relevant; a larger Pod budget is not permission for that container to ignore its own limit.

Also distinguish an ordinary CPU budget from exclusive CPU placement, NUMA alignment, or memory-manager behavior. Those resource-manager integrations have separate prerequisites and feature gates. Review the Pod-level resource managers documentation before applying this model to workloads that rely on dedicated cores or topology alignment.

Live resizing is another separate feature. This example sets the budget at creation time; it does not extend the stable container-resize procedure automatically to the Pod-wide envelope. Use the container resizing guide for that existing workflow.

After inspection, remove the disposable resources:

kubectl delete namespace pod-budget-demo

Apply the result to Polyaxon services

Polyaxon makes resource decisions reusable across notebooks, sandboxes, training jobs, and inference experiments. Start with the documented sandbox resource configuration and capture an appropriate CPU, memory, and GPU profile in a scheduling preset. Teams can then use a known profile for interactive development and a different one for batch execution.

For a service with cooperating containers, measure their simultaneous demand and retain the resource configuration with the run's benchmark metrics. Compare useful throughput, memory peaks, throttling, and failures before changing the standard profile. For interactive services, combine resource sizing with Polyaxon's timeouts and idle culling so an unused notebook does not hold its allocation indefinitely.

The documented run.container.resources configuration sets container resources. Adopting a Kubernetes Pod-wide budget additionally requires the deployed workload integration to carry spec.resources. Inspect the generated Pod to confirm the aggregate budget and individual limits before attributing a benchmark result to resource sharing.