Kubernetes v1.36 “Haru”: Why Some Changes Aren’t Worth the Wait

Prelude: A “Sober” Release

The community often counts new features as a sign of progress, but the v1.36 blog deliberately emphasizes debt removal. Of the 70 enhancements, 18 are GA and 25 are Alpha, showing a shift from experimental overload to production‑ready functionality.

Ingress NGINX End‑of‑Life

On 2026‑03‑24 the ingress‑nginx repository became read‑only; no new releases, patches, or CVE fixes will be provided. Running ingress‑nginx after this date leaves clusters exposed to the high‑severity CVE‑2025‑1974 (snippets RCE, CVSS 9.8). The design of NGINX assumes a relatively static environment, and the snippets annotation bypasses RBAC, making the vulnerability unavoidable.

Retiring ingress‑nginx mirrors the Docker Swarm abandonment: the community chose to drop an outdated architecture despite the migration cost.

Migration path: use the Gateway API and the ingress2gateway 1.0 tool to convert existing Ingress objects to HTTPRoute + Gateway. The three‑layer design (GatewayClass, Gateway, HTTPRoute) is safer for multi‑tenant scenarios but adds conceptual complexity.

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

Security Layer: Three GA Changes

Fine‑grained Kubelet API auth (KEP‑2862)

Previously monitoring components needed the broad nodes/proxy permission, effectively granting root‑level node access. v1.36 allows individual endpoint authorizations ( /metrics, /logs, /exec), enabling true least‑privilege configurations.

# Before: a single wide‑open rule
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

# After: grant only what is needed
rules:
- apiGroups: ["kubelet.k8s.io"]
  resources: ["nodes/metrics"]
  verbs: ["get"]

This change is especially valuable for compliance‑heavy environments such as finance or healthcare.

SELinux mount‑context optimization (KEP‑1710)

On SELinux‑enforcing nodes, mounting a PVC with millions of files previously invoked chcon per file, causing minutes‑long pod startup delays. The GA solution uses mount -o context=XYZ to set the context once for the whole volume.

Upgrade warning: if multiple pods share a PVC with differing SELinux contexts, the new default may conflict; set seLinuxChangePolicy: Recursive to revert or adjust securityContext.

External ServiceAccount token signing (KEP‑740)

Token signing keys are now delegable to external KMS providers (AWS KMS, GCP Cloud KMS, HashiCorp Vault), enabling centralized key management, rotation, and audit logging, which satisfies strict compliance requirements.

DRA Explosion: AI‑Era Hardware Scheduling

Dynamic Resource Allocation (DRA) moved from isolated GA in v1.34 to a suite of eight+ KEPs in v1.36, adding resource‑pool status, GPU‑level taints/tolerations, device attribute injection, and list‑type attributes. This lets operators mark a single GPU for maintenance ( maintenance:NoSchedule) without cordoning the whole node, saving costly downtime for expensive hardware.

DRA follows the same trajectory as CNI a decade ago: initially ignored, later indispensable.

MutatingAdmissionPolicy GA: End of Webhook Era

v1.36 graduates MutatingAdmissionPolicy to GA, completing the CEL‑based native admission control stack. Unlike Webhooks, policies run inside the API server, eliminating external certificate management, HA concerns, and timeout risks.

# Before: external webhook configuration
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: inject-labels.example.com
  clientConfig:
    service:
      name: webhook-svc
      namespace: default
      port: 443
  failurePolicy: Fail

# After: native policy
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
spec:
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: |
        Object{metadata: ObjectMeta{labels: {"environment": "production"}}}

Recommendation: migrate any CEL‑expressible webhook logic to MutatingAdmissionPolicy now.

Two Removals, Fifteen Years of Debt Cleared

gitRepo Volume

Deprecated in 2018 and finally disabled in 2026, gitRepo allowed pods to run arbitrary git commands on the node, exposing the cluster to code‑execution vulnerabilities via git hooks or core.fsmonitor. After upgrade, pods using gitRepo will fail to schedule; move clone logic to an Init Container or git‑sync sidecar.

# Find pods with gitRepo volumes
kubectl get pods --all-namespaces -o json |
  jq '.items[] | select(.spec.volumes[]?.gitRepo != null) | .metadata | "\(.namespace)/\(.name)"'

IPVS mode

IPVS was removed in favor of nftables, which offers a cleaner implementation for large Service counts. Teams still on IPVS should test nftables in staging before migration.

Upgrade Action Checklist

Check for ingress‑nginx usage and plan migration to Gateway API (target Q3 2026).

Audit all Services for externalIPs to mitigate CVE‑2020‑8554.

Identify pods with gitRepo volumes and relocate clone logic.

On SELinux‑enforcing nodes, verify no shared PVCs have mismatched contexts.

If still using kube‑proxy IPVS, validate nftables replacement in staging.

Ensure CIDR strings follow 192.168.1.1/24 format; v1.36 now rejects non‑zero host bits.

After upgrade, migrate CEL‑expressible MutatingWebhooks to MutatingAdmissionPolicy (e.g., label injection, default limits, image tag rewrites).

Test Alpha features relevant to AI/ML workloads: DRAResourcePoolStatus, WorkloadAwarePreemption, Gang Scheduling with DisruptionMode, and Kubelet local gRPC Pod API.

Conclusion

Kubernetes won the early container‑orchestration battle by supporting everything; now it stays healthy by dropping what it should not support. v1.36 is not about groundbreaking new directions but about graduating the right things, retiring the wrong ones, and removing long‑standing debt—an essential step for a platform that runs on millions of clusters.