Overview

Understanding and writing Kubernetes manifest files.

Basic Structure

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

Common Resource Types

Deployment

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: myapp:1.0.0
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Service

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.url: "postgres://db:5432"
  log.level: "info"

Secret

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=  # base64 encoded

Best Practices

Resource Requests and Limits

Always define resource requests and limits:

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Liveness and Readiness Probes

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Labels and Selectors

Use consistent labeling:

metadata:
  labels:
    app: my-app
    version: v1
    environment: production

Validation

# Validate manifest syntax
kubectl apply --dry-run=client -f manifest.yaml

# Validate with kubeconform
kubeconform manifest.yaml

# Validate against live cluster
kubectl apply --dry-run=server -f manifest.yaml