KYAML Is Stable: Kubernetes Finally Fixes Its YAML Problem

Kubernetes 1.37 shipped on September 4 and most coverage fixated on scale-to-zero and gang scheduling. Meanwhile, the release also promoted KYAML to Stable — a change that directly affects every developer who has ever spent 40 minutes debugging a Kubernetes deployment only to find the culprit was a YAML value silently parsed as a boolean. KYAML is Kubernetes’ answer to the broken parts of standard YAML. It is now stable, it costs nothing to adopt, and it eliminates an entire class of configuration bugs.

The Problem With YAML in Kubernetes

YAML is the worst configuration format in widespread use, except for all the others. The specific problem in Kubernetes is that virtually all tooling — kubectl, Helm, kubeconform, most operators — still uses YAML 1.1, a spec that makes some genuinely strange decisions about implicit type coercion.

The canonical example is the Norway Bug. In YAML 1.1, unquoted NO is parsed as boolean false. Same with yes, on, off, and their capitalisation variants. Put this in a Helm values file:

region: NO
featureFlag: ON

You are not setting strings. You are setting booleans. This has caused documented production incidents — teams filtering by country code “NO” (Norway) and getting nothing back, feature flags resolving incorrectly, application startup failures that take half an hour to trace to a YAML parsing quirk. Indentation is the other major failure mode: block-style YAML is whitespace-sensitive, and Kubernetes will accept a manifest where a key landed in the wrong nested object because of a two-space error, with no error message until runtime.

What KYAML Actually Is

KYAML is a strict subset of YAML — meaning every KYAML file is valid YAML. No parser changes are needed. kubectl, Helm, Flux, and ArgoCD all read it today without any updates.

The restrictions KYAML imposes are targeted. According to the official KYAML reference:

• Flow style only. Maps use {}, lists use []. No indented block style.
• All strings must be double-quoted. region: "NO" is valid. region: NO is not KYAML.
• No implicit type coercion. The Norway Bug is structurally impossible to write in KYAML.
• Comments and trailing commas are allowed. Unlike JSON, KYAML stays human-editable.

The result reads a bit like JSON but feels closer to YAML — and critically, removes the footguns that have been biting Kubernetes users for years.

How to Use KYAML Right Now

The most immediate change in Kubernetes 1.37 is that -o kyaml is now stable in kubectl:

kubectl get deployment my-app -o kyaml

Previously, -o yaml returned block-style YAML with unpredictably quoted values. With -o kyaml, the output is deterministic: every string is quoted, every type is explicit. This matters when you are scripting against kubectl output or diffing live state against Git-managed manifests.

Here is what the difference looks like in practice:

# kubectl get -o yaml (block style, implicit types)
metadata:
  name: my-app
  labels:
    region: NO        # silently becomes false in some parsers
    replicas: 3

# kubectl get -o kyaml (flow style, explicit types)
{"apiVersion": "apps/v1", "kind": "Deployment", "metadata": {"name": "my-app", "labels": {"region": "NO", "replicas": "3"}}}

For Helm users, KYAML is particularly valuable in templates. The indent and nindent helper functions exist entirely to manage indentation in block-style YAML. Flow-style KYAML does not care about leading whitespace. That class of template bug disappears.

Should You Migrate?

Migration is optional and nothing breaks if you skip it. Your existing manifests, Helm charts, and CI pipelines are unchanged. kubectl apply -f manifest.yaml keeps working exactly as before.

The practical path forward: start using kubectl get -o kyaml for live resource inspection and scripting — this is free and immediate. For new manifests and Helm values files, consider writing in KYAML from day one. For existing manifests, migration is a “when it causes you pain” project, not an urgent task.

The direction of travel is clear. InfoQ notes that the Kubernetes community frames KYAML as the recommended output format going forward, and The New Stack reports Helm maintainers have already discussed native KYAML output. GitOps tools that live and die by manifest diffs are a natural fit. KYAML reaching Stable is the signal that the ecosystem is ready to move.

The Norway Bug has been documented in Kubernetes contexts since at least 2018. Eight years later, there is now an official fix in the tooling. Start using it.