Kubernetes 1.21, codenamed “Power to the Community,” dropped today and it’s a release that tells an interesting story — not through flashy new features, but through the sheer number of items graduating to stable. Thirteen enhancements moved to GA in this release, the most in any single Kubernetes release so far. That’s a strong signal that the project is shifting from “move fast and add features” to “stabilize what we have.”
Immutable Secrets and ConfigMaps Hit GA#
The headline feature for me is the graduation of immutable Secrets and ConfigMaps to stable. This has been in beta since 1.19, and its promotion to GA is well-deserved. The concept is simple: once you mark a Secret or ConfigMap as immutable, it cannot be updated. Any attempt to modify it will be rejected by the API server.
Why does this matter? First, performance. The kubelet watches for changes to Secrets and ConfigMaps that pods reference. When you have thousands of pods across hundreds of nodes, that’s an enormous amount of watch traffic hitting the API server. Immutable resources can be skipped by the watch mechanism entirely, reducing load on both the kubelet and the API server significantly. In clusters I’ve managed with several thousand pods, the API server load from Secret watches alone was non-trivial.
Second, safety. An immutable Secret can’t be accidentally (or maliciously) modified. In a world where a single misconfigured ConfigMap can cascade through an entire deployment, having an explicit “this is locked, don’t touch it” flag is a meaningful guard rail. You have to create a new Secret and update the pod spec to reference it — which means going through your normal deployment pipeline with all its reviews and approvals.
apiVersion: v1
kind: Secret
metadata:
name: database-credentials
type: Opaque
data:
password: cGFzc3dvcmQxMjM=
immutable: trueIt’s a small addition syntactically, but it changes the operational model in important ways.
CronJobs Graduate to GA#
CronJobs have been in beta since Kubernetes 1.8 — that’s over three years in beta. Their graduation to GA in 1.21 comes with a new controller implementation (CronJobControllerV2) that’s more reliable and performant than the old one.
The old CronJob controller had well-known issues with missed schedules, especially under API server load. If the controller couldn’t list jobs quickly enough, it might miss a scheduled run or, worse, create duplicate jobs. The new controller addresses these issues with a more robust scheduling algorithm and better handling of clock skew.
For those of us running batch workloads on Kubernetes — ETL jobs, report generation, cleanup tasks — this is a welcome stabilization. I’ve had to implement workarounds for CronJob reliability issues in production for years, including external cron schedulers that create Kubernetes Jobs directly. Being able to trust the built-in CronJob controller simplifies operations considerably.
PodSecurityPolicy Deprecation#
The flip side of all these graduations is the formal deprecation of PodSecurityPolicy (PSP). PSPs have been the primary mechanism for enforcing security constraints on pods — things like preventing privileged containers, restricting volume types, or enforcing read-only root filesystems.
The deprecation isn’t surprising. PSPs have been widely criticized for their confusing authorization model, difficult debugging experience, and inconsistent behavior. The Kubernetes team has been signaling this move for a while, and the replacement — a new Pod Security Admission controller — is in development.
The practical impact is that PSPs will continue to work through Kubernetes 1.25 (expected removal), giving teams roughly two years to migrate. But if you’re running PSPs in production, now is the time to start planning your migration strategy. The new admission controller will use a simplified model based on three predefined security profiles (Privileged, Baseline, and Restricted) rather than the current highly-configurable-but-confusing approach.
Graceful Node Shutdown Goes Beta#
Another notable feature is the graduation of graceful node shutdown to beta. When a node is shutting down (whether for maintenance, scaling down, or a cloud provider spot instance reclamation), Kubernetes can now detect the shutdown signal and gracefully terminate pods in priority order, respecting their terminationGracePeriodSeconds.
This is particularly relevant for cloud environments where spot/preemptible instances are common. Without graceful shutdown, pods on a terminating node get killed abruptly, potentially corrupting in-progress work or losing data. With this feature, the kubelet intercepts the systemd inhibitor lock and orchestrates a clean shutdown sequence.
In practice, this means your stateful workloads — databases, message queues, long-running batch jobs — have a much better chance of shutting down cleanly when the underlying node disappears. It’s the kind of feature that doesn’t make headlines but saves you from 3 AM incident calls.
My Take#
Kubernetes 1.21 isn’t a release that will generate breathless blog posts about revolutionary new capabilities. And that’s exactly what the ecosystem needs right now. The platform has been growing features at a breakneck pace for years, and the operational reality has been that many of those features sat in alpha or beta for extended periods, leaving operators in a perpetual state of “can I actually rely on this?”
Having thirteen features graduate to stable in a single release is the Kubernetes project saying: “We’re finishing what we started.” That’s maturity. I’ve been running Kubernetes in production since the 1.6 days, and the difference in stability and operational confidence between then and now is night and day.
The PSP deprecation is the right call, even though it creates migration work. Sometimes you have to admit that an approach didn’t work and start fresh with the lessons learned. The new admission controller design looks much more pragmatic — three profiles instead of an infinitely configurable policy space means less room for misconfiguration.
If you’re running 1.20 in production, plan your upgrade path. The immutable Secrets feature alone is worth the effort for large clusters. And if you’re still relying on PSPs, start reading up on the replacement now — two years sounds like a lot of time until you’re six months out and haven’t started.