7 Things Kubernetes 1.36 Changes (From Killing Ingress-Nginx to Native Scale-to-Zero)

Kubernetes 1.36: what actually changes

When I read release notes, I don't start with the feature list. I start with a different question: how does this change my operating costs and who's on the hook when it breaks? A feature can look great on a slide and still mean nothing to the person carrying the pager. Cost, security boundaries, incident procedure — that's the whole job.

Reading the 1.36 beta with those glasses on, this isn't a stabilization release. The core is reaching out and taking back a few holes that third-party projects have been plugging for years. If you've never been able to scale a workload to zero without KEDA or Knative, or if you're tired of Ingress configs drowning in annotations, this one's worth your time.

GA is set for April 22. Here are seven things worth sorting out before then.

1. Native scale-to-zero

You can now scale a workload to zero without bolting anything on.

Until now that meant KEDA or Knative. The cost isn't just "one more component." It's one more thing to monitor, one more upgrade cadence to align, and one more fork in every incident: is this an HPA problem or a KEDA problem? The responsibility boundary gets blurry.

In 1.36 the HPAScaleToZero feature gate is on by default, so plain HPA does the job.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: scale-to-zero-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-inference-worker
  minReplicas: 0    # 드디어 네이티브 지원!
  maxReplicas: 10
  behavior:
    scaleDown:
      policies:
      - type: Pods
        value: 1
        periodSeconds: 300

Why this matters: think about your dev environments, or anything that sits idle overnight. Idle most of the day, and still required to keep at least one pod alive. Every time I've gone through a client's cloud bill line by line, these "always up, barely working" workloads eat a surprising share of it. Actually getting to zero isn't a convenience feature from a FinOps standpoint.

Cold starts don't go away, though. Where requests wait out the 0→1 climb, whether you absorb them in a queue — that's a separate design problem. Being able to scale to zero and being able to wake up safely from zero are two different things.

2. Ingress-Nginx says goodbye

The Ingress-Nginx controller is winding down. Less of a shock, more of a scheduled ending.

It's not disappearing tomorrow. But the project has now officially started pointing people at the Gateway API. Gateway is more expressive, and more importantly it's role-oriented by design. Who gets to configure what is split at the resource level. That lands right on the weak spot of classic Ingress, where platform-team and service-team responsibilities were mashed into one object.

If you're still stacking annotations like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    # ... 수많은 annotation들

The problem is that controller-specific behavior has soaked into your YAML. This isn't standard spec, it's one controller's dialect. When the controller goes, the dialect has nowhere to live.

Migrate sooner rather than later. Technical debt accrues interest. Mapping your rules over while Ingress-Nginx is still alive and supported is a completely different job from being forced across after support ends.

3. Dynamic Resource Allocation for the AI era

GPU, TPU, and NPU scheduling changes.

The old Device Plugin API was fine for simple accelerators, but it ran out of vocabulary once the hardware got complicated. 1.36 brings a big DRA push aimed squarely at AI workloads.

The piece that caught my eye is DRA taints and tolerations. Say one GPU on a multi-GPU node starts throwing ECC errors. Until now the node was the smallest unit of isolation. One bad card, and you had to drain the healthy GPUs and the CPU work sitting on that node along with it. You park the whole machine.

Now you taint the single bad GPU. Everything else on the node keeps running. Fault isolation dropped from node granularity to device granularity. Anyone who's operated AI infrastructure knows how much that one step down is worth.

4. Vertical scaling without a restart

Bumping memory on a Java app and briefly taking the service down with it — most of us have that story.

I've got mine. All I wanted was a slightly higher memory limit, and the pod restarted and the service blinked out. The change is trivial; the fact that something trivial causes downtime is what makes operational procedure ossify into "resource changes go in the maintenance window."

In 1.36, In-Place Vertical Pod Scaling is stable, so you can adjust a running pod's resource allocation without restarting it. Notably it works even with the static CPU manager policy enabled.

If you run VPA, this is good news. Zero-downtime resource adjustment is real now, and even high-performance workloads that need pinned CPU cores can scale without a cold start. When the risk cost of a change drops, your procedures can loosen up to match.

5. Hardened image pulls

The era of static imagePullSecrets is ending.

Pulling from a private registry — ECR, ACR, Harbor — meant a fixed secret. Once that leaks, it stays exploitable until a human rotates it by hand. Static credentials carry a permanent risk: you don't know when they leak, and when they do you find out much later.

1.36 stabilizes ephemeral service account tokens: short-lived, automatically rotated.

Zero trust reached the image-pull layer. Tokens are issued and expire against a specific pod's lifecycle, so a leak has a narrow window to be useful. Having wrestled with credential management in financial-sector IT, I think this is the right direction — moving from "hide the secret well" to "keep the secret's life short."

6. Smarter node monitoring with PSI

An alert fires: "memory utilization 95%." Is that actually dangerous?

If most of that memory is page cache, everything might be fine. Kubernetes has been judging by utilization alone, which is how cache gets counted as pressure, NodeNotReady fires falsely, and perfectly healthy pods get evicted. The number is high, but nobody is actually stalled waiting on a resource. Fake load.

1.36 uses PSI (Pressure Stall Information) to read node state more accurately. PSI is a Linux kernel feature that tells you whether tasks are genuinely stalled waiting on resources. The shift is from utilization, a surface number, to stall, a structural signal.

Operationally I expect smarter pod eviction, fewer false NodeNotReady flags, and observability that distinguishes real load from fake load. False positives are the most exhausting part of incident response. A signal-versus-noise metric landing in the core also means fewer 3 a.m. wake-ups.

7. Containerd 2.x and OCI artifact support

If you've been putting off a runtime upgrade, consider this the deadline notice.

Kubernetes 1.36 will likely be the last version supporting containerd 1.6.x. Start planning the move to 2.x.

OCI artifact mounting also went stable. Helm charts, WASM modules, config files — you can mount them into pods straight from an OCI registry. That opens the door to cleaning up the pattern of cramming everything into the image or dragging it in through a separate volume.

Swapping a runtime isn't glamorous work, it's just annoying work. Which is exactly why it keeps sliding. Things to check now: your current AMI or provisioning scripts, containerd version compatibility, and your node image update plan.

What platform teams should touch now

Broken into actual work items, the seven above come out roughly like this.

1. Clean up autoscaling

Start by identifying workloads that idle overnight. Pick out the ones that can take minReplicas: 0, then plan the native HPA migration together with a cold-start answer.

2. Prep the Ingress migration

First, analyze how deep your dependency on complex Nginx annotations actually runs. Then Gateway API learning and a POC, and on top of that, the work of mapping existing Ingress rules to Gateway.

3. Upgrade the infrastructure

• Verify containerd 2.x compatibility
• Prepare kernel images built with CONFIG_PSI=y
• Plan the node OS image update

What to sort out before GA

About 20 days to go. One theme runs through this release: the core is absorbing holes that third parties have been filling. Scale-to-zero, Gateway API, DRA, PSI — all of it.

The consequence is clear enough. Some of the external components you operate today shrink in scope or go away, and that responsibility shifts into the core. Fewer components does mean less operational burden, but it isn't free. You're bound more tightly to the core version, and you have less room to defer upgrades.

If it were my cluster, I'd start with scale-to-zero and the Gateway API migration. One touches cost immediately; the other only gets more expensive to move the longer you wait. The rest can ride along with your normal infrastructure upgrade cycle.

The better posture going into this release isn't deciding when to flip on the new features. It's sketching out which of your current external dependencies you're going to retire and which ones you're keeping.