YAML Line Options in Kubernetes ConfigMaps

I was recently asked about some formatting options that a peer saw in a Kubernetes manifest for a ConfigMap resource. Because these manifests conform to the YAML spec, I was able to refer to a very specific resource for this purpose, but thought I’d run through it for the sake of completeness here.

Given a ConfigMap for data like:

  someKey: |-

The question centered around the pipe | and the minus sign - characters (in combination), and what their purpose was in a block like the above. I directed my peer to the YAML Spec for each of these items:

Literal Style

Block Chomp Indicator

but want to demonstrate the output as far as Kubernetes is concerned.   The | literal indicated that the following is a multi-line value, and that tabs, backslashes, etc. are considered content (everything at the proper level of indentation after the data key name), meaning that they will be rendered along with the rest of the block.

The - chomping indicator instructs, when the YAML is rendered, that the final line break is removed (ending at the line the last character appears on, rather than a trailing line), rather than preserving (+) trailing lines.

So, with this in mind, let’s look at an example, where we’ll indicate we’d like to strip the trailing line breaks, and one where we’ll preserve it:

kind: ConfigMap
apiVersion: v1
  name: test-configmap
  chomp.strip: |-

  chomp.keep: |+

In chomp.strip, we’ll use - to indicate we’d like the line breaks stripped after the last line with data, and in chomp.keep, we’ll preserve it.

To validate the formatting came out as expected, let’s run kubectl describe configmap/test-configmap:

jmarhee@y2k-stepdad [19:47] ~ » kubectl describe configmap/test-configmap
Name:         test-configmap
Namespace:    default
Labels:       <none>
Annotations:  <none>


Events:  <none>

and, as you see above, the formatting was preserved per that chomping indicator we set!

Kubernetes resources conform to the YAML spec (though the reverse isn’t always the case), so I recommend, if you found this useful, that you take a look at the rest of the spec (worth a read, at least once!) and see where else in your manifests you can benefit from knowing your formatting options.