Kubernetes YML Breakdown
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 containersname,image,ports[],env[],resources,volumeMounts[]
volumes[]- Storage volumesrestartPolicy- 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 podsselector- How to find pods to managetemplate- 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/LoadBalancerselector- Which pods to send traffic toports[]- 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
datainstead ofspec - 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
dataorstringDatainstead ofspec - 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:
| Resource | Key Spec Fields |
|---|---|
| Pod | containers[] |
| Deployment | replicas, selector, template |
| Service | type, selector, ports[] |
| ConfigMap | data (not spec!) |
| Secret | data or stringData (not spec!) |
| Ingress | rules[] |
| PersistentVolumeClaim | accessModes, 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.matchLabelsMUST matchtemplate.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.matchLabelsin Deployment - ❌ Mismatching labels between selector and pod
- ❌ Wrong
apiVersion(useapps/v1for Deployments) - ❌ Using
specin ConfigMap/Secret (it'sdata)
🚀 Practice Exercise
Try writing these from memory:
- A Deployment with 2 replicas running nginx:1.19
- A Service exposing the above deployment on port 80
- A ConfigMap with database connection string
- 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!