Understanding YAML in Kubernetes

📄 Understanding YAML in Kubernetes. Visit Kubernetes Home Page – Explore More Topics

YAML (YAML Ain't Markup Language) is a human-readable data serialization format that is widely used for configuration files. In Kubernetes, YAML is the standard format to define resources such as Pods, Deployments, and Services.

With YAML, you describe the desired state of your cluster. Kubernetes reads these YAML files to create, update, or delete resources accordingly.

graph TD A[Kubernetes YAML File] B[apiVersion] C[kind] D[metadata] E[spec] A --> B A --> C A --> D A --> E D --> F[name] D --> G[labels] E --> H[Containers/Configuration] H --> I[name] H --> J[image] H --> K[ports]

The diagram above shows a typical structure of a Kubernetes YAML file. At the top level, you define the apiVersion, kind, metadata (including the resource's name and labels), and the spec, which outlines the detailed configuration.

Example: Pod Definition


apiVersion: v1                   # Specifies the API version for the Pod
kind: Pod                        # Defines the resource as a Pod
metadata:
  name: nginx-pod                # Name of the Pod
  labels:
    app: nginx                   # Label used for selection
spec:
  containers:
  - name: nginx-container        # Name of the container within the Pod
    image: nginx:1.19            # Container image to run
    ports:
    - containerPort: 80          # Port exposed by the container

graph TD A[Pod YAML] A --> B[apiVersion: v1] A --> C[kind: Pod] A --> D[metadata] D --> E[name: nginx-pod] D --> F[labels: app=nginx] A --> G[spec] G --> H[containers] H --> I[name: nginx-container] I --> J[image: nginx:1.19] I --> K[ports] K --> L[containerPort: 80]

This example defines a simple Pod running an Nginx container. Inline comments are provided to explain the purpose of each configuration line.

Example: Deployment Definition


apiVersion: apps/v1                # API version for Deployments
kind: Deployment                 # Defines the resource as a Deployment
metadata:
  name: nginx-deployment         # Name of the Deployment
  labels:
    app: nginx                   # Label to identify the application
spec:
  replicas: 3                    # Number of Pod replicas to run
  selector:
    matchLabels:
      app: nginx                 # Selector to match Pods with this label
  template:
    metadata:
      labels:
        app: nginx               # Labels for Pods created by this Deployment
    spec:
      containers:
      - name: nginx              # Container name within the Pod
        image: nginx:1.19        # Container image to deploy
        ports:
        - containerPort: 80      # Port exposed by the container

graph TD A[Deployment YAML] A --> B[apiVersion: apps/v1] A --> C[kind: Deployment] A --> D[metadata] D --> E[name: nginx-deployment] D --> F[labels: app=nginx] A --> G[spec] G --> H[replicas: 3] G --> I[selector] I --> J[matchLabels: app=nginx] G --> K[template] K --> L[metadata] L --> M[labels: app=nginx] K --> N[spec] N --> O[containers] O --> P[name: nginx] P --> Q[image: nginx:1.19] P --> R[ports] R --> S[containerPort: 80]

The Deployment example creates multiple replicas of a Pod running Nginx. Each field is explained using inline comments.

Example: Service (LoadBalancer)


apiVersion: v1                   # API version for Service
kind: Service                    # Defines the resource as a Service
metadata:
  name: nginx-service            # Name of the Service
spec:
  selector:
    app: nginx                   # Selects Pods with the label 'app: nginx'
  ports:
  - protocol: TCP                # Protocol used by the Service
    port: 80                   # Port that the Service exposes
    targetPort: 80             # Port on the Pod that the Service routes to
  type: LoadBalancer             # Service type for external access

graph TD A[Service YAML] A --> B[apiVersion: v1] A --> C[kind: Service] A --> D[metadata] D --> E[name: nginx-service] A --> F[spec] F --> G[selector: app=nginx] F --> H[ports] H --> I[protocol: TCP] H --> J[port: 80] H --> K[targetPort: 80] F --> L[type: LoadBalancer]

This Service example exposes Nginx Pods to external traffic by creating a LoadBalancer. Inline comments help explain each configuration option.

Example: ConfigMap


apiVersion: v1                   # API version for ConfigMap
kind: ConfigMap                  # Defines the resource as a ConfigMap
metadata:
  name: app-config               # Name of the ConfigMap
data:
  LOG_LEVEL: "debug"             # Log level setting for the application
  CACHE_SIZE: "256MB"            # Cache size configuration

graph TD A[ConfigMap YAML] A --> B[apiVersion: v1] A --> C[kind: ConfigMap] A --> D[metadata] D --> E[name: app-config] A --> F[data] F --> G[LOG_LEVEL: debug] F --> H[CACHE_SIZE: 256MB]

The ConfigMap example decouples configuration from code by defining non-sensitive configuration data. Each line includes inline comments for clarity.

Additional YAML Examples

Example: Secret


apiVersion: v1                   # Specifies the API version
kind: Secret                    # Defines this resource as a Secret
metadata:
  name: db-secret               # Name of the secret resource
type: Opaque                    # Type of secret (Opaque indicates a generic secret)
data:
  username: YWRtaW4=            # Base64 encoded username (e.g., 'admin')
  password: c2VjcmV0            # Base64 encoded password (e.g., 'secret')

graph TD A[Secret YAML] A --> B[apiVersion: v1] A --> C[kind: Secret] A --> D[metadata] D --> E[name: db-secret] A --> F[type: Opaque] A --> G[data] G --> H[username] G --> I[password]

This Secret example stores sensitive data using Base64 encoding. Inline comments are provided to explain the purpose of each line.

Example: Ingress


apiVersion: networking.k8s.io/v1  # API version for Ingress resources
kind: Ingress                   # Defines the resource as an Ingress
metadata:
  name: web-ingress             # Name of the Ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /  # Rewrite target for URL paths
spec:
  rules:
  - host: example.com           # Domain name for accessing the service
    http:
      paths:
      - path: /               # URL path to match
        pathType: Prefix      # Matching strategy for the path
        backend:
          service:
            name: web-service # Service to route traffic to
            port:
              number: 80      # Port on the service to use

graph TD A[Ingress YAML] A --> B[apiVersion: networking.k8s.io/v1] A --> C[kind: Ingress] A --> D[metadata] D --> E[name: web-ingress] D --> F[annotations] F --> G[rewrite-target: /] A --> H[spec] H --> I[rules] I --> J[host: example.com] J --> K[http] K --> L[paths] L --> M[path: /] M --> N[pathType: Prefix] M --> O[backend] O --> P[service name: web-service] P --> Q[port: 80]

The Ingress example configures external access by routing traffic from example.com to a backend service. Inline comments clarify each configuration option.

📢 Stay Informed!

Mastering YAML is essential for managing Kubernetes configurations effectively. With a clear understanding of the structure, syntax, and best practices, you can create powerful, maintainable configuration files that drive your cluster's behavior.