Skip to main content

Kubernetes YML Breakdown

· 6 min read
Femi Adigun
Femi Adigun
Senior Software Engineer & Coach

Here is a universal structure that applies to ALL Kubernetes YAML files, plus memory tricks to never forget it!

The Universal Kubernetes YAML Structure​

Every Kubernetes resource follows this 4-part structure:

apiVersion: <api-group>/<version>
kind: <ResourceType>
metadata:
  name: <resource-name>
  namespace: <namespace>
  labels:
    key: value
  annotations:
    key: value
spec:
  # Resource-specific configuration goes here

Memory Trick: "AKM-S"​

Api version Kind Metadata Spec

Or remember: "A Kind Metadata Spec" - like you're specifying a kind of metadata!

The 4 Core Fields Explained​

1. apiVersion - Which API to use​

Format: <api-group>/<version> or just <version>

Common values:

apiVersion: v1                           # Core resources
apiVersion: apps/v1                      # Deployments, StatefulSets
apiVersion: batch/v1                     # Jobs
apiVersion: networking.k8s.io/v1         # Ingress
apiVersion: autoscaling/v2              # HPA
apiVersion: rbac.authorization.k8s.io/v1 # RBAC

2. kind - Type of resource​

kind: Pod
kind: Deployment
kind: Service
kind: ConfigMap
kind: Secret
# ... etc

3. metadata - Identifying information​

Always has:

  • name (required)
  • namespace (optional, defaults to "default")
  • labels (optional but recommended)
  • annotations (optional)
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
    version: v1
    env: prod
  annotations:
    description: "My application"

4. spec - Desired state (varies by resource)​

This is where the resource-specific configuration goes. Changes based on kind.

Common Kubernetes Resources Cheat Sheet​

Pod (Basic building block)​

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

Spec structure for Pod:

  • containers[] - List of containers
    • name, image, ports[], env[], resources, volumeMounts[]
  • volumes[] - Storage volumes
  • restartPolicy - Always/OnFailure/Never

Deployment (Manages Pods)​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.19
          ports:
            - containerPort: 80

Spec structure for Deployment:

  • replicas - Number of pods
  • selector - How to find pods to manage
  • template - Pod template (has its own metadata + spec)

Service (Networking)​

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP # ClusterIP, NodePort, LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80 # Service port
      targetPort: 80 # Container port

Spec structure for Service:

  • type - ClusterIP/NodePort/LoadBalancer
  • selector - Which pods to send traffic to
  • ports[] - Port mappings

ConfigMap (Configuration data)​

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgres://db:5432"
  log_level: "info"

Spec structure for ConfigMap:

  • Uses data instead of spec
  • Key-value pairs

Secret (Sensitive data)​

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  username: YWRtaW4= # base64 encoded
  password: cGFzc3dvcmQ=

Spec structure for Secret:

  • Uses data or stringData instead of spec
  • Values must be base64 encoded in data

Interview Strategy: The Template Method​

Step 1: Start with the skeleton (10 seconds)

apiVersion:
kind:
metadata:
  name:
spec:

Step 2: Fill in the basics (20 seconds)

apiVersion: apps/v1 # Know common ones
kind: Deployment # What they asked for
metadata:
  name: my-app # Descriptive name
spec:
  # Now focus here

Step 3: Add spec details (30 seconds)

For each resource type, remember the key spec fields:

ResourceKey Spec Fields
Podcontainers[]
Deploymentreplicas, selector, template
Servicetype, selector, ports[]
ConfigMapdata (not spec!)
Secretdata or stringData (not spec!)
Ingressrules[]
PersistentVolumeClaimaccessModes, resources

Most Common Interview Questions​

Q: "Write a Deployment with 3 replicas"​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:latest

Key points:

  • selector.matchLabels MUST match template.metadata.labels
  • Template is a Pod spec inside Deployment spec

Q: "Expose this Deployment as a Service"​

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app # Match the Deployment's pod labels
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Q: "Create a ConfigMap and mount it in a Pod"​

ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.yaml: |
    database:
      host: localhost
      port: 5432

Pod using ConfigMap:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: myapp
      volumeMounts:
        - name: config
          mountPath: /etc/config
  volumes:
    - name: config
      configMap:
        name: app-config

Quick Reference Card (Memorize This!)​

┌─────────────────────────────────────────┐
│  KUBERNETES YAML STRUCTURE              │
├─────────────────────────────────────────┤
│  apiVersion: <group>/<version>          │
│  kind: <ResourceType>                   │
│  metadata:                              │
│    name: <name>                         │
│    namespace: <namespace>               │
│    labels:                              │
│      <key>: <value>                     │
│  spec:                                  │
│    <resource-specific-fields>           │
└─────────────────────────────────────────┘

COMMON apiVersion VALUES:
• v1                    → Pod, Service, ConfigMap, Secret
• apps/v1              → Deployment, StatefulSet, DaemonSet
• batch/v1             → Job, CronJob
• networking.k8s.io/v1 → Ingress

DEPLOYMENT PATTERN:
spec:
  replicas: <number>
  selector:
    matchLabels:
      app: <app-name>
  template:
    metadata:
      labels:
        app: <app-name>  ← Must match selector!
    spec:
      containers:
      - name: <container-name>
        image: <image>

🎓 Interview Tips​

1. Always start with AKM-S structure​

Write the skeleton first, then fill in details.

2. Know these by heart:​

  • Pod spec: containers[]
  • Deployment spec: replicas, selector, template
  • Service spec: selector, ports[], type

3. Remember the "selector-label" rule​

Service selector must match Pod labels Deployment selector.matchLabels must match template.metadata.labels

4. Container essentials:​

containers:
  - name: <name>
    image: <image>
    ports:
      - containerPort: <port>

5. If you forget, explain your thinking​

"I know the structure is apiVersion, kind, metadata, and spec. For a Deployment, I need replicas, a selector to match pods, and a template that defines the pod specification..."

6. Common mistakes to avoid:​

  • ❌ Forgetting selector.matchLabels in Deployment
  • ❌ Mismatching labels between selector and pod
  • ❌ Wrong apiVersion (use apps/v1 for Deployments)
  • ❌ Using spec in ConfigMap/Secret (it's data)

🚀 Practice Exercise​

Try writing these from memory:

  1. A Deployment with 2 replicas running nginx:1.19
  2. A Service exposing the above deployment on port 80
  3. A ConfigMap with database connection string
  4. A Pod that uses the ConfigMap as environment variables

📚 Bonus: Multi-Resource YAML​

You can combine multiple resources in one file with ---:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - port: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
data:
  env: production

Final Memory Aid​

Before the interview, write this on your paper:

A-K-M-S
v1, apps/v1, batch/v1
Pod: containers
Deploy: replicas, selector, template
Service: selector, ports, type

With this structure in mind, you can write any Kubernetes YAML!