Cheat sheet

Kubernetes YAML

Copy-paste manifest skeletons for the objects you write most — with the fields people forget.

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels: { app: web }
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: registry.example.com/web:v1.2.3
          ports: [{ containerPort: 8080 }]
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { memory: 256Mi }
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true

Service

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector: { app: web }       # matches POD labels
  ports:
    - port: 80                  # service port
      targetPort: 8080          # container port
  type: ClusterIP               # NodePort | LoadBalancer

# Headless (for StatefulSets / direct pod DNS)
# clusterIP: None

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: nginx
  tls:
    - hosts: [app.example.com]
      secretName: web-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }

ConfigMap & Secret

apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
  LOG_LEVEL: "info"
  app.yaml: |
    feature_flags:
      new_ui: true
---
apiVersion: v1
kind: Secret
metadata: { name: app-secrets }
type: Opaque
stringData:                 # plain text; encoded on apply
  DATABASE_URL: postgres://...

# In the pod spec:
#   envFrom: [{ configMapRef: { name: app-config } }]
#   env:
#     - name: DATABASE_URL
#       valueFrom:
#         secretKeyRef: { name: app-secrets, key: DATABASE_URL }

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: gp3
  resources:
    requests: { storage: 20Gi }

# Mount in the pod spec:
#   volumes:
#     - name: data
#       persistentVolumeClaim: { claimName: data }
#   containers[].volumeMounts:
#     - { name: data, mountPath: /var/lib/data }

HorizontalPodAutoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report
spec:
  schedule: "0 2 * * *"        # 02:00 daily
  timeZone: "Asia/Kolkata"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 1800
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: report
              image: registry.example.com/report:v3

NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-web-only
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }
      ports: [{ protocol: TCP, port: 8080 }]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: db }
      ports: [{ protocol: TCP, port: 5432 }]
# Empty podSelector {} = every pod in the namespace

Related resources

Commands to drive these objects live in the kubectl cheat sheet. Validate manifests with the Kubernetes YAML Linter, and generate policies with the NetworkPolicy Generator and RBAC Generator.

New to these objects? Start with the Kubernetes core concepts tutorial.

About the Kubernetes YAML Cheat Sheet

Kubernetes manifests are verbose, and most of the verbosity is boilerplate you copy rather than think about. The parts worth understanding are the few fields that change behaviour meaningfully: selectors and labels, resource requests and limits, probes, and the security context.

Selectors are where manifests most often go quietly wrong. A Service finds pods by label, not by name or by Deployment — a mismatch produces a Service with no endpoints and no error anywhere. A Deployment's selector is immutable after creation, so getting it wrong means recreating the Deployment.

Requests and limits are the other high-consequence field. Requests drive scheduling and are what the autoscaler reasons about; limits cause throttling for CPU and termination for memory. Setting a memory limit far above the request is how pods get OOM-killed on a node that looked like it had room.

Frequently asked questions

My Service has no endpoints. What is wrong?

The Service's selector does not match any running pod's labels, or the matching pods are not ready. Compare the Service selector against the pod labels rather than the Deployment's, since the pod template is what produces them. If labels match, check readiness probes — a pod that is not ready is deliberately excluded from endpoints.

What is the difference between requests and limits?

Requests are what the scheduler reserves and what determines which node a pod lands on. Limits are the ceiling enforced at runtime. Exceeding a CPU limit throttles the process; exceeding a memory limit terminates it. Setting requests too low leads to nodes that look free and are not, which is the usual cause of mysterious evictions.

When should I use a liveness probe versus a readiness probe?

Readiness controls traffic — a failing readiness probe removes the pod from Service endpoints without restarting it. Liveness controls restarts — a failing liveness probe kills the container. An aggressive liveness probe on a slow-starting application creates a restart loop, which is why startup probes exist to cover initialisation separately.

Why did my Deployment update not roll out?

Only changes to the pod template trigger a rollout. Editing a ConfigMap or Secret the pods mount changes nothing about the template, so nothing restarts and the old configuration stays live. Either roll out the Deployment explicitly, or include a hash of the configuration in a pod annotation so a change alters the template.

What belongs in a ConfigMap versus a Secret?

Non-sensitive configuration in a ConfigMap, sensitive values in a Secret. Be aware that Secrets are base64-encoded rather than encrypted by default, so enable encryption at rest and restrict RBAC accordingly. Anyone who can create a pod in a namespace can usually read that namespace's secrets, which is worth remembering when deciding what to store there.