Hey {{first name | there}}. This past week I read this fantastic piece by Craig Risi over at InfoQ about the work the Kubernetes team is doing to encourage developers to consider adopting KYAML. 

As the title hinted, my first reaction was, “great, more YAML”, but perhaps there is something here. 

In today's technical notes:  

  • WTH is KYAML 

  • Why we should care 

  • Why I am willing to try it.

📰Technical notes: Hold on, K. YAML? 

Although I am writing about this now, KYAML has been around for quite some time; more specifically, it was part of KEP-5295, which is the Kubernetes enhancement proposal that sought to introduce it into the project in May of 2025

At this stage, you are likely staring  at the screen like:

 To quote directly  from the enhancement proposal:

This format is a strict subset (aka "dialect") of standard YAML, and so should be parseable by the existing ecosystem. This dialect seeks to emphasize syntactical choices which avoid many of the most common traps in YAML. For example, unlike standard YAML output, this dialect is not whitespace-sensitive, which makes it vastly easier to patch correctly in things like Helm charts.

So….. what is wrong with YAML?

While researching for this issue, I came across this blog by  CNCF Ambassador ChengHao Yang, which concisely describes the Norway problem. 

Simply put, if you had an array of countries such as 

This YAML converts to JSON like this: 

This is great, until you try to add it in Norway. 

In an ideal world, the resulting JSON should look like:

But in reality, it becomes:

Per the YAML specification  

YAML allows scalar content to be presented in several formats. For example, the boolean “true” might also be written as “yes”.

In other words, this isn’t a bug. It’s a feature. Something like Yes, which looks like a string, gets treated as the boolean true. Same story for NO, ON, OFF, Y, and N.

JSON should work, right?

Anyone who has written an operator knows Kubernetes already accepts JSON. The issue is JSON doesn’t support comments, it’s precious about trailing commas, and it wants every key quoted. 

Fine for machines. Worse for manifests you actually have to read. And most of the tooling around Kubernetes, Helm especially, is built around YAML. Switching everything to JSON was never going to happen. Making YAML stricter was.

Okay, so what is KYAML actually?

Not a new language. YAML with fewer choices.

The KEP boils it down to four rules:

  1. Always double-quote value strings, so NO stays "NO"

  2. Leave keys unquoted unless they’re unsafe (no would always be quoted)

  3. Always use {} for maps and structs

  4. Always use [] for lists

Taken together, it isn’t whitespace-sensitive. YAML calls this flow style. It looks a lot like JSON, because it is adjacent to JSON, with three differences that matter for config: comments are allowed, trailing commas are allowed, and keys don’t have to be quoted. It also starts with --- so you can tell it apart from a JSON blob that happens to start with {.

Ugly? A little. Ambiguous? Much less.

And you don’t have to rewrite anything by hand. Since 1.34:

kubectl get deploy my-app -o kyaml

In 1.34, that was alpha, behind KUBECTL_KYAML=true. From 1.35, it’s on by default. There are still no plans to make it the default output, which is the right call.

Why we should care

The Norway problem is a fun example. The reason this shipped is Helm.

Wrongly indented YAML is still valid YAML. It just represents a different object than the one you thought you wrote. That’s annoying in a hand-edited Deployment. It’s miserable in a Helm chart, where you’re templating whitespace from outside the YAML and praying indent / nindent line up.

Why I am willing to try it

I’m not converting every chart in a repo because a dialect got a blog post.

What I am willing to do is the cheap experiment. kubectl get -o yaml versus kubectl get -o kyaml. Same object, quoted strings, braces instead of indentation, and I can paste it into any tool that already speaks YAML. If I hate how it looks, I go back to block style. Nothing on the cluster moved.

That’s what got me past “great, more YAML.” It isn’t CUE. It isn’t Jsonnet. It isn’t a new parser or a migration weekend. It’s an opinionated way to print a format we’re already stuck with.

I still don’t want it as the default. Conventional YAML is easier to skim for small objects. Using it for generated output, for charts, and for anything an agent might rewrite, feels like the right place to start.

Where this leaves you

If you’re on kubectl 1.34 or newer, run kubectl get deploy -o kyaml against something you already know well. That’s the whole trial.

If you want to convert files, yamlfmt -o=kyaml exists. You don’t need to boil the repo.

If you maintain Helm charts, this is who the KEP was written for. Worth trying on the next chart that has already made you angry.

And if your team is still going to write block-style YAML until the heat death of the cluster, that’s fine. Kubernetes isn’t making this the default.

🌍IN THE ECOSYSTEM

How to Pretty-Print Your Kubernetes YAML as KYAML — official Kubernetes blog: what it is, the YAML vs KYAML Pod example, and how to get the output.

What is KYAML? KEP-5295 Reading Notes — ChengHao Yang on the Norway problem and why “KYAML is YAML, but not all YAML is KYAML.”

Kubernetes Promotes KYAML as a Safer, More Consistent Way to Work with Manifests — Craig Risi’s InfoQ piece on why a stricter dialect matters as more manifests get generated.

⏱️UNTIL NEXT TIME

That’s it for this issue. If you try -o kyaml this week, reply and tell me whether it looks like a fix or like JSON in a cheap disguise. Especially if you try it inside a Helm chart.

Know an engineer who will find this helpful? Share this link with them

Jubril Oyetunji
CTO, EverythingDevOps

HOW DID WE DO?

Login or Subscribe to participate