KYAML in Kubernetes v1.34: A Safer, Leaner Alternative to YAML and JSON

Introduction

In the cloud-native ecosystem, YAML and JSON have been the de facto formats for writing Kubernetes manifests and configuration files. But both come with trade-offs. As of Kubernetes v1.34, a new configuration dialect — KYAML — emerges to bridge the gap: safer than YAML, more flexible than JSON, and fully compatible with existing tooling.

The Case Against Traditional YAML and JSON

YAML: Whitespace Hazards & Implicit Typing

YAML’s human-friendly syntax often hides pitfalls:

• Whitespace sensitivity: A single misplaced space can restructure a manifest unexpectedly — a nightmare in templating systems like Helm.

• Implicit typing: Unquoted values like NO, yes, or 1:23 can be coerced into boolean or numeric types—famously known as the "Norway Bug." For example, country: NO may inadvertently become false. The StrictYAML community removed implicit typing precisely to avoid that kind of ambiguity. The HitchDev blog discusses this problem in depth under the name “The Norway Problem”.

JSON: Valid, But Minus the Human Touch

JSON is stricter and more predictable — no implicit types or indentation issues — but it lacks comments, forbids trailing commas, and mandates quoted keys, making it less practical for human-authored manifest files.

Enter KYAML: The Best of Both Worlds

As revealed in the Kubernetes v1.34 Sneak Peek (July 28, 2025), KYAML is a Kubernetes-specific dialect of YAML designed to eliminate common configuration errors while remaining compatible with existing tooling.

Key features of KYAML include:

• All string values are double‑quoted, avoiding implicit coercion (e.g., "NO" remains a string);

• Flow-style syntax: Always uses {} for mappings and [] for lists, which greatly reduces whitespace sensitivity;

• Comments are allowed, retaining readability and documentation ability — something JSON forbids;

• Trailing commas are permitted, enabling cleaner edits and diffs;

• Unquoted keys by default, unless ambiguous, preserving clarity and brevity;

As a strict subset of YAML, KYAML ensures all valid KYAML is still valid YAML — so existing parsers and tools continue to work seamlessly.

KYAML in Action: Kubernetes v1.34 (Alpha)

In Kubernetes v1.34 (released August 27, 2025), KYAML is introduced as an alpha feature, meaning it’s optional — but available for experimentation.

You can enable KYAML output in kubectl using:

export KUBECTL_KYAML=true
kubectl get <resource> -o kyaml

All existing YAML and JSON output formats remain supported.

Why KYAML Matters

KYAML isn’t just syntactic sugar — it addresses real pain points:

Early adopters report KYAML can reduce deployment errors, especially in GitOps workflows, audit processes, and CI/CD contexts.

The Road Ahead: KEP‑5295 and Community Feedback

KYAML is formalized under KEP‑5295, introduced by SIG CLI. The proposal includes:

• KYAML as a new kubectl output format.

• Plans to eventually make KYAML the standard format for Kubernetes documentation and examples.

Community reactions are mixed. On Reddit, some users praise KYAML for retaining compatibility while reducing ambiguity, while others feel it’s “uglier” or slower to type due to braces and quotes.

Sample Comparison

Traditional YAML (error-prone):

apiVersion: v1
kind: ConfigMap
data:
  country: NO
  version: 1.0

Possible pitfalls: country becomes boolean false, floats inferred, and indentation errors risk breakage.

KYAML Equivalent:

apiVersion: "v1"
kind: "ConfigMap"
data: {
  country: "NO",
  version: "1.0",
}

Clear types, predictable structure — comments allowed, trailing comma included.

Real-World Comparison: YAML vs KYAML in Action

Let’s compare the actual output of a real Kubernetes object — the kubernetes service running in the default namespace—retrieved via kubectl.

YAML Output

kubectl get svc kubernetes -o yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2025-09-06T12:12:51Z"
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
  resourceVersion: "243"
  uid: d1f8264c-60a1-418f-bc69-511aec01691a
spec:
  clusterIP: 172.20.0.1
  clusterIPs:
  - 172.20.0.1
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

This format is readable but carries all the risks of whitespace sensitivity, lack of quoting, and potential type coercion (e.g., None, Cluster, or IPs could be parsed differently in various YAML parsers).

KYAML Output

kubectl get svc kubernetes -o kyaml

---
{
  apiVersion: "v1",
  kind: "Service",
  metadata: {
    creationTimestamp: "2025-09-06T12:12:51Z",
    labels: {
      component: "apiserver",
      provider: "kubernetes",
    },
    name: "kubernetes",
    namespace: "default",
    resourceVersion: "243",
    uid: "d1f8264c-60a1-418f-bc69-511aec01691a",
  },
  spec: {
    clusterIP: "172.20.0.1",
    clusterIPs: [
      "172.20.0.1",
    ],
    internalTrafficPolicy: "Cluster",
    ipFamilies: [
      "IPv4",
    ],
    ipFamilyPolicy: "SingleStack",
    ports: [{
      name: "https",
      port: 443,
      protocol: "TCP",
      targetPort: 6443,
    }],
    sessionAffinity: "None",
    type: "ClusterIP",
  },
  status: {
    loadBalancer: {},
  },
}

Here we clearly see KYAML’s strengths:

• All strings are explicitly quoted

• Flow-style syntax makes the structure explicit

• Comments are allowed (not shown here, but supported)

• Trailing commas allowed for clean diffs

Even a subtle misinterpretation like None being treated as a Python-style null (instead of a string) is avoided thanks to strict quoting.

Conclusion: Do We Really Need a YAML-JSON Hybrid?

KYAML — introduced in Kubernetes v1.34 under KEP‑5295 — is clearly an attempt to bring predictability and structure to the sometimes frustrating world of YAML-based configuration.

It solves real problems: it removes implicit typing, supports trailing commas and comments, and avoids whitespace-related bugs. It’s fully backwards compatible with YAML tooling and enables safer GitOps workflows. On paper, it’s an elegant step forward.

But speaking honestly… I’m still not sure if I like it.

At first glance, KYAML looks a lot like JSON, especially due to its flow-style syntax with {} and []. That resemblance can be disorienting, especially when you’re expecting a YAML file. It introduces more visual noise—quotes, commas, and brackets—which can make simple configurations feel bloated compared to traditional YAML.

Do we really need a hybrid between YAML and JSON?
Or are we just adding another format to an already overloaded toolchain?

It feels like a compromise between two imperfect formats — trying to be safer than YAML while remaining more user-friendly than JSON. But compromises can sometimes bring new complexity rather than clarity.

That said, it’s still early days. KYAML is in alpha, and its adoption will likely depend on how tooling, IDEs, and human workflows evolve around it. If it gains traction, KYAML could become the default in Kubernetes’ future — but whether it becomes loved is another matter.

Bonus: KYAML Meme of the Month

Spotted on Twitter recently:

And… well, they’re not wrong.
KYAML definitely looks like that kind of hybrid at first sight. 🐧➕🐘 = 🤯