Kubernetes 1.33: the sneak peek from an operations lens

Actualizado: 2026-05-03

The official Kubernetes 1.33 sneak peek was published on March 26 and the release lands on April 23 under the Octarine name. The note reads more soberly than 1.30 or 1.32: fewer fireworks and plenty of debt being closed. In 1.33, in-place pod resize matures, old endpoint annotations get cleaned up, and security changes land that are worth knowing before you meet them in the final changelog.

This post is a review from an operations perspective. I won’t list every KEP; other publications do that. I’ll stay with what changes day-to-day work and what requires prep. For previous version context, the analysis of Kubernetes 1.31: stabilizations is a useful reference for the maturation cadence.

Key takeaways

• In-place pod resize goes GA (KEP-1287): change CPU and memory without restarting the pod, with containerd 2.0+ or recent CRI-O.
• Sidecars now participate in in-place resize; the sidecar pattern closes its maturity cycle.
• Security changes: stricter PodSecurityStandards baseline, ServiceAccount token projection moving toward default.
• Two noise sources in the upgrade: endpoint annotation deprecation and GA feature-gate cleanup.
• This is a consolidation release, not a headline one: a 1.32 to 1.33 upgrade shouldn’t produce surprises with adequate preparation.

In-place pod resize finally GA

KEP-1287, in-place update of pod resources, moves to GA in 1.33 after being in beta since 1.27. Until now, changing a live pod’s CPU or memory required recreating it: destroy the container, reschedule, lose in-memory state, suffer cold starts. With in-place resize you can modify resources without restarting, provided the runtime (containerd 2.0+, recent CRI-O) supports cgroup updates.

The clearest practical case is workloads with uncertain spikes that were previously overprovisioned to avoid the kill-and-restart cycle. With live resize, a VPA can adjust memory upward when the pod starts breathing near the limit, with no latency impact. The same applies to in-cluster databases that tolerate restarts poorly: a Postgres managed by an operator can grow in memory without dropping connections.

The limits remain real:

• Not every resource can be changed live. Storage, hugepages, and some devices still require recreation.
• The kubelet needs to discover the update through the runtime; mixing nodes with containerd 1.7 and 2.x in the same cluster can produce inconsistent behavior if not aligned first.

The recommended plan: bring up a 1.33 environment with the newest runtime, test resize against a dummy workload measuring cold restart rate with PromQL, and only then authorize the feature in production.

Sidecars, the chapter that closes

Sidecar containers as initContainers with restartPolicy: Always reached stable in 1.29 and have been polished since. The news in 1.33 isn’t the pattern itself but per-container resource support during reallocation: sidecars also participate in in-place resize. A pod with Envoy as a sidecar and a main app no longer needs to rotate the whole pod to adjust proxy memory when mTLS load spikes.

A smaller but useful detail: the OpenTelemetry collector as a sidecar stops having that odd pattern of closing first and losing the last spans. With termination order clear since 1.29 and resize moveable, the sidecar pattern ends up the closest thing to what it promised in 2023: a first-class citizen of the pod.

Security changes worth reviewing

Several small changes that together tighten security defaults:

• The deprecation of AllowAllPodVolumeActions advances.
• PodSecurityStandards at baseline level start blocking patterns that in 1.32 only produced warnings. Concretely, writable hostPath and undeclared capabilities in the policy are noisier at admission.
• ServiceAccount token projection continues its path toward default. If there are still pods consuming the token mounted via traditional secret, migration to projected tokens with specific audience should be closed within two or three more releases.
• For those using kube-proxy ipvs: in 1.33 the deprecation messages toward nftables become more explicit. Using Cilium as CNI with kube-proxy replacement changes nothing; using traditional kube-proxy in ipvs mode, start migrating.

For managing workload security beyond the Kubernetes core, the analysis of Falco for runtime security provides the complementary detection layer.

What will be noisy in the upgrade

Two things we anticipate as noisy in the 1.33 upgrade:

Endpoint DeprecatedAnnotation. Controllers still reading endpoints.kubernetes.io/last-change-trigger-time will need to migrate to the equivalent field in EndpointSlice. Most popular tools already did this, but internal scripts rarely have.

--feature-gates cleanup. More flags graduating to GA cleans kubelet config but forces auditing node manifests that still include explicit flags. If Ansible or Talos is applying --feature-gates=InPlacePodVerticalScaling=true and 1.33 is applied, boot will fail with an obscure error. Better clean the flags before the upgrade.

My read

Octarine is a consolidation release, not a headline one. The interesting work is closing things that had been in beta for two or three cycles, reducing annotation debt, and continuing to tighten security defaults. For those running clusters, this is better than 1.30 with DRA debuting or 1.32 with so many changes that upgrade needed a window. A 1.32 to 1.33 upgrade shouldn’t produce surprises if you do the homework of auditing flags and deprecations.

The point most worth noting is in-place resize GA. It’s the feature that most clearly changes how you think about resource allocation in dynamic workloads. For clusters with many long-lived pods and unpredictable traffic, it removes an entire category of incidents: forced restarts for resource adjustment. That alone justifies planning the upgrade once 1.33.0 is available, waiting perhaps for 1.33.1 or 1.33.2 for production as is prudent practice.