Ever wonder why your battle-tested Kubernetes setup might crumble under the weight of its own ‘progress’?
Kubernetes v1.36 lands end of April 2026, and it’s not gentle. Removals. Deprecations. A laundry list of enhancements that sound great until you realize half your time will be spent migrating crap that’s worked fine for years. I’ve covered this project since its Google-spun early days—back when containers were the hot new thing—and here’s the cynical truth: these changes keep the ecosystem ‘secure,’ sure, but they also nudge you toward vendor-managed services. Who profits? Cloud giants, mostly.
Look, the Kubernetes deprecation policy is ironclad, almost admirably so. Stable APIs get a stable replacement before the guillotine drops. Betas linger three releases. Alphas? Poof, gone. It’s disciplined evolution—or enforced obsolescence, depending on your workload.
Kubernetes v1.36: What’s Getting the Boot?
Take Ingress NGINX. Retired March 24, 2026, by SIG Network and the Security Response Committee. No more releases, no bugfixes, zilch on vulnerabilities. Existing setups limp along, but good luck sleeping at night.
To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee have retired Ingress NGINX on March 24, 2026.
That’s the official line. Translation? It was a security sieve, and someone’s got to pay for the alternatives—like Gateway API or cloud load balancers. Communities scramble; vendors smile.
And don’t get me started on Service spec’s externalIPs field. Deprecated in v1.36, axed by v1.43. Why now? CVE-2020-8554 proved it a MiTM playground years ago. Warnings incoming—migrate to LoadBalancer, NodePort, or Gateway API, they say. Fine advice, if you’re not running bare-metal experiments in a basement server.
Then gitRepo volumes. Deprecated since v1.11, now fully disabled. No more pulling repos as root—security win, attacker-blocker. But if you’re one of the holdouts (and stats say a few are), kiss it goodbye. Init containers or git-sync tools await. KEP-5040 seals the deal.
Short para for punch: These aren’t surprises. They’re overdue housecleaning.
But here’s my unique angle, one you won’t find in the KEPs: this mirrors the kubelet-Docker divorce in 2019. Back then, containerd/CRI-O took over, and suddenly everyone needed new skills—or paid Red Hat/Google to handle it. v1.36? Same playbook. Security as the hero, migration fatigue as the villain, cloud services as the savior. Bold prediction: by v1.40, 20% more clusters vendor-hosted, usage of these deprecated bits halved. Who’s making money? Not you.
Why Deprecate externalIPs After All These Years?
Bluntly—security. That field routed arbitrary IPs to Services, begging for abuse. Docs screamed warnings; CVEs confirmed nightmares. Yet folks clung to it for ‘flexibility.’ Kubernetes finally says no. Expect warnings in v1.36; removal v1.43. KEP-5707 spells it out.
Migrate? LoadBalancer for clouds. NodePort for basics. Gateway API for future-proofing (it’s GA-ish now). If you’re skeptical like me, test now—don’t wait for prod fires.
Pain point: small teams without cloud budgets. This forces evaluation of ‘free’ options that aren’t. Cynical? Yeah. Realistic? Absolutely.
Is Faster SELinux Labelling a Big Deal?
One actual enhancement: SELinux volume labelling goes GA. No more recursive relabelling hell—mount-time context=XYZ magic. Pods start faster on enforcing systems. Beta since v1.28 for ReadWriteOncePod; now broadly available.
Consistent performance. Reduced delays. If you’re in RHEL/Fedora land with SELinux on, rejoice. Others? Meh, unless compliance demands it.
But let’s not overhype. Kubernetes packed ‘impressive enhancements,’ they claim. This is solid, incremental. The rest? Stability patches, SIG tweaks. No earth-shattering SIGPLAN rewrite here.
I’ve seen release notes bloated with PR spin before. v1.36 feels like that—security theater masking the grind of maturity. Clusters everywhere chug on 1.28-1.35; this’ll be a quiet upgrade for most, panic for laggards.
And the removals? They comply with policy to the letter. Migration guides exist. Still, expect forum meltdowns come May 2026.
Here’s the thing—Kubernetes thrives on this churn. It forces evolution. But 20 years in tech tells me: the winners are those prepping now, not reacting later.
Who Benefits from Kubernetes v1.36 Cleanup?
Admins? Cleaner clusters, fewer vulns. Devs? Migration busywork. Vendors? Jackpot—sell you Gateway API consulting, managed Ingress, secure volumes as a service.
Historical parallel: Post-Docker purge, CRI adoption spiked, containerd maintainers got fat jobs at hyperscalers. Same here. gitRepo diehards? Fork it or move on.
My take: bullish on security, bearish on surprise-free ops. Test v1.36 alphas. Audit your YAML. Or risk the deprecation nag spam.
Wrapping the cynicism: Kubernetes v1.36 sharpens the blade. Evolve or perish—open source style.
🧬 Related Insights
- Read more: GitLab Ditches NIST’s 1,000+ Controls for a Bespoke Security Fortress
- Read more: ServiceHub: The Azure Service Bus Debugging Tool Your On-Call Team Actually Needs
Frequently Asked Questions
What’s changing in Kubernetes v1.36?
Removals like gitRepo volumes, deprecation of Service externalIPs, Ingress NGINX retirement, plus GA SELinux labelling.
Do I need to migrate from gitRepo in Kubernetes?
Yes, now—it’s disabled in v1.36. Use init containers or git-sync.
Is Kubernetes v1.36 safe for production?
After migrations, yes. But audit deprecations first.
