Manifestly Safer, Why Kubernetes Wants Developers to Speak KYAML

Kubernetes project leaders want software application developers to pay attention to KYAML, a stricter dialect of YAML (the human-readable data serialization language used primarily for writing configuration files cleanly), and this is primarily because KYAML is built to make Kubernetes configuration more explicit, predictable, and more capable of avoiding common YAML errors. 

KYAML (just in case it wasn’t obvious) stands for Kubernetes YAML.

It is a strict, whitespace-insensitive (formatting that does not alter data structure or execution) subset of YAML designed for Kubernetes configurations to eliminate syntax ambiguity, formatting errors, and implicit type coercion. 

A Regional Dialect Of YAML

Considered to be a dialect (almost like a regional accent) of standard YAML, KYAML is designed to be parseable by the existing ecosystem without needing any changes, as proposed in KEP 5295. A KEP (Kubernetes Enhancement Proposal) is a formal document proposing and tracking Kubernetes features.

It does not introduce a new format or a new parser. It just narrows the scope of choices you make when writing YAML, so everyone ends up making the same ones.

DevOps intern and Kubernetes organization member, Kashish Verma, blogs this month to say that YAML has been the standard way to write Kubernetes manifests for years. She notes that every example, tutorial, and configuration file developers come across is written in it., but the problem isn’t that YAML is a bad format. 

The issue, as far as her team measures it, is that YAML gives coders a lot of choices, and not all of them are equally good for writing Kubernetes manifests. Some features make files harder to read, some are easy to misuse, and others can lead to surprising behavior.

“The interesting part is that Kubernetes doesn’t actually need most of those features. It only relies on a small subset of YAML. This led to a simple question: If Kubernetes only needs a small part of YAML, why not standardize on that part and avoid the rest? Instead of introducing a new configuration language, SIG CLI introduced KYAML, a stricter, more consistent way to write YAML,” said Verma.

Indentation Frustration Situation

Another problem is that indentation defines structure in YAML. As developers will know, indentation structure means using spaces to define nested relationships, where misplaced spacing alters object hierarchy without throwing a syntax error.

Because indentation defines structure in YAML, a wrongly indented file can remain syntactically valid while representing a different object than intended. Verma says that this “gets especially painful” with templating tools like Helm, where developers are manipulating indentation from outside the YAML context.

She also highlights the fact that string quoting is optional in YAML. String quoting wraps text in single or double quotes to explicitly declare it as string data, preventing YAML from misinterpreting characters or automatically converting values into other data types. 

Although this appears useful and convenient, it is in fact the opposite.

Some values that look like strings get coerced into other types without warning. The classic example is the “Norway Bug”. The Norway bug occurs when unquoted country codes like NO are implicitly parsed as boolean False instead of the string “NO”, because standard YAML evaluates NO (along with yes, no, true, false) as boolean values.

Developers, Should You KYAML?

The good news here is that every valid KYAML file is, essentially, a valid YAML file. This means that software application developers writing in KYAML will find that existing tools can all stay intact and do not need to change… and we’re talking about everything from kubectl to the Continuous Integration (CI) pipeline. 

Programmers can also pass KYAML as input to any version of kubectl, not just 1.34+, because, as we said, KYAML is a dialect of YAML so it is just YAML.

Verma concluded by saying that KYAML “is not strictly necessary” and that developers can keep writing block-style YAML and things will work. But it is a deliberate choice to make your configs less error-prone and more consistent, especially across a team or a larger repo. She says it’s less of a migration and more of a better habit.