Kubernetes 1.33 - (Octarine): What changes for production

Kubernetes 1.33, Octarine, delivers 64 enhancements: 18 graduating to Stable, 20 entering Beta, 24 entering Alpha, and 2 deprecated or withdrawn. The release emphasizes production maturity across workload lifecycle, networking, storage, scheduling, and security while continuing investment in Dynamic Resource Allocation and node-level isolation.

The official theme is “Octarine: The Color of Magic,” inspired by Terry Pratchett’s Discworld. Its logo depicts a swamp dragon above the Unseen University, a Kubernetes moon, and 64 stars representing the release’s 64 enhancements. See the official Kubernetes 1.33 release announcement for the complete release story.

Key Highlights and Graduations

SIG Node and Workload Lifecycle

Stable: Sidecar containers

Sidecar containers are now generally available. Kubernetes implements a sidecar as an init container with:

restartPolicy: Always

This model ensures that sidecars start before application containers, continue running throughout the Pod lifecycle, and terminate after the main containers exit. Sidecars can also use startup, readiness, and liveness probes. Their out-of-memory score adjustments align with those of primary containers, reducing the risk that an auxiliary container is terminated prematurely under memory pressure.

Production impact: Operators can use a native, lifecycle-aware sidecar model for logging, telemetry, proxies, and other supporting processes instead of relying on ordering workarounds.

Beta: In-place Pod resource resize

CPU and memory resources for existing Pods can now be updated in place as a Beta capability. Before this enhancement, changing container resources in a workload template generally caused Pod replacement.

Potential use cases include:

Vertically scaling stateful processes without replacing their Pods.
Reducing resources when demand falls.
Allocating additional startup resources and reducing them after initialization.

Because this remains Beta, validate workload, runtime, and autoscaling behavior before adopting it broadly in production.

Stable: CPU Manager options for SMT alignment

The CPU Manager can now reject workloads whose exclusive CPU requests do not align with Simultaneous Multithreading configurations. On SMT-enabled systems, this allows policy enforcement around allocating complete core pairs rather than unintentionally sharing sibling threads.

Production impact: Latency-sensitive and CPU-isolated workloads can receive more predictable CPU placement.

Beta: CPU distribution across NUMA nodes

A CPU Manager policy option can distribute CPUs across NUMA nodes rather than concentrating allocations within one NUMA node. This is intended to improve resource utilization and performance for selected workloads on multi-NUMA systems.

Beta: Linux Pod user namespaces enabled by default

Support for user namespaces within Linux Pods remains Beta but is enabled by default in v1.33. Existing Pods are unaffected unless they explicitly opt in using:

spec:
  hostUsers: false

Production impact: User namespaces can improve isolation by separating container user identities from host user identities. Adoption still requires explicit workload changes and should be tested against container runtimes, storage, and security controls.

Beta: Fine-grained supplemental group control

The supplementalGroupsPolicy field in a Pod security context supports:

Merge: preserves backward compatibility by combining explicitly configured groups with memberships from the container image’s /etc/group.
Strict: applies only explicitly configured groups.

The capability is Beta and enabled by default, although the supplied release text also states that the SupplementalGroupsPolicy feature gate must be enabled. Operators should manually verify effective feature-gate settings in their chosen distribution.

Production impact: Strict can prevent implicit image-defined group memberships from granting unintended file access.

Beta: Pod `procMount` option enabled by default

The procMount capability is now an enabled-by-default Beta feature. It allows workloads to adjust the normal masking and read-only treatment of selected /proc paths.

This can support nested unprivileged containers used together with user namespaces. Because relaxing /proc restrictions affects isolation, security teams should review any workload that changes the default behavior.

Beta: Zero-duration `preStop` sleep

The Sleep action for a container preStop hook can now accept a zero-second duration. This provides a no-op lifecycle hook for configurations that require the hook to exist but do not require a shutdown delay.

Alpha: Configurable container restart delay

Kubelet-level configuration for tuning CrashLoopBackOff behavior continues as Alpha in v1.33. Operators should treat it as experimental and verify the exact configuration schema in the official changelog before testing it.

Alpha: Custom container stop signals

With the Alpha ContainerStopSignals feature gate enabled, a Pod can define a stop signal through:

lifecycle:
  stopSignal: SIGTERM

The Pod must also specify spec.os.name. If no custom signal is configured, Kubernetes falls back to the image-defined stop signal or the container runtime default.

Other Alpha node capabilities

Kubernetes 1.33 also introduces:

Node topology labels through the downward API.
Pod metadata.generation and status.observedGeneration.
Split L3/last-level-cache awareness for CPU Manager.
Linux Pressure Stall Information metrics based on cgroup v2.

These features remain experimental and should not be treated as stable operational interfaces.

SIG Network and Windows

Stable: Multiple Service CIDRs

The ServiceCIDR and IPAddress API objects are now stable. They provide a newer allocation model for unique ClusterIP addresses and allow administrators to expand Service IP capacity by creating additional ServiceCIDR objects.

Production impact: Clusters can increase the address space available to ClusterIP Services without relying on a single fixed Service CIDR.

Stable: nftables backend for kube-proxy

The nftables backend for kube-proxy is now stable and is designed to improve Service implementation performance and scalability.

The iptables backend remains the default on Linux for compatibility. Graduation to Stable does not automatically migrate existing nodes; operators must plan and validate any backend change.

Stable: Topology-aware routing and traffic distribution

Topology-aware routing is now stable, along with the Service field:

spec:
  trafficDistribution: PreferClose

PreferClose directs traffic toward nearby available endpoints based on network topology. EndpointSlice topology hints can also guide components such as kube-proxy toward same-zone endpoints.

Production impact: Multi-zone environments can reduce cross-zone traffic, latency, and associated transfer costs.

Beta: Direct Service Return for Windows kube-proxy

Direct Service Return support in Windows kube-proxy is now Beta. DSR allows response traffic to bypass the load balancer and return directly to the client, potentially reducing latency and load-balancer utilization.

Beta: DRA reporting for network interfaces

Standardized network-interface reporting through Dynamic Resource Allocation has graduated to Beta. This provides a more Kubernetes-native integration model for networking devices.

SIG Storage

Stable: Volume populators

Generic volume populators are now stable. A PersistentVolumeClaim can reference custom data sources through dataSourceRef, extending volume initialization beyond PVC clones and volume snapshots.

The mechanism includes:

A VolumePopulator custom resource.
A volume-data-source-validator controller.
Populator controllers that register supported data-source types.

The release announcement explicitly notes that the appropriate CRD must be installed before volume populators can be used.

Production impact: Platform teams can build controlled workflows that initialize volumes from organization-specific data sources.

Stable: PersistentVolume reclaim policy enforcement

Kubernetes now uses finalizers on relevant PersistentVolumes so that reclaim policies are honored even when a PV is deleted before its associated PVC.

Production impact: Storage assets using the Delete reclaim policy are less likely to leak because of an unexpected deletion order.

Stable: Portworx in-tree to CSI migration

Portworx file in-tree to CSI driver migration is included among the 18 Stable enhancements. The supplied excerpt does not provide configuration or migration details; Portworx users should manually verify the full Kubernetes 1.33 changelog before upgrading.

Stable: Recursive read-only mounts

Recursive read-only mounts are included in the Stable graduation list. Operational details are not present in the supplied release excerpt and require manual verification in the official release notes.

Beta: OCI images as Pod volumes

Pods can use an OCI image reference as a volume and mount its contents into containers. This makes it possible to package data separately from application images and share it among containers in a Pod.

Production impact: Separating binaries or data artifacts from the primary application image can simplify image construction and reduce duplication. The feature remains Beta and should be validated against the runtime and image-distribution environment.

SIG Scheduling and Autoscaling

Stable: Pod affinity label-key matching

The following fields are now stable in Pod affinity and anti-affinity terms:

matchLabelKeys
mismatchLabelKeys

They complement labelSelector and provide more precise control over which Pods should or should not be colocated.

Production impact: These fields can improve placement behavior during rolling updates and help controllers isolate related workload revisions.

Stable: Topology-spread handling for affinity and taints

Pod topology spread constraints now stably support:

nodeAffinityPolicy
nodeTaintsPolicy

The documented defaults are:

nodeAffinityPolicy: Honor
nodeTaintsPolicy: Ignore

These settings control whether node affinity and node taints are considered while calculating topology-spread skew.

Beta: Asynchronous scheduler preemption

The scheduler can process expensive preemption operations, including Pod deletion API calls, in parallel while continuing to schedule other Pods.

Production impact: Clusters with high Pod churn or frequent scheduling failures can experience less scheduler blocking during preemption.

Beta: Earlier processing of unscheduled Pods

When the scheduler’s activeQ is empty, it can process eligible Pods from backoffQ rather than becoming idle. This improves scheduling efficiency for Pods that are not currently backed off because of errors.

Alpha: Configurable HorizontalPodAutoscaler tolerance

HorizontalPodAutoscaler tolerance can be configured to dampen scaling reactions to small metric changes. This remains Alpha and should be evaluated only after verifying its feature gate and API details in the official release notes.

SIG Apps

Stable: Per-index backoff limits for Indexed Jobs

Indexed Jobs can define retry limits per index rather than relying only on the Job-wide backoffLimit.

Production impact: Failure of one index does not need to terminate unrelated indexes, giving batch platforms more precise control over independently processed tasks.

Stable: Job success policy

The stable .spec.successPolicy supports success criteria based on:

succeededIndexes
succeededCount
A combination of both

This is useful when partial completion is sufficient or when a leader’s successful completion determines the result of a larger Job.

SIG Auth and Security

Stable: Bound ServiceAccount token improvements

Bound ServiceAccount tokens now include security and auditing enhancements such as:

A unique JWT ID (JTI) claim.
Node information.
Support for node-specific restrictions.

Production impact: Token use can be audited more precisely, and node binding can reduce the opportunity to misuse a token elsewhere.

Beta: ClusterTrustBundle

ClusterTrustBundle is now a Beta, cluster-scoped resource for publishing X.509 trust anchors to workloads. It is intended to make it easier for in-cluster certificate signers to distribute root certificates.

Alpha: Credential-aware image pull authentication

An Alpha enhancement can require kubelet to perform an image-pull authentication check for each new credential set, including when the image is already present or the pull policy is IfNotPresent or Never.

Alpha: ServiceAccount-based kubelet image credentials

The kubelet on-disk credential provider can optionally fetch Kubernetes ServiceAccount tokens. This is intended to support secret-less integration with OIDC-compatible registry identity systems.

Dynamic Resource Allocation

Beta: Structured parameters and `resource.k8s.io/v1beta2`

Structured parameters remain Beta, with a simplified resource.k8s.io/v1beta2 API in v1.33. Additional changes include:

Users with the namespaced edit role can use DRA.
Kubelet supports rolling upgrades for DRA drivers deployed as DaemonSets.
ResourceSlice objects can remain unchanged during those upgrades.
Kubelet waits 30 seconds before cleanup after a driver unregisters.

Alpha: Device taints and tolerations

The DRADeviceTaints feature gate allows devices to carry taints and workloads to declare tolerations. Scheduling can pause while a taint exists, and Pods using a tainted device can be evicted.

Alpha: Prioritized device alternatives

With DRAPrioritizedList, DeviceRequest gains a firstAvailable field containing an ordered list of alternatives. A request can potentially allow no allocation when preferred hardware is unavailable.

Alpha: DRA administrative access

With DRAAdminAccess, use of adminAccess is restricted to users authorized to create ResourceClaim or ResourceClaimTemplate objects in namespaces labeled:

resource.k8s.io/admin-access: "true"

Alpha: Partitionable devices

DRAPartitionableDevices allows vendors to advertise multiple, potentially overlapping device partitions. The scheduler selects a compatible partition and prevents conflicting simultaneous allocations.

All four Alpha DRA capabilities also require the DynamicResourceAllocation feature gate.

SIG API Machinery and SIG CLI

Stable: CRD validation ratcheting

CRD validation ratcheting is one of the Stable graduations in v1.33. Detailed operational semantics are not included in the supplied excerpt and should be verified against the official release notes before changing CRD validation policies.

Beta: Declarative validation for Kubernetes-native types

Kubernetes contributors can use the internal validation-gen tooling to generate declarative validation rules. This is primarily an internal maintainability improvement rather than a user-facing API.

Stable: kubectl subresource support

The --subresource argument is generally available for commands including:

kubectl get
kubectl patch
kubectl edit
kubectl apply
kubectl replace

This allows supported resource subresources to be fetched or updated directly.

Alpha: `.kuberc` user preferences

kubectl introduces an opt-in .kuberc file that separates user preferences, aliases, and overrides from cluster credentials in kubeconfig.

Enable the Alpha capability with:

export KUBECTL_KUBERC=true

The default path is:

~/.kube/kuberc

An alternative file can be selected with the documented flag:

kubectl --kuberc /var/kube/rc

Because this interface is Alpha, avoid making it a mandatory dependency for production automation.

Deprecations, Removals, and Breaking Changes

Stable `Endpoints` API deprecated

The original stable Endpoints API is deprecated in Kubernetes 1.33. EndpointSlice, stable since v1.21, is its replacement and supports capabilities such as dual-stack networking while scaling better to large endpoint counts.

Affected users: Workloads, controllers, integrations, and scripts that directly read or write Endpoints.

Migration action: Move direct integrations to EndpointSlice. The release announcement does not specify a removal release, so no removal date should be assumed.

`Node.status.nodeInfo.kubeProxyVersion` removed

The following Node status field has been removed:

.status.nodeInfo.kubeProxyVersion

It was deprecated and disabled by default in v1.31 because the kubelet-populated value was not consistently accurate.

Operator action: Remove monitoring, inventory, admission, and automation dependencies on this field. The supplied sources do not identify a direct replacement.

In-tree `gitRepo` volume driver removed

The in-tree gitRepo volume driver implementation has been removed after being deprecated since v1.11.

Important compatibility details:

The gitRepo volume type remains in the Kubernetes API.
The API server can still admit Pods containing a gitRepo volume.
A kubelet with GitRepoVolumeDriver=false will not run those Pods and will return an error.
The kubelet feature gate can temporarily re-enable the driver for three versions.
Removal of the feature gate and in-tree plugin code is planned for v1.39.

Migration paths: Replace gitRepo volumes with an init container or a tool such as git-sync.

Operator action: Inventory manifests and generated workloads before upgrading worker nodes. API admission alone does not prove that such Pods will run on v1.33 kubelets.

Windows Pod host-network support removed

The Alpha implementation of host-network-only support for Windows Pods has been fully removed in v1.33 after its enhancement proposal was withdrawn.

This does not remove Windows HostProcess containers, which continue to provide host networking together with host-level access.

Operator action: Identify Windows workloads using the withdrawn host-network-only capability and move them to an alternative supported networking design. Do not treat HostProcess as an automatic drop-in replacement without a security review.

Upgrade Impact and Operational Notes

Before upgrading

Review the complete Kubernetes 1.33 changelog , especially its v1.33.0 Urgent Upgrade Notes, Deprecation, and API Change sections. Those sections are present in the supplied changelog index, but their full contents were not included in the source excerpt and therefore require manual verification.

Perform these workload and integration checks:

Locate controllers, scripts, or observability systems that depend directly on Endpoints; plan migration to EndpointSlice.
Remove dependencies on Node.status.nodeInfo.kubeProxyVersion.
Find Pods or templates that declare gitRepo volumes.
Review Windows Pods that depend on the withdrawn host-network-only capability.
Verify feature gates used by Alpha and Beta capabilities on every relevant component.
Confirm that clusters using volume populators have the required CRD and controller.
Validate DRA drivers and manifests against resource.k8s.io/v1beta2 where applicable.
Test any planned kube-proxy nftables migration separately; iptables remains the default.
Verify third-party CSI, CNI, device, admission, monitoring, and management integrations against their vendor support matrices.

Control-plane considerations

The supplied sources do not define a complete control-plane upgrade sequence or a supported version-skew matrix. Follow the upgrade procedure in the official Kubernetes documentation or the process provided by your Kubernetes distribution.

Control-plane-focused checks include:

Ensure admission and automation no longer assume the removed Node kube-proxy version field exists.
Review consumers of Endpoints and begin transitioning them to EndpointSlice.
Validate any use of the new ServiceCIDR and IPAddress APIs in a non-production environment.
Review RBAC for DRA, especially the ability of users with the namespaced edit role to use DRA.
Treat ClusterTrustBundle and other Beta APIs as non-GA interfaces.

Worker-node considerations

Worker upgrades carry the most direct impact from the gitRepo driver removal and Windows host-network withdrawal.

Before upgrading kubelets:

Ensure no required workload depends on the in-tree gitRepo driver.
Confirm whether GitRepoVolumeDriver is explicitly configured and document any temporary compatibility use.
Validate container-runtime behavior for user namespaces, image volumes, procMount, custom stop signals, and in-place resource resize.
Review CPU Manager policies on SMT and multi-NUMA hosts.
Validate DRA driver rolling upgrades and the 30-second unregister cleanup grace period.
Test Windows kube-proxy behavior if adopting Beta DSR.

The supplied sources do not state new minimum runtime, operating-system, etcd, or kubeadm dependency versions for the v1.33.0 release. Those requirements must be verified manually in the full changelog and installation documentation rather than inferred.

Conclusion

Kubernetes 1.33 moves several long-running capabilities into production-ready status, notably sidecar containers, multiple Service CIDRs, the nftables kube-proxy backend, topology-aware traffic distribution, volume populators, and stronger PersistentVolume lifecycle enforcement. At the same time, operators must address concrete compatibility risks around the deprecated Endpoints API, the removed Node kube-proxy version field, the removed in-tree gitRepo driver, and withdrawn Windows host-network support.

The most valuable upgrade strategy is to treat Octarine as both a maturity release and a migration checkpoint: adopt the Stable capabilities deliberately, test Beta features against real infrastructure, and keep Alpha functionality isolated from production dependencies.