YAML Basics: A Beginner’s Guide to YAML Manifests

There’s no escape from the YAML monster if you’re doing anything related to Kubernetes and here we’ll give you the knowledge needed to conquer this best. 

Have no fear, there are many tools out there to help you with these tasks, and Monokle is one of them!  

Now, let’s get down to basics…

What is a Kubernetes Manifest? 

A Kubernetes Manifest is a specification of a Kubernetes API object in JSON or YAML format. A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. A configuration file can contain multiple manifests. 

What is YAML? 

YAML stands for “YAML Ain't Markup Language” and is a human-readable text-based format that helps you specify information in your configurations. It’s vital for anyone working with containerized web applications and deploying them to Kubernetes. This is because YAML manifest files are what communicate with Kubernetes for a successful deployment. While YAML was initially meant to be an easy-to-read language, it’s also easy to make mistakes when creating manifests. From syntax issues to other errors, Manifests can be finicky. 

So, that begs the question, what’s the appeal? 

1. Structure: YAML utilizes indents to define structure, making it easy to read and understand 
2. Simplicity: YAML is simple and it’s syntax is straightforward and convenient to learn 
3. Flexibility: YAML allows for a wide range of data types and structures, which includes lists, maps and scalars. 
4. Readability: YAML is meant to be read and understood by humans, meaning it’s clear and concise  

Now that we understand the upsides to tackling the beastie that is YAML, let’s take a look at what basic YAML manifest structure looks like for Kubernetes deployment.

Below, is an example of basic manifest structure: 

Here are the following elements that we can see in the example above, and what they mean: 

apiVersion: Specifies the API version of Kubernetes 

kind: Specifies type of Kubernetes resource, in the example above the type is “deployment” 

metadata: This is where we find information about the deployment, likes names and labels 

spec: This is the desired state of your deployment, including things like the number replicas and the pod template. 

replicas: specifies the number of replicas to be made 

selector: how replicas are selected  

matchLabels: specifies which labels that each replica should match 

template: specifies which pod template for which replica 

containers: specifies which container to run in the pod 

name: the name of the container 

image: specifies which docker image 

ports: which ports to expose within the container

The apiVersion and kind of the manifest will specify which schema to use.

What is a Manifest Schema in regards to Kubernetes Manifests? 

A manifest schema defines the “content” of the manifest and is not to be confused with Kubernetes itself! 

The following is an example of what a manifest schema looks like

Manifest schemas are used to validate manifest files. When a manifest is validated, the schema is then used to check that the manifest file contains the required information and that it's formatted correctly.

Manifest schemas are also used to generate documentation for manifest files. When a manifest is documented, the manifest schema is used to generate a document that describes its structure and contents.  

The Relationships Between Kubernetes Manifests

Kubernetes manifest relationships are the way that Kubernetes objects are connected to each other. These relationships are used to define how Kubernetes objects interact with each other.

There are a number of different types of Kubernetes manifest relationships. Some of the most common types of relationships include:

• Ownership: An ownership relationship indicates that one Kubernetes object owns another Kubernetes object. The owner of an object is responsible for managing the object and ensuring that it is in a healthy state.
• References: A reference relationship indicates that one Kubernetes object references another Kubernetes object. The referenced object is used by the referencing object.
• DependsOn: A depends-on relationship indicates that one Kubernetes object depends on another Kubernetes object. The dependent object cannot be created or started until the depended-on object is created or started.
• VolumeMounts: A volume-mount relationship indicates that a Kubernetes object mounts a volume. The mounted volume provides data to the object.

Manifest relationships are defined using the Kubernetes API, which provides a number of different methods for creating, deleting and updating relationships. 

Kubernetes manifest relationships are ultimately used to manage the complexity of Kubernetes clusters. By defining how Kubernetes objects interact, manifest relationships ensure that clusters are stable and reliable.

Below are some examples of what these relationships look like in practice: 

• A Pod may have a VolumeMount relationship to a PersistentVolumeClaim. Meaning that the Pod will mount the PersistentVolumeClaim's volume at a specified path. 
• A deployment may have a DependsOn relationship to a Service. Meaning that the deployment will not start until the Service is running. 
• A Job may have an Owner relationship to a CronJob. Meaning that the Job is owned by the CronJob and will be automatically created and deleted by the CronJob.

Kubernetes manifest relationships are a powerful tool for managing Kubernetes clusters. Just like in real life, understanding how relationships work means you can create more complex and reliable applications in Kubernetes. 

You can also use Monokle to help manage your own complex clusters! Check out how to leverage Monokle in your Kubernetes lifecycle here

Now that we understand the foundations of our YAML and K8s Manifests, how they form relationships and how they relate to the world of Kubernetes, it’s time to apply our new knowledge! Below, you’ll find resources on how to leverage Monokle for editing and managing your YAML Manifests and Kubernetes clusters. And next time, we’ll go over everything you need to know to start utilizing YAML templates, and navigating through the Kubernetes lifecycle. 

See you then.

How to Validate YAML Using Monokle CLI 

Kubernetes Deployments Using Monokle and Kustomize