Kubernetes 1.33 “Octarine”: What’s New and What It Means For You

Kubernetes 1.33, codenamed “Octarine: The Color of Magic” (a nod to Terry Pratchett’s Discworld series), was released on April 23, 2025. This update brings significant improvements to the popular container orchestration platform with 64 enhancements across the board – 18 graduated to stable, 20 moved to beta, and 24 new alpha features were introduced.

In this blog post, we’ll explore the most important changes in Kubernetes 1.33 and what they mean for you and your organization.

Key Highlights

• Native sidecar containers now officially stable
• In-place Pod vertical scaling promoted to beta
• User namespaces support for improved security
• kubectl subresource support graduated to stable
• New generation field for Pods to better track changes
• OCI images as volumes (alpha)
• HorizontalPodAutoscaler configurable tolerance (alpha)

Native Sidecar Containers (Stable)

One of the most anticipated features to reach stable status in Kubernetes 1.33 is native support for sidecar containers. While the sidecar pattern (using additional containers that extend and enhance the main container) has been common in Kubernetes since nearly the beginning, it previously lacked built-in support in the platform.

In 1.33, the SidecarContainers feature has graduated to stable, allowing you to properly define sidecar containers with better lifecycle management. This means:

• Sidecar containers start before and terminate after the main application containers
• Proper handling of Pod initialization and graceful shutdown scenarios
• Support for PostStart and PreStop lifecycle hooks
• Full support for all probe types (startup, readiness, liveness)
• Readiness probes that influence overall Pod readiness

To use sidecar containers, you define them within the initContainers section of your Pod spec with a restartPolicy: Always

This feature is particularly valuable for service mesh implementations, logging agents, metrics collectors, and network proxies, where you need containers to run for the entire Pod lifecycle but with controlled startup and termination behavior.

In-Place Pod Vertical Scaling (Beta)

Kubernetes 1.33 promotes in-place Pod vertical scaling to beta status. This is a game-changer for resource management, as it allows you to adjust CPU and memory allocations for running Pods without needing to delete and recreate them.

Prior to this feature, changing resource requests or limits for a Deployment or StatefulSet would cause Kubernetes to replace each Pod to apply the new resources, resulting in application downtime. Now, the kubelet can update a running container’s resources directly when possible.

This capability is particularly valuable for:

• Stateful applications or databases where Pod recreation is disruptive
• Long-running processes that need resource adjustments on the fly
• Workloads that experience variable resource demands throughout the day
• Environments where you want to scale down resources during low usage periods

Since it’s now a beta feature in 1.33, the InPlacePodVerticalScaling feature gate is enabled by default, meaning you don’t need to take any special action to use it in most clusters.

For example, to increase the CPU resources for a running Pod:

kubectl patch pod mypod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/resources/requests/cpu", "value": "2"}]'

Note that certain changes (like decreasing memory limits under some conditions) might still require a restart or be disallowed for safety reasons. It’s also worth mentioning that the Vertical Pod Autoscaler (VPA) doesn’t yet support resizing Pods in-place in 1.33, but this integration is expected in future releases.

User Namespaces Support for Pod Security (Beta)

A major security enhancement in Kubernetes 1.33 is the improved support for Linux user namespaces for Pods. This feature, which has been in development since 2016 (KEP-127), is now enabled by default in its beta status.

User namespaces isolate the user and group IDs used inside a container from those on the host. This provides a powerful security boundary that allows you to:

• Run containers as “root” within the container while being mapped to a non-privileged user on the host
• Significantly reduce the damage a compromised container can do to the host or other Pods
• Mitigate several high and critical security vulnerabilities (like CVE-2024-21626)

To use this feature, simply set hostUsers: false in your Pod spec

This setting won’t impact existing Pods unless you manually opt in. The feature is particularly valuable for security-sensitive workloads and multi-tenant clusters. With user namespaces enabled, Kubernetes will also relax certain Pod Security Standards restrictions in a controlled way for these Pods, as they no longer present the same security risks.

kubectl Subresource Support (Stable)

The ability to work with subresources through kubectl has graduated to stable in 1.33. This enhancement adds a new --subresource flag to key kubectl commands like get, patch, edit, apply, and replace.

This makes subresources like status, scale, and resize accessible and manageable across all supported resource types, including custom resources. For example:

kubectl get deployment/mydep --subresource=status

kubectl patch deployment/mydep --subresource=scale -p '{"spec":{"replicas":3}}'

This improvement simplifies scripting and client usage, ensuring you don’t need separate commands or API calls for common subresource actions.

Pod Generation Field (Beta)

Kubernetes 1.33 introduces a new metadata.generation field for Pods. This field tracks updates to the Pod spec by incrementing its value whenever a mutable field changes, bringing Pod behavior in line with existing workload resources like Deployments and StatefulSets.

Previously, Kubernetes Pods lacked a built-in way to indicate if their spec had changed over time. With Pod generation tracking, tools and controllers can now respond more reliably to Pod updates, making it easier to:

• Track Pod spec changes natively
• Detect configuration drift
• Implement more intelligent automation and GitOps workflows

OCI Images as Volumes (Alpha)

A new alpha feature in 1.33 allows you to use OCI artifacts and images as volume sources. This means container images containing tools, binaries, or configuration bundles can be mounted directly into Pods as volumes.

This eliminates the need to unpack or bake these resources into traditional container images, simplifying content distribution and supporting use cases like:

• Sidecar injection
• Custom CLI tooling
• Secure artifact delivery
• Dynamic, versioned resources mounted at runtime

The feature helps reduce container image sprawl, simplifies tooling delivery, and supports more modular architecture patterns in Kubernetes.

HorizontalPodAutoscaler Configurable Tolerance (Alpha)

Kubernetes 1.33 introduces configurable tolerance for horizontal Pod autoscaling. This alpha feature allows you to fine-tune how the HorizontalPodAutoscaler responds to metric fluctuations.

Previously, Kubernetes applied a fixed 10% tolerance to avoid scaling on minor metric changes. With this feature enabled, you can configure custom tolerance values per HPA object:behavior: scaleUp: tolerance: 0.05 # 5% tolerance for scale up

This is particularly useful for large deployments where the default 10% tolerance might represent dozens of Pods.

Other Notable Changes

• Endpoints API Deprecation: The Endpoints API is deprecated in favor of EndpointSlices, which offer better scalability and support for modern features.
• gitRepo Volume Type Removal: This volume type has been completely removed due to security concerns. Users should migrate to alternatives like initContainers with git clone operations.
• Windows Pod Networking Changes: Support for host network in Windows Pods has been withdrawn due to technical challenges.
• Streaming Encoding for LIST Responses: Improves API server performance for large list operations.
• Pod Resource Checkpoint Changes: Pod resource checkpointing is now tracked by new files (allocated_pods_state and actuated_pods_state), replacing the previously used pod_status_manager_state.

Preparing for Kubernetes 1.33

If you’re planning to upgrade to Kubernetes 1.33, here are some key considerations:

1. Review the deprecations and removals, particularly the Endpoints API and gitRepo volume type, and adjust your manifests accordingly.
2. Take advantage of stable features like native sidecar containers instead of using workarounds.
3. Consider enabling user namespaces for better security isolation, especially in multi-tenant environments.
4. Test in-place Pod vertical scaling with your stateful workloads to see if it can reduce operational overhead.
5. Update your tooling and CI/CD pipelines to work with the new subresource support in kubectl.

Conclusion

Kubernetes 1.33 “Octarine” brings a mix of long-awaited features graduating to stability and innovative new capabilities in progress. From native sidecar containers and in-place Pod resizing to enhanced security with user namespaces, this release demonstrates the project’s ongoing commitment to improving usability, security, and flexibility.

These enhancements are the result of contributions from across the Kubernetes community and represent a significant step forward in the platform’s evolution. By understanding and adopting these new features, you can make your Kubernetes deployments more efficient, secure, and manageable.

For more detailed information, check out the official Kubernetes 1.33 release notes and the Kubernetes blog.

Happy upgrading, and enjoy the new features in Kubernetes 1.33!