Updated: 2026-07-12

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 beta and ships enabled by default (KEP-1287): change CPU and memory without restarting the pod, through the new resize subresource.

  • Sidecars reach GA in this same release and now participate in live resize too; the sidecar pattern closes its maturity cycle.

  • Security changes: ServiceAccount tokens get tied more tightly to the node, user namespaces are on by default, and ClusterTrustBundles reaches beta.

  • Two noise sources in the upgrade: the endpoints API deprecation and the locking of feature-gates that already reached GA.

  • 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, now in beta

KEP-1287, in-place update of pod resources, moves to beta in 1.33 and ships with the InPlacePodVerticalScaling feature-gate enabled by default, after being in alpha 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 supports the underlying cgroup update: containerd has had it since 1.6.9, and CRI-O since it implemented the UpdateContainerResources API. The operation now goes through a dedicated resize subresource (replacing the now-deprecated status.resize field), with PodResizePending and PodResizeInProgress conditions to track the change.

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, implemented as initContainers with restartPolicy: Always, reached beta with the gate on by default in 1.29 and have been polished since. The news in 1.33 is that the pattern finally reaches GA (the SidecarContainers feature-gate is locked to its default value and slated for removal in 1.36), and along with it, sidecars also participate in live resize, even though resize itself is still beta. 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 component with native, first-tier support inside the pod.

Security changes worth reviewing

Several small changes that together tighten security defaults:

  • Bound Service Account Tokens get stronger: the token now also includes the node name in its claims, so a pod’s identity is tied more closely to the node it runs on, and a leaked token loses some of its usefulness outside that context.

  • User namespaces are on by default for pods that request them, adding the extra UID/GID isolation that gives you against a container escape. It does require containerd 2.0+ and runc 1.2+ on the nodes.

  • ClusterTrustBundles reaches beta: a native object for distributing trusted CA bundles without leaning on hand-rolled ConfigMaps.

  • For those using kube-proxy in ipvs mode: the nftables mode keeps moving toward GA as the medium-term replacement for iptables and ipvs, though iptables stays the default even once nftables graduates. Using Cilium with kube-proxy replacement, this changes nothing; on traditional kube-proxy, it is worth trying nftables on a test node.

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.

Locking of --feature-gates that reach GA. Once a feature-gate reaches GA, its value gets locked and can no longer be flipped off; SidecarContainers is the clear case in this release, locked to true with removal announced for 1.36. If Ansible or Talos is explicitly setting that gate to false (or any other already-locked gate) in node manifests, boot fails with an inconsistent-flag error. Better to audit and clean those explicit 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 watching is in-place resize, now beta and on by default. It’s the feature that most clearly changes how you think about resource allocation in dynamic workloads, even if its GA graduation will have to wait for a later release. For clusters with many long-lived pods and unpredictable traffic, it aims to remove an entire category of incidents: forced restarts for resource adjustment. That alone justifies planning the upgrade once 1.33.0 is available, trying resize out in staging, and waiting perhaps for 1.33.1 or 1.33.2 for production as is prudent practice.