Kubernetes Manifest Files Explained

Last updated
October 20, 2023
Cortney Nickerson
Developer Advocate
Monokle

Table of Contents

Get started with Monokle today

Get started with Monokle today

Now that your company has decided to embrace Cloud-native and microservices software architecture, you’ve suddenly been thrust into the whimsical, and somewhat confusing, world of Kubernetes. So, let’s get down to research! Put on your learning Monokle and let’s dive into  Kubernetes Manifest files!

What is a Kubernetes Manifest file?

A Kubernetes Manifest file is a YAML or JSON file that describes the desired state of a Kubernetes object. These objects can include deployment, replica set, service, and more. Manifest files define the specifications of the object, such as its metadata, properties, and desired state. 

Also known as a YAML or JSON file, it describes the desired state of a Kubernetes object: deployment, replica set, service etc… 

Simple, yah? 

But don’t underestimate the needs of your Desired State. Manifest files are powerful tools that allow devs to deploy, scale and manage your Kubernetes clusters and ultimately enable consistent infrastructure that (hopefully) makes your deployment life easier.  

Speaking of, what exactly is a “Desired State” when it comes to Kubernetes Manifests?  

Simply put, it’s the state you want your objects to be in (I guess you could say, it’s your ideal “manifestation” ha. ha.) including the images used, number of replicas, and anything else you desire! Once you’ve clearly visualized your Desired State, Kubernetes acts to automatically deploy and manage your carefully crafted object, keeping it in its, “Desired State”.

 Understanding Kubernetes Manifests 

Before you can create or manage Kubernetes objects, you must first understand the importance of Manifests: 

Kubernetes Manifests are composed of three parts: 

Metadata which includes object labels, name and annotations 

Specification which defines the desired state of the kubernetes object, its properties and configurations. 

And finally, Status: the section that describes the true state of an object, the number of replicas and your current version. 

Example of Kubernetes Manifest Files

Below, is what your Manifest File should look like: 

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment

spec:

  replicas: 3

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

      - name: my-container

        image: my-image:latest

        ports:

        - containerPort: 80

This example defines a deployment object with three replicas. It includes a Pod template with one container and uses the image "my-image:latest" and is listening on containerPort: 80.  

Remember, the syntax and structure of your Manifest File will vary depending on the defined resource. Make sure to review, and test to ensure successful deployment and management of your Kubernetes Clusters (link to article on cluster management) 

If you’re worried about catching errors, and being able to edit them, don’t worry! We have a tutorial for that over here (insert link)

Common Errors in Kubernetes Manifest (link to article)

So, what exactly does an error in a Kubernetes Manifest look like? Well, the most common errors are YAML formatting errors, property names with simple typos, invalid values and JSON syntax errors (insert links to related articles). 

But, in my experience, the most common error is similar to what I do with my keys: forgetting. Specifically, forgetting to include required properties for your objects like image names for containers.  

Fortunately, Monokle has an easy solution if you happen to leave your specified properties behind on the counter (link to article).  

Enough about my chaotic morning, let’s take a closer look at some of these errors, shall we? 

Yaml File Format Errors 

Formatting YAML Errors can cause a whole slew of fun problems to solve, here are some of the typos we see regularly: 

  • Missing colon after a property name

containers

- name my-app

  • Missing closing quotation mark

env:

- name: MY_ENV_VAR

value: "my-value

  • Incorrect indentation

env:

- name: MY_ENV_VAR

   value: "my-value"

Property name typos 

Misspelled property names in Kubernetes Manifests can easily cause issues with deployment and application management. Make an English teacher and check, double check and triple check that all your property names are spelled correctly and match the specifications of the defined object.

Misspelled property names come in a variety of flavors, like the heavy handed, “imageee” instead of “image” or swapping “prot” instead of “port”. Careful eyes, or adding another pair of fresh ones, can help catch these errors- 

before it’s too late… 

(I’m only kidding. Monokle is really good at catching errors and letting you edit them as you go. Check out our genius solution to sticky keyboard fingers here) 

Invalid values for properties 

Invalid values for properties can really mess up your deployment and management. 

Specifying non-existent images can confuse your deployment the same way pretending to throw the ball confuses your poor dog. Make sure the ball is real, and ensure that all your property values are valid, and match the specifications of any object being defined.

About Monokle

Monokle helps you achieve high-quality Kubernetes deployments throughout the entire application lifecycle—from code to cluster. It enables your team to define Kubernetes configuration policies to ensure consistent, secure, and compliant application deployments every time. In addition to policy enforcement, Monokle’s ecosystem of tools make your team’s daily YAML configuration workflows easier. Get started with Monokle for free.

Related topics: