YAML Manifest

We have now learned how users communicate with a Kubernetes cluster through the kubectl command-line tool. We also saw that kubectl supports both declarative and imperative approaches, with the declarative approach being the preferred method for managing Kubernetes resources.

In the declarative approach, we define the desired state of our resources using configuration files. These configuration files are written in YAML format. Let's understand why YAML is important and how to write Kubernetes YAML manifests.

What is YAML?

YAML stands for "YAML Ain't Markup Language." It is a human-readable data serialization format that uses indentation and simple syntax to represent data structures.

YAML is widely used in configuration files across many technologies and tools. It is simple, readable, and easy to understand, making it an ideal format for defining Kubernetes resources.

Why YAML in Kubernetes?

YAML is the standard format for defining Kubernetes resources because:

1. Human-Readable: YAML files are easy to read and understand, making them suitable for version control systems like Git.
2. Infrastructure as Code (IaC): YAML manifests allow you to define your entire infrastructure as code, which can be versioned, reviewed, and deployed consistently.
3. Reproducibility: By maintaining YAML manifests, you can reproduce the same cluster state across different environments (dev, staging, production).
4. Declarative Approach: YAML manifests define the desired state, and Kubernetes automatically adjusts the current state to match the desired state.
5. Automation: YAML manifests can be easily integrated into CI/CD pipelines for automated deployments.

Advantages of YAML Manifests Over Imperative Commands

While imperative commands like kubectl create deployment my-deployment --image=nginx are quick for testing, they have several limitations:

YAML Manifests Advantages:

Aspect	YAML Manifests	Imperative Commands
Version Control	Can be tracked in Git, showing history of changes	No built-in version history
Documentation	Comments in YAML files serve as documentation	No easy way to document intent
Repeatability	Same manifest produces same result every time	Easy to make inconsistent changes
Code Review	Changes can be reviewed before deployment	Difficult to review or audit
Environment Differences	Easy to maintain different configs for dev/staging/prod	Prone to manual errors across environments
Disaster Recovery	Quick restoration from stored manifests	Requires remembering all commands
Collaboration	Teams can work together on manifests	Difficult to coordinate changes
CI/CD Integration	Easily integrated into automated pipelines	Requires manual intervention

Anatomy of a Kubernetes YAML Manifest

A Kubernetes YAML manifest typically contains the following structure:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-container
    image: nginx:latest
    ports:
    - containerPort: 80

Let's break down each section:

1. apiVersion

The API version of the Kubernetes resource. Different resource types have different API versions.

• Examples: v1, apps/v1, batch/v1

2. kind

The type of Kubernetes resource being created.

• Examples: Pod, Deployment, Service, ConfigMap

3. metadata

Contains metadata about the resource, such as:

• name: The name of the resource
• namespace: The namespace where the resource is created (defaults to default)
• labels: Key-value pairs for organizing and selecting resources

metadata:
  name: my-pod
  namespace: default
  labels:
    app: my-app
    tier: frontend

4. spec

Describes the desired state of the resource. The content varies based on the kind.

• For a Pod, the spec includes container definitions, volumes, and restart policies.
• For a Deployment, the spec includes replicas, selector, and pod template.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

Best Practices

1. Use Meaningful Names: Use clear, descriptive names for resources.
2. Use Labels and Annotations: Label resources for organization and selection.
3. Separate Concerns: Use different manifests for different components.
4. Use Namespaces: Organize resources using namespaces.
5. Version Control: Always store manifests in a version control system.
6. Comments: Add comments to explain complex configurations.

Next Steps

Now that we understand YAML manifests and their importance, we can start defining our Kubernetes resources using YAML. But before that, we need to have a Kubernetes environment to learn all these concepts. Let's see the available options to have our own cluster.