Home

Awesome

kubectl-neat

Remove clutter from Kubernetes manifests to make them more readable.

Demo

Here is a result of a kubectl get pod -o yaml for a simple Pod. The lines marked in red are considered redundant and will be removed from the output by kubectl-neat.

demo

Why

When you create a Kubernetes resource, let's say a Pod, Kubernetes adds a whole bunch of internal system information to the yaml or json that you originally authored. This includes:

If you try to kubectl get resources you have created, they will no longer look like what you originally authored, and will be unreadably verbose.
kubectl-neat cleans up that redundant information for you.

Installation

kubectl krew install neat

or just download the binary if you prefer.

When used as a kubectl plugin the command is kubectl neat, and when used as a standalone executable it's kubectl-neat.

Usage

There are two modes of operation that specify where to get the input document from: a local file or from Kubernetes.

Local - file or Stdin

This is the default mode if you run just kubectl neat. This command accepts an optional flag -f/--file which specifies the file to neat. It can be a path to a local file, or - to read the file from stdin. If omitted, it will default to -. The file must be a yaml or json file and a valid Kubernetes resource.

There's another optional optional flag, -o/--output which specifies the format for the output. If omitted it will default to the same format of the input (auto-detected).

Examples:

kubectl get pod mypod -o yaml | kubectl neat

kubectl get pod mypod -oyaml | kubectl neat -o json

kubectl neat -f - <./my-pod.json

kubectl neat -f ./my-pod.json

kubectl neat -f ./my-pod.json --output yaml

Kubernetes - kubectl get wrapper

This mode is invoked by calling the get subcommand, i.e kubectl neat get .... It is a convenience to run kubectl get and then kubectl neat the output in a single command. It accepts any argument that kubectl get accepts and passes those arguments as is to kubectl get. Since it executes kubectl, it need to be able to find it in the path.

Examples:

kubectl neat get -- pod mypod -oyaml
kubectl neat get -- svc -n default myservice --output json

How it works

Besides general tidying for status, metadata, and empty fields, kubectl-neat primarily looks for two types of things: default values inserted by Kubernetes' object model, and common mutating controllers.

Kubernetes object model defaults

For de-defaulting Kubernetes' object model, we invoke the same code that Kubernetes would have, and see what default values were assigned. If these observed values look like the ones we have in the incoming spec, we conclude they are default. If they weren't, and the user manually set a field to it's default value, it's not a bad thing to remove it anyway.

Common mutating controllers

Here are the recommended admission controllers, and their relation to kubectl-neat:

controllerdescriptionneat
NamespaceLifecyclerejects operations on resources in namespaces being deletedignore
LimitRangerset default values for resource requests and limitsignore
ServiceAccountset default service account and assign tokenRemove default-token-* volumes. Remove deprecated spec.serviceAccount
TaintNodesByConditionautomatically taint a node based on node conditionsTODO
Priorityvalidate priority class and add it's valueignore
DefaultTolerationSecondsconfigure pods to temporarily tolarate notready and unreachable taintsTODO
DefaultStorageClassvalidate and set default storage class for new pvcignore
StorageObjectInUseProtectionprevent deletion of pvc/pv in use by adding a finalizerignore
PersistentVolumeClaimResizeenforce pvc resizing only for enabled storage classesignore
MutatingAdmissionWebhookimplement the mutating webhook featureignore
ValidatingAdmissionWebhookimplement the validating webhook featureignore
RuntimeClassadd pod overhead according to runtime classTODO
ResourceQuotaimplement the resource qouta featureignore
Kubernetes Schedulerassign pods to nodesRemove spec.nodeName