← Blog
#Kubernetes#DevOps#Cloud Infrastructure#DRA

Kubernetes 1.37 Preview: KYAML, Pod-Level Resources, and DRA Device Taints Go Stable

webhani·

What's coming on August 26

Kubernetes 1.37 is scheduled for release on August 26, 2026, and the project's sneak-peek posts give a good early read on what's graduating to stable this cycle — 16 enhancements in total. Three stand out for teams running production clusters: KYAML output, pod-level resource requests, and GA for DRA device taints and tolerations. None of these are flashy on their own, but each one changes a workflow that platform teams touch constantly.

KYAML: fixing YAML's sharp edges

KYAML is a YAML dialect, compatible with existing tooling, that applies opinionated formatting rules to avoid the well-known footguns in plain YAML — the classic example being the "Norway problem," where an unquoted NO gets silently parsed as boolean false instead of the string "Norway." If you've ever debugged a manifest where a country code, a version string, or an abbreviation got coerced into the wrong type, you already know why this matters.

KYAML becoming a stable output option for kubectl means you can get manifests back in a form that's harder to misparse, without switching your entire toolchain away from YAML. For teams maintaining large GitOps repositories, this is worth testing directly:

# once available, compare kubectl's default output against KYAML output
kubectl get deployment my-app -o yaml
kubectl get deployment my-app -o kyaml

Diff the two for any resource with ambiguous scalar values in your manifests — version strings, region codes, feature-flag-like keys — and you'll likely find at least one place where the distinction matters.

Pod-level resources

Pod-level resource requests and limits graduate to stable in 1.37. Historically, Kubernetes resource requests and limits are set per-container, which forces awkward workarounds when you want to budget resources across an entire pod that has multiple containers — sidecars, init containers, and the main workload all competing for a shared ceiling. Setting limits at the pod level lets you express "this pod, in total, should not exceed X" without manually dividing that budget across every container and hoping the split holds under real traffic.

This matters more as sidecar patterns (service mesh proxies, logging agents, security scanners) become the default rather than the exception in production deployments. If your clusters run a lot of multi-container pods, this is one of the more immediately useful stable features in this release.

DRA device taints and tolerations reach GA

Dynamic Resource Allocation (DRA) has been maturing across several releases, and in 1.37 the device-taints-and-tolerations enhancement reaches General Availability. This lets DRA drivers — or cluster operators, via user-defined DeviceTaintRule objects — mark specific hardware devices (typically GPUs or other specialized accelerators) as tainted:

  • A NoSchedule taint blocks new pods from being scheduled onto degraded or offline hardware.
  • A NoExecute taint can evict pods currently running on a device, useful for planned maintenance windows.
  • Workloads that specifically need to tolerate a taint (for debugging a flaky device, for instance) can add matching tolerations directly to their ResourceClaim.

For teams running GPU-backed workloads — increasingly common given how much AI/ML infrastructure now sits on Kubernetes — this closes a real operational gap. Before this, taking a degraded GPU node out of rotation cleanly, without editing node-level taints that affect unrelated workloads, required more manual coordination than it should have.

A rough shape of what a DeviceTaintRule looks like conceptually:

apiVersion: resource.k8s.io/v1
kind: DeviceTaintRule
metadata:
  name: gpu-maintenance-window
spec:
  deviceSelector:
    driver: example.com/gpu-driver
    pool: gpu-pool-a
  taint:
    key: maintenance
    value: "scheduled"
    effect: NoExecute

Treat this as illustrative rather than a copy-paste manifest — validate the exact schema against the 1.37 API reference once it's released, since DRA's API surface has been evolving release over release.

What to check before upgrading

  1. Audit your GitOps pipelines for YAML-sensitivity. If any config-generation step relies on YAML's default (sometimes surprising) type coercion, KYAML output changes could expose that fragility — in a good way, but budget time to review the diffs.
  2. Review multi-container pods for resource-limit assumptions. If tooling or dashboards currently sum per-container limits to infer pod-level ceilings, check whether that logic needs updating once pod-level limits become a first-class field.
  3. If you run DRA-managed hardware, plan your taint rollout. GA status is a good signal to move device-taint automation out of "watch and wait" and into your maintenance runbooks.
  4. As always with a .0 release, hold production upgrades until at least one patch release, and test against a staging cluster first — new GA features tend to surface edge cases in their first few weeks in the wild.

Takeaways

None of 1.37's headline features are dramatic on their own, but together they reflect where Kubernetes is spending its maturity budget: fixing long-standing rough edges (YAML ambiguity, per-container-only resource limits) and hardening newer subsystems (DRA) that increasingly carry GPU and AI workloads. At webhani, we help clients plan Kubernetes upgrade cycles that account for exactly this kind of incremental, unglamorous improvement — it's usually where the real operational payoff is.

References: Kubernetes v1.37 Sneak Peek (kubernetes.io), Kubernetes 1.37: What You Need to Know (Cloudsmith), Kubernetes 1.37 Release: New Features, Beta & Stable Changes (PerfectScale)

← Back to Blog