Kubernetes v1.36 Sneak Peek: The Security-Cleaning, Token-Signing, GPU-Splitting Release (Plus What Might Break on Upgrade)

AI generated image for Kubernetes v1.36 Sneak Peek: The Security-Cleaning, Token-Signing, GPU-Splitting Release (Plus What Might Break on Upgrade)

Kubernetes upgrades have a reputation: they’re either delightfully boring (“it just worked”) or they’re the reason your on-call rotation suddenly becomes a cardio program. Kubernetes v1.36 looks like it wants to live in the first category—quietly improving security and platform maturity—while still slipping a few “please read this before upgrading” notes under your keyboard.

This article is based on the upstream Kubernetes blog post “Kubernetes v1.36 Sneak Peek” by the Kubernetes Contributors (published March 30, 2026). I’ll expand it with additional upstream context, KEP references, and what operators should realistically do before they press the upgrade button.

Per the upstream post, Kubernetes v1.36 is planned for release on Wednesday, April 22, 2026. citeturn1view0

What’s the big theme of Kubernetes v1.36?

If Kubernetes releases had bumper stickers, v1.36’s would read: “Remove the foot-guns; make the secure path the normal path.” That shows up in three places:

  • Security-driven deprecations and removals (externalIPs warnings, gitRepo disabled permanently)
  • Better primitives for identity and key management (external signing of ServiceAccount tokens going GA)
  • More mature device scheduling and sharing via Dynamic Resource Allocation (DRA), including better controls and more realistic GPU/accelerator utilization

In other words: v1.36 is less “new shiny API” and more “let’s stop letting people accidentally build a cluster-shaped vulnerability.”

Release timing and why “planned” matters

The upstream sneak peek is explicit: the list of enhancements is likely included, but not a commitment. citeturn1view0 That caveat is not legalese—it’s how Kubernetes governance works. Features can slip if they don’t meet testing requirements or if cross-SIG concerns pop up late.

For planning, treat April 22, 2026 as a target date for v1.36.0, and assume you’ll still want a staging cycle and at least one patch release before production, depending on your tolerance for excitement.

Deprecation: Service.spec.externalIPs is finally on the way out

Let’s talk about the most operator-relevant deprecation in the sneak peek: the deprecation of .spec.externalIPs in Services.

What externalIPs did (and why people used it)

The externalIPs field has historically been a convenient hack: you can list one or more external IPs and Kubernetes will set up rules so traffic arriving at those IPs is routed to the Service. In certain bare-metal or DIY environments, it felt like an easy substitute for a proper load balancer.

But “easy substitute” is also how many security incidents begin.

Why it’s being deprecated: CVE-2020-8554

The upstream blog calls externalIPs a long-standing security headache and links it to CVE-2020-8554, a man-in-the-middle class vulnerability that can allow traffic interception within a cluster under certain conditions. citeturn1view0turn5search3turn5search9

Important nuance: CVE-2020-8554 has long been described as “unpatchable” in the sense that the behavior is a consequence of how Kubernetes service routing works; mitigations typically involve policy restrictions and admission controls rather than a simple code fix. citeturn5search9

What changes in v1.36

In Kubernetes v1.36, usage of Service.spec.externalIPs will trigger deprecation warnings. citeturn1view0turn4view0

The upstream sneak peek states that full removal is planned for v1.43. citeturn1view0 That’s a long runway, but it’s also a gift: you can migrate methodically, not in a panic.

What to do instead

The upstream post suggests alternatives like LoadBalancer Services (where available), NodePort for simple exposure, and increasingly Gateway API for more flexible ingress and traffic management. citeturn1view0

In practice, your best alternative depends on your environment:

  • Managed clouds: prefer a cloud LoadBalancer (with a WAF or gateway in front if needed) or Gateway API implementations integrated with your provider.
  • Bare metal: use a real L4/L7 solution (MetalLB, BGP/ECMP setups, or a gateway) rather than wiring “random external IPs” directly into Service objects.
  • Security-conscious multi-tenant clusters: use admission policies to block externalIPs immediately, even before you upgrade.

If you want a mental model: the deprecation is Kubernetes telling you, politely, that network exposure should be explicit infrastructure, not a field in a Service spec that looks harmless in a PR.

Removal: the gitRepo volume driver is permanently disabled

There are deprecations, and then there are removals that feel like someone finally unplugged a haunted appliance. In v1.36, Kubernetes permanently disables the in-tree gitRepo volume plugin.

What gitRepo volumes were

The gitRepo volume type let a pod specification declare a Git repository URL, which kubelet would clone onto the node and mount into the pod. That sounds convenient—until you remember that cloning repositories is effectively “execute remote content,” and it’s happening in a privileged path on the node.

Why it’s being removed

The upstream sneak peek notes that gitRepo has been deprecated since Kubernetes v1.11 and that in v1.36 it becomes permanently disabled, citing a critical security risk: potential for an attacker to run code as root on the node. citeturn1view0

The corresponding enhancement tracking issue is KEP-5040 (“Remove gitRepo volume driver”), which targets v1.36 for this step. citeturn3view1

Operator reality: this can break workloads immediately

Unlike externalIPs (warnings now, removal later), this change is more immediate: workloads that still depend on gitRepo will fail in v1.36. Upgrades will “work,” but your application won’t, which is a classic form of technical correctness.

Migrating off gitRepo: practical patterns

The upstream post suggests moving to supported approaches such as init containers or external “git-sync style” tools. citeturn1view0 Here’s what those look like in practice:

  • Init container clone: an init container with a minimal Git image clones into an emptyDir volume, then the main container mounts the same volume. You can pin commits and validate signatures if you’re serious.
  • Sidecar sync: a git-sync sidecar keeps a working tree up to date; useful for config or content, less ideal for runtime code unless you’re very confident about update semantics.
  • Build it into the image: for application code, the most reproducible option is still “CI pulls Git, builds an image, signs it, and you deploy that.” It’s boring for the best reasons.

If you’re thinking “but we used gitRepo for fast prototyping,” congratulations: you’re exactly why Kubernetes has a deprecation policy. Prototypes become production. It’s a law of nature.

Featured enhancement (GA): faster SELinux labeling for volumes

Security improvements aren’t only about removing risky features. Kubernetes v1.36 also promotes a performance-and-safety upgrade to generally available (GA): faster SELinux labeling for volumes.

The performance problem

On SELinux-enforcing systems, a common source of painful pod startup times has been volume relabeling—especially with large volumes—because recursive relabeling means kubelet walks the entire tree and updates labels file-by-file.

The new behavior: label at mount time

The sneak peek describes a shift away from recursive relabeling toward applying the label at mount time using mount -o context=…. That change reduces pod startup delays and improves consistency. citeturn1view0turn3view2

The enhancement is tracked as KEP-1710 (“Speed up recursive SELinux label change”), with v1.36 listed as the stable target. citeturn3view2

The “this could still bite you” clause

The upstream post includes a real-world warning: mixing privileged and unprivileged pods with shared volumes can become tricky, and pod authors are responsible for correctly setting SELinux fields like seLinuxChangePolicy and labels. citeturn1view0

Translation: the default experience improves, but if your cluster is doing creative things with shared storage and SELinux contexts, test the upgrade. Kubernetes is getting safer, but it can’t protect you from your own YAML.

Featured enhancement (GA): external signing of ServiceAccount tokens

Kubernetes identity has been evolving for years: projected ServiceAccount tokens, bounded lifetimes, workload identity integrations, and an industry-wide push to treat key management like a first-class system. v1.36 continues that trend by bringing external signing of ServiceAccount tokens to stable (GA), per the sneak peek.

What “external signing” means

Instead of having the Kubernetes API server sign ServiceAccount tokens only with internally managed keys, the API server can delegate signing to an external system (for example, a cloud key management service or an HSM-backed signing service). citeturn1view0turn3view3

This feature is tracked in KEP-740 (“API for external signing of Service Account tokens”), with v1.36 listed as the stable target. citeturn3view3

Why operators should care

  • Centralized key management: align Kubernetes token signing with enterprise key policies, audit trails, rotation requirements, and hardware-backed controls.
  • Reduced blast radius: separating signing infrastructure from the cluster can simplify certain incident response scenarios.
  • Cleaner integration patterns: for organizations already using KMS/HSM for signing elsewhere, Kubernetes can stop being the odd system that insists on doing its own thing.

One caution: “external” adds dependency surface. If your external signer becomes unavailable, your authentication flows can get weird in a hurry. Design for availability, not just compliance.

Dynamic Resource Allocation (DRA): Kubernetes keeps getting serious about accelerators

For years, Kubernetes device scheduling has been a mix of node labels, extended resources, and vendor plugins. It worked, but it didn’t scale gracefully to the modern reality: expensive accelerators, multi-tenant AI workloads, and a desperate need to not strand 80% of your GPU because one pod asked for “1 GPU” and got the entire thing.

DRA is Kubernetes’ answer: a structured, API-driven approach to devices and claims that schedulers and controllers can reason about more natively. Kubernetes v1.36 continues to expand and harden DRA.

DRA device taints and tolerations (beta)

The sneak peek highlights device taints and tolerations for DRA graduating to beta, making it available by default without a feature flag and open to user feedback. citeturn1view0turn3view4

This is the right kind of “boring” feature: it lets drivers mark devices as effectively off-limits unless a workload explicitly tolerates the taint. That helps prevent accidental scheduling onto devices that are reserved, unhealthy, or dedicated to specific tenants or compliance constraints.

DRA partitionable devices (better sharing of expensive hardware)

The sneak peek also calls out DRA support for partitionable devices, designed to allow a single accelerator to be split into logical units usable by multiple workloads. citeturn1view0turn3view5

In the real world, the obvious poster child is NVIDIA Multi-Instance GPU (MIG), where one physical GPU can be partitioned into multiple isolated instances. MIG exists today, but operationalizing it in Kubernetes has historically required custom tooling and careful coordination. Guides and vendor ecosystems have been moving in that direction already, and DRA’s partitioning work is a path toward making this behavior more native and schedulable. citeturn5search1turn3view5

More DRA changes you’ll see in the v1.36 changelog

The Kubernetes v1.36 changelog includes additional DRA-related items beyond the sneak peek highlights, including API additions, RBAC authorization tightening around ResourceClaim status updates, and more DRA feature maturation. citeturn4view5

If you run accelerators at scale, it’s worth reading the DRA sections in the changelog carefully—not just for features, but for any permission or behavior changes that might require updating controllers, schedulers, or vendor drivers.

Ingress NGINX retirement: the ecosystem signal behind the v1.36 story

The sneak peek contains an important ecosystem callout: Ingress NGINX has been retired. It frames this as part of Kubernetes’ broader lifecycle discipline—features and projects have lifecycles, and retirement is sometimes the safest outcome. citeturn1view0turn2view0

The upstream sneak peek states the retirement date as March 24, 2026 and notes that after that date there are no releases, bugfixes, or security updates, though existing deployments will continue to function and artifacts remain available. citeturn1view0

Even though Ingress NGINX retirement is not a “Kubernetes v1.36 core code” change, it’s absolutely part of the operator experience of upgrading in 2026. If you’re migrating ingress or adopting Gateway API, do it as a deliberate project—don’t wait until you’re also upgrading your cluster.

What might break when you upgrade to Kubernetes v1.36?

Kubernetes itself tries hard not to break you, but upgrades still have two common failure modes: (1) your workloads depended on deprecated behaviors, or (2) your operational tooling had assumptions baked into metrics, API fields, or permissions.

Workloads that used gitRepo volumes

This is the loudest potential break: if you still have gitRepo in manifests (or in templating that spits out manifests), v1.36 will stop that from working. The upstream sneak peek is clear that it becomes permanently disabled. citeturn1view0turn3view1

Services that use externalIPs

These won’t break immediately in v1.36, but you’ll see warnings and you should treat them as “start migrating now” signals. citeturn4view0turn1view0

Monitoring dashboards and alerts that depend on renamed metrics

The v1.36 changelog’s urgent upgrade notes include at least one practical example: the kube-controller-manager metric volume_operation_total_errors was renamed to volume_operation_errors_total. If you have alerts keyed to the old name, they’ll go silent. citeturn4view0

Silent alerts are a special category of operational horror, so this is exactly why reading urgent upgrade notes matters.

DRA RBAC and integration changes

As DRA matures, it also becomes stricter about permissions. The v1.36 changelog notes that DRA drivers/controllers may require more granular RBAC permissions for updating ResourceClaim statuses when a certain feature gate is enabled (beta in 1.36). citeturn4view5

If you’re using DRA drivers from vendors or internal teams, verify compatibility and required roles before production rollout.

How to prepare for v1.36: a pragmatic checklist

Here’s a practical pre-upgrade list that won’t win awards for poetry, but will reduce the chance that your upgrade turns into a “learning opportunity.”

1) Inventory externalIPs usage

  • Search all namespaces for Services with spec.externalIPs.
  • Decide: migrate to LoadBalancer, NodePort, or Gateway API.
  • Implement admission controls to prevent new usage if you can.

2) Find and eradicate gitRepo volumes

  • Scan manifests and Helm charts for gitRepo.
  • Migrate to init container clone or build-time cloning.
  • Test on staging with v1.36 before touching prod.

3) If you use SELinux, test realistic storage workloads

  • Run pod startup timing tests on representative volumes.
  • Validate SELinux contexts and any shared-volume patterns.
  • Train application teams on seLinuxChangePolicy and label responsibilities.

4) If you use DRA or GPUs, treat this as a platform upgrade

  • Confirm your DRA drivers support v1.36 and any beta behavior changes.
  • Review RBAC changes and update service accounts/roles accordingly.
  • If you plan GPU partitioning, define your scheduling and quota model early (who gets what slice, under what policy).

5) Read the v1.36 changelog “urgent upgrade notes” like it’s a thriller novel

Yes, it’s long. But at least it’s not a 3 a.m. incident report.

Start with the upstream changelog entry for v1.36, especially the “Urgent Upgrade Notes” section and the deprecations list. citeturn4view0turn2view8

Why v1.36 matters for the bigger Kubernetes trajectory

Kubernetes has been steadily shifting from “container orchestration” to “the substrate for everything,” including AI inference, batch workloads, and regulated enterprise environments. The features highlighted in the sneak peek are small pieces of that arc:

  • Security posture: deprecating externalIPs and disabling gitRepo nudges clusters away from insecure defaults and legacy behaviors. citeturn1view0
  • Identity maturity: external signing aligns Kubernetes with external key governance realities. citeturn1view0turn3view3
  • Hardware efficiency: DRA partitioning and device controls help platforms treat accelerators like shared infrastructure rather than indivisible snowflakes. citeturn1view0turn3view5
  • Operational smoothness: SELinux volume labeling improvements reduce a common performance pain point on secure Linux distributions. citeturn1view0turn3view2

And perhaps most importantly: Kubernetes is using the release process to steadily remove the stuff that looked handy in 2017 but looks terrifying in 2026. That’s a sign of a platform that expects to be around for a long time.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org