Kubernetes 1.33 graduates native sidecars and makes admission policy CEL-first

Code-named Octarine, Kubernetes 1.33 shipped on 23 April 2025. Sixty-four enhancements: 18 graduating to stable, 20 to beta, 24 new alpha. Behind the volume, three changes stand out for anyone running clusters professionally: native sidecar containers are now generally available, Pods can be resized in place without a restart, and structured authorization configuration is the new standard.

For clusters still running bespoke admission webhooks, 1.33 is the signal: ValidatingAdmissionPolicy (VAP) with CEL is now a production-grade alternative. Here is what matters — and what needs migrating.

Native sidecars: the workaround is over

The sidecar pattern — an auxiliary container running alongside the application container for networking, logging, or telemetry — has been bolted onto Kubernetes by service meshes and OpenTelemetry collectors for years. But Kubernetes had no native guarantee that the sidecar would start before the main application.

1.33 closes that gap for good. The mechanism, introduced as alpha in 1.28 and beta in 1.29, is now stable. The idea is simple: an initContainer with restartPolicy: Always becomes a sidecar. It starts before regular containers, persists throughout the Pod lifecycle, and terminates automatically once the main containers exit. No more guessing whether Envoy was ready before your app started listening.

spec:
  initContainers:
    - name: envoy-proxy
      image: envoyproxy/envoy:v1.30
      restartPolicy: Always   # ← Turns this into a sidecar
      startupProbe:
        httpGet:
          path: /ready
          port: 9901
        failureThreshold: 30
  containers:
    - name: app
      image: myapp:latest
      # Guaranteed: Envoy is ready before the app starts

For Istio, Linkerd, and OpenTelemetry deployments, this removes a long-standing ambiguity. Lifecycle ordering is now predictable — no wrapper scripts, no repurposed init containers. Sidecars get probes (startup, readiness, liveness), and their OOM scores align with primary containers.

In-place Pod resizing

Before 1.33, changing a Pod’s CPU or memory request meant killing and recreating it. In-place Pod vertical scaling — now beta — changes that fundamentally.

kubectl patch pod my-pod --subresource=resize \
  -p '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"500m","memory":"512Mi"}}}]}}'

No restart. The Pod picks up the new limits directly.

Each container can define a resizePolicy with two options: RestartNotRequired (the default for CPU) and RestartContainer (for memory on some runtimes). The Pod status now separates allocatedResources (what the node actually granted) from resources (the desired target).

Paired with HPA, vertical scaling becomes a genuine architectural choice: for stateful workloads, one larger Pod may be better than ten smaller ones.

Admission control: VAP steps into production

The most consequential change is the quiet maturing of ValidatingAdmissionPolicy. Introduced as alpha in 1.26, VAP offers a declarative alternative to validating admission webhooks: rules are written in Common Expression Language (CEL) and evaluated inside the API server itself — no external network call.

1.33 brings CEL expression improvements and better error-message handling. VAP is now production-viable for policies expressible in CEL.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-app-label
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "has(object.metadata.labels) && has(object.metadata.labels.app)"
      message: "The 'app' label is required on all Deployments"

What VAP does well. No extra controller to operate, minimal latency (in-process with the API server), straightforward for rules like “every Deployment must carry an app label” or “block the docker.io/noname registry.”

What VAP does not do. CEL is less expressive than Gatekeeper’s Rego or Kyverno’s YAML for complex policies. VAP covers validation only — no mutation. No advanced exception workflows.

The emerging pattern in 2025–2026: VAP for simple, universal guardrails; Kyverno or Gatekeeper for richer supply-chain enforcement. Both coexist on the same cluster without conflict.

Structured authorization: YAML replaces CLI flags

Another major graduation: structured authorization configuration is now GA. Before 1.30, expressing an authorizer chain (Node → RBAC → Webhook) meant crafting fragile, order-sensitive command-line flags. 1.33 makes a declarative YAML file canonical.

apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration
authorizers:
  - type: Node
    name: node
  - type: RBAC
    name: rbac
  - type: Webhook
    name: opa-webhook
    webhook:
      timeout: 3s
      failurePolicy: Deny
      matchConditions:
        - name: only-non-system
          expression: "!request.userInfo.username.startsWith('system:')"

The matchConditions in CEL let you scope webhook calls to relevant requests — a significant performance win. The flag-based path is on a deprecation track: migrate before 1.34.

What will break

In-tree cloud providers. The native AWS, GCP, and Azure controllers are removed. Clusters must run the external cloud-controller-manager. If your cluster still relied on in-tree integrations, migration is no longer optional.

cgroup v1. Deprecation signals are tightening. Runtimes tied to cgroup v1 should plan migration — 1.33 is not the removal release, but the writing is on the wall.

Ghost PSP controllers. PSP has been dead since 1.25, but ageing clusters sometimes still carry residual PSP admission controllers. 1.33 is a good release to purge them.

# Check deprecated API usage
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

# Audit Pod Security Admission per namespace
kubectl get namespaces -o json | jq '.items[] | {name: .metadata.name, pss: .metadata.labels["pod-security.kubernetes.io/enforce"]}'

Jobs: finer-grained control

Batch workloads gain two GA improvements. Success Policy lets you define “done” beyond “all pods completed” — require the first N indexes, a minimum count, or both. Per-index backoff limits prevent a single flaky task from failing an entire indexed Job.

The upgrade checklist

1. Verify third-party admission controller compatibility — Kyverno, Gatekeeper, commercial controllers
2. Migrate authorization configuration from CLI flags to the structured YAML file
3. Check deprecated API usage — kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
4. Deploy external CCM if your cluster used in-tree cloud providers
5. Audit namespace Pod Security Admission labels before switching to enforce mode

The cadence rule: run N or N-1 in production. Kubernetes ships three releases per year with a 14-month support window. Being more than one version behind dangerously compresses the decision timeline on security backports.

The verdict

Kubernetes 1.33 is a maturation cycle, not a revolution. But it is maturation that changes daily practice.

Native sidecars fix a lifecycle-ordering problem service meshes have been working around for years — no scripts, no hijacked init containers. In-place resizing removes a major operational friction point: not having to kill a Pod to give it more CPU changes how you think about sizing stateful workloads. And VAP becomes a real alternative to webhooks for simple policies — without the overhead of running an extra controller.

If you run production clusters, now is the time to pay down the technical debt: migrate your authorization config, verify your admission controllers, and start moving straightforward validation rules to VAP. 1.34 will not wait.

References

• Kubernetes v1.33: Octarine, Kubernetes Blog, 23 April 2025.
• Kubernetes 1.33 Security Deep Dive, Safeguard, 20 June 2025.
• Kubernetes 1.31 to 1.33: Every Feature You Need to Know Right Now, Dev Note, 30 June 2026.
• Validating Admission Policy, Kubernetes documentation.
• Sidecar Containers, Kubernetes documentation.
• KEP-753: Sidecar Containers.
• KEP-1287: In-Place Update of Pod Resources.
• KEP-3850: Backoff Limit Per Index For Indexed Jobs.
• KEP-3998: Job success/completion policy.