Configuration

In order to create and manage resources in a Kubernetes cluster, you need to define the desired state of the cluster using configuration files. These configuration files specify the objects you want to create (e.g., pods, deployments, services) and their properties.

Kubernetes supports both a declarative model (desired state), which is specified in configuration files (YAML or JSON), and an imperative model (direct commands, e.g. using kubectl). The declarative model is the preferred way to manage the state of the cluster, as it allows for better automation and reproducibility, as well as keeping changing in a version control system, such as git.

Here is a simple example of a configuration (in YAMl) that specifies a pod running an Nginx container:

apiVersion: v1
kind: Pod # specifies the type of object
metadata: # metadata for the pod (name, labels, etc.)
  name: nginx # name of the pod
spec: # specification of the pod
    containers: 
    - name: nginx # name of the container
        image: nginx:latest # image to use for the container
        ports:
        - containerPort: 80 # port to expose

This configuration file can be applied to the cluster using the kubectl apply¹ command:

kubectl apply -f pod.yaml

The command above will create the pod in the cluster based on the configuration specified in the pod.yaml file.

Anatomy of a Configuration File

The kubernetes configuration file contains a set of key-value pairs that define the configuration of the object to be created or updated in the cluster.

apiVersion

• Specifies the API version of the Kubernetes object (e.g., v1, apps/v1).
• Determines the schema used to validate the object.
  • Example: apiVersion: apps/v1

kind

• Specifies the type of Kubernetes object being created.
  • Example: kind: Deployment, kind: Service, kind: Pod

metadata

• Contains metadata about the object, such as its name, namespace, and labels.
  • Key fields:
    • name: The unique name of the object (e.g., name: my-app).
    • namespace (optional): Specifies the namespace in which the object resides (e.g., namespace: default).
    • labels: Key-value pairs used for organizing and selecting resources (e.g., labels: app: my-app).
    • annotations: Key-value pairs for additional metadata, often used by tools or plugins.

spec

• Describes the desired state of the object. The contents of spec depend on the type of object (kind).
  • For Deployments:
    • replicas: Number of Pod replicas to create.
    • selector: Defines how to match Pods (e.g., based on labels).
    • template: Specifies the Pod definition (see below).
  • For Services:
    • type: Specifies the Service type (e.g., ClusterIP, NodePort, LoadBalancer).
    • selector: Labels to match Pods.
    • ports: Port mapping definitions.

template

• Defines the Pod template used to create Pods.
  • Key fields:
    • metadata: Metadata for the Pod, such as labels.
    • spec: Defines the Pod specification (e.g., containers, volumes).

containers

• Lists the container(s) to run in the Pod.
  • Key fields:
    • name: Name of the container.
    • image: The container image to use (e.g., nginx:1.21).
    • ports: Ports exposed by the container.
    • env: Environment variables passed to the container.
    • resources: Resource limits and requests (CPU/memory).

Configuration Management Tools

Helm Charts

Helm is a package manager for Kubernetes that simplifies the deployment and management of applications in a Kubernetes cluster. Helm uses a packaging format called “charts,” which are collections of files that describe a set of Kubernetes resources.

Kustomize

Kustomize is a tool built into kubectl that allows you to customize Kubernetes resources through a set of patches and overlays. It provides a way to manage and customize Kubernetes manifests without modifying the original files.