Kubernetes 1.37 “Garhwal” is out, and the headline change is KYAML reaching stable.

The problem KYAML solves

YAML is a difficult configuration language that everyone uses anyway, and Kubernetes made it the default interface to an extremely complex system. The failure modes are well known and still bite people constantly:

The Norway problem. NO parses as boolean false. So does no, off, and n. A country code, a disabled flag, or a two-letter identifier can silently become false.

countries:
  - NO    # this is the boolean false
  - SE    # this is the string "SE"

Sexagesimal integers. In YAML 1.1, 22:30 parses as 1350. Time values and version strings have both been caught by this.

Significant whitespace with no delimiters. A manifest indented one space wrong is frequently still valid YAML, describing something other than what you meant, and the error surfaces as a runtime behaviour rather than a parse failure.

Silent type coercion generally. 1.10 becomes the float 1.1, dropping the trailing zero, which matters when it was a version number.

KYAML is a constrained subset with stricter, more predictable parsing. Strings stay strings. Ambiguous scalars are not guessed at. The result is that what you wrote is what the API server receives.

What this means in practice

KYAML being stable means it can be relied on in production tooling. Existing YAML continues to work, so nothing breaks, but new manifests can be written in a dialect that does not silently reinterpret values.

The place this matters most is generated configuration. Templating engines and tools that produce manifests programmatically are where quoting bugs are hardest to spot, because nobody reads the intermediate output. Helm charts have produced this class of bug for years.

# worth doing regardless of dialect
kubectl apply --dry-run=server -f manifest.yaml

Server-side dry run catches what client-side validation misses, because it runs admission controllers and defaulting.

Wider context

If you are running Kubernetes yourself rather than consuming a managed offering, upgrades follow the usual pattern: control plane first, then nodes, one minor version at a time, with deprecated API removals checked before you start.

For smaller deployments, k3s remains the more sensible starting point, and our k3s guide covers that. Full Kubernetes is a lot of machinery for a workload that fits on one server, and Docker Compose is frequently the correct answer instead.

The container fundamentals underneath are the same regardless, and our Docker and Podman basics covers those.