Kubernetes v1.34 — KYAML, Pod Budgets, and Why This Release Feels Different
Kubernetes 1.34 (Of Wind & Will) is out, and as usual, the changelog is a small novel. But instead of throwing 58 features at you, let’s zoom in on a few that actually make daily life better — the things you’ll care about when YAML gremlins ruin your Friday night deploy or when your sidecar insists on hogging more CPU than your actual app.
For me, the headliners are:
- KYAML — finally, YAML that doesn’t turn on you like a bad roommate.
- Pod-level Resource Requests & Limits — your pods now get a proper “budget” instead of everyone fighting over allowances.
- (Bonus) Tracing in kubelet & API server — because “why is my pod pending?” deserves an actual answer.
KYAML — Because Regular YAML Was Gaslighting Us
YAML has always been the friend who says “don’t worry, I got this,” and then eats the last slice of pizza. It looks friendly, it feels lightweight — until you realize that NO suddenly means false and your app won’t start in production because of a single missing quote.
Enter KYAML, a Kubernetes-specific subset of YAML. Think of it as YAML after a few years of therapy: stricter boundaries, fewer surprises, still compatible with the rest of the family.
- Strings must be quoted. (
"NO"means"NO", notfalse.) - Lists and maps use explicit brackets.
- Diffs are cleaner, merges are safer, and tools can actually trust the syntax.
In real life? Imagine Helm charts that don’t break because of an indentation snafu. Or CI pipelines that don’t silently interpret a config key as a boolean. KYAML is still alpha, but if it grows up healthy, it could save us countless “why the heck won’t this deploy” hours.
Pod-Level Resource Requests & Limits — Finally, a Shared Budget
Until now, every container in a pod had to declare its own resource requests and limits. It’s like every roommate in a flat having their own fridge and pretending they’ll never share groceries. Inefficient and, frankly, silly.
With Kubernetes v1.34, you can give the whole pod a CPU and memory budget. The containers inside can then work it out among themselves.
Example scenario:
- You’ve got a main app container and a sidecar for logging.
- The app needs predictable performance, but the sidecar occasionally spikes.
- Instead of over-provisioning both “just in case,” you say:
resources:
requests:
cpu: "1"
memory: "2Gi"
limits:
cpu: "2"
memory: "4Gi"
Now they share. If the sidecar gets hungry for CPU during a batch job, it borrows from the budget. If your app container suddenly spikes, it gets priority.
This is beta in v1.34 (KEP-2837), but it’s already enabled by default. The scheduler and autoscaler also understand pod-level budgets, which means less wasted capacity and saner scaling decisions.
Real life win: sidecars, proxies, or background agents won’t force you to constantly guess “how much CPU is too much?” Pods finally behave more like the single logical unit we always said they were.
Tracing — Because “It’s Stuck” Is Not an Answer
We’ve all been there: kubectl get pods shows “Pending,” you dig around logs, and eventually discover some obscure bottleneck between scheduler and kubelet.
With v1.34, tracing is now wired into the kubelet and API server using OpenTelemetry. That means you can literally follow the journey of your pod request through the system. It’s like putting AirTags on your workloads.
This isn’t a shiny end-user feature, but for SREs and platform engineers, it’s a gift. Debugging goes from “black box” to “traceable pipeline,” and suddenly you know where things are slow, not just that they’re slow.
Why These Three Matter
- KYAML: fewer hacks, less yak-shaving, safer manifests.
- Pod-level resources: better efficiency, fewer overprovisioned nodes, less swearing at sidecars.
- Tracing: actual visibility when Kubernetes says “¯_(ツ)_/¯ Pending.”
Together, these aren’t massive, headline-grabbing changes. They’re the kind of quality-of-life improvements that chip away at the everyday frustrations of running Kubernetes. And honestly, that’s the kind of progress we should celebrate.
