How to validate a Kubernetes manifest

What is a Kubernetes manifest?

When software teams deploy an application to Kubernetes, that application must be ready to be containerized and run in a container runtime. Once that happens, developers must be able to specify different aspects of that application's deployment within the cluster. To accomplish this, they turn to Kubernetes manifests.

A Kubernetes manifest is a YAML-formatted way to interact with the Kubernetes API. It specifies the desired state of an application by defining aspects such as the following:

• what type of spec to run;
• what container image to use;
• ports the application will run on; and
• secrets or environment variables that will pass into the application.

Developers define the above qualities through Kubernetes mappings and lists via key/value pairs. Below is an example of a Kubernetes manifest, sourced from the Kubernetes deployments page:

apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
 spec:
   selector:
     matchLabels:
       app: nginx
   replicas: 2
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: nginx
         image: nginx:1.14.2
         ports:
         - containerPort: 80

The Kubernetes manifest specifies how the entire application runs. This ensures that Kubernetes deploys the application properly.

Potential validation problems

Before the dev team attempts to validate a Kubernetes manifest, they must consider some of the problems that can occur during this process.

The biggest and most common problems with a Kubernetes manifest are the following:

• formatting
• the API in use
• mandatory fields

Developers format Kubernetes manifests with indents, much like the formatting in programming language Python because that is YAML style. There are challenges to this approach. In other formatting styles, such as JSON, the start/stop of a block is inside of brackets. YAML uses indents instead. When indenting a Kubernetes manifest, developers cannot use the Tab key. Instead, they must use spaces. In the example code of the Kubernetes manifest, there are two indents after labels: and before app:nginx.

Another potential issue lies with the API in use for the Kubernetes spec. The first line of the above code reads apiVersion:. That tells Kubernetes what APIs to use. There's the core API group, which is the original Kubernetes functionality. It includes deployments, pods and ConfigMaps. There are also the named API groups, which is where all the new APIs go. In addition, API betas may have their own unique API version. Validate the correct API for the correct resource spec or risk failures.

Mandatory fields can also create problems for a Kubernetes manifest. Some fields are required, and the code won't run without them. If a certain mandatory field is not incorporated, the manifest will not work properly.

How to validate a Kubernetes manifest

Several tools can validate a Kubernetes manifest, all of which are on GitHub. A few are the following:

• Kubeval
• Config-lint
• Kube-score

While third-party tools are useful, there is a native way in Kubernetes to validate manifests, via the --dry run flag in kubectl. This option is already at the hands of developers using Kubernetes right now.

For example, using the --dry-run command generates an output similar to Figure 1.

To demonstrate how manifest validation tools work, we can install and run Kubeval.

Kubeval can validate one or more Kubernetes manifests.

First, install the Kubeval application. Kubeval has many installation options. For this demonstration, I'm using Apple macOS. Installation is through the following Homebrew package installer library:

brew tap instrumenta/instrumenta brew install kubeval

Next, developers can run the kubeval command against any Kubernetes manifest. Figure 2 shows a successful pass.

Figure 3 shows an unsuccessful pass.

The error output is because I changed apps/v1 to apps/v in the manifest in order to produce an error.

What about policy as code?

Developers can use policy as code to create a set of rules and expectations. For example, policy as code can be useful when a team uses the latest version of a Docker image but the team lead wants to ensure that they use a specific version instead. The team lead could set up a policy that would say "don't let anyone run the latest version of this Docker image." Then, if someone tried, the policy would kick in, and the deployment would fail.

One tool for policy-as-code implementation is Checkov, which developers can use to run static code analysis via a set of policies.