Kubernetes-Patterns

Was macht Kubernetes-Patterns?

Produktionsreife Kubernetes-Patterns zur zuverlässigen Bereitstellung, Verwaltung und Fehlerbehebung von Workloads.

Wann zu aktivieren

• Schreiben von Kubernetes-Manifesten (Deployments, Services, Ingress, Jobs)
• Konfigurieren von Ressourcenanforderungen/-limits, Liveness/Readiness-Probes
• Einrichten von RBAC, Namespaces oder ServiceAccounts
• Verwalten von Konfiguration und Secrets in K8s
• Debuggen von CrashLoopBackOff, OOMKilled, ausstehenden Pods oder Image-Pull-Fehlern
• Konfigurieren von HPA (Horizontal Pod Autoscaler) oder PodDisruptionBudgets
• Überprüfen von K8s-YAML auf Sicherheit oder Korrektheit

Wann zu verwenden

Entspricht Wann zu aktivieren oben. Dieser Alias erfüllt die Konventionen des Repository-Skill-Formats. Verwenden Sie dieses Skill jedes Mal, wenn Sie Kubernetes-YAML und Workloads schreiben, überprüfen oder debuggen.

Wie es funktioniert

Dieses Skill bietet kopierbare, produktionsreife YAML-Patterns und kubectl-Debugging-Befehle, organisiert nach Aufgaben:

1. Deployment-Vorlage — Ein vollständig konfiguriertes Produktions-Deployment mit Sicherheitskontext, Rolling-Update-Strategie, allen drei Probe-Typen, Ressourcenlimits und Umgebungsvariablen-Injektion aus ConfigMap/Secret.
2. Probes — Entscheidungstabelle für Startup vs. Liveness vs. Readiness mit korrekter failureThreshold × periodSeconds-Berechnung.
3. Services & Ingress — ClusterIP-, LoadBalancer- und TLS-Ingress-Patterns mit cert-manager-Annotationen.
4. ConfigMaps & Secrets — Leitfaden zu envFrom, Datei-Mount und externen Secrets.
5. Ressourcenmanagement — Faustregeln für Requests vs. Limits nach Workload-Typ (Web-API, JVM, Worker, Sidecar).
6. RBAC — Least-Privilege-ServiceAccount → Role → RoleBinding-Kette.
7. HPA & PDB — Konfigurationen für Autoscaling und Knoten-Drain-Sicherheit.
8. Jobs & CronJobs — Einmalige und geplante Workload-Patterns mit korrektem restartPolicy.
9. kubectl-Spickzettel — Befehle für Logs, Exec, Rollback, Port-Forward, Dry-Run und häufige Fehlerdiagnosen.
10. Anti-Patterns & Checkliste — Was man NICHT tun sollte und eine Checkliste für Sicherheit/Zuverlässigkeit/Beobachtbarkeit.

Beispiele

Siehe die folgenden Abschnitte für vollständige, ausführbare Beispiele. Kurzreferenzen:

Aufgabe	Springe zu
Vollständiges Produktions-Deployment-YAML	Kern-Workload-Patterns
Probe-Konfiguration	Probes
RBAC Least-Privilege-Setup	RBAC
Debuggen eines CrashLoopBackOff	kubectl-Debugging-Spickzettel
Autoscaling	HPA

---

Kern-Workload-Patterns

Deployment — Produktionsvorlage

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
  labels:
    app: my-app
    version: "1.0.0"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # Erlaube 1 zusätzlichen Pod während des Updates
      maxUnavailable: 0    # Nie unter die gewünschte Anzahl reduzieren
  template:
    metadata:
      labels:
        app: my-app
        version: "1.0.0"
    spec:
      # Sicherheitskontext auf Pod-Ebene
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
        fsGroup: 1001

      # Graceful Shutdown
      terminationGracePeriodSeconds: 30

      containers:
        - name: my-app
          image: ghcr.io/org/my-app:1.0.0   # Niemals :latest verwenden
          imagePullPolicy: IfNotPresent

          ports:
            - containerPort: 8080
              protocol: TCP

          # Ressourcenanforderungen UND Limits sind beide erforderlich
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

          # Container-Sicherheitskontext
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

          # Probes (siehe Abschnitt Probes unten)
          startupProbe:
            httpGet:
              path: /health
              port: 8080
            failureThreshold: 30
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 0
            periodSeconds: 30
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
            failureThreshold: 2

          # Umgebungsvariablen aus ConfigMap und Secret
          envFrom:
            - configMapRef:
                name: my-app-config
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: my-app-secrets
                  key: db-password

          # Beschreibbares tmp-Verzeichnis bei readOnlyRootFilesystem: true
          volumeMounts:
            - name: tmp
              mountPath: /tmp

      volumes:
        - name: tmp
          emptyDir: {}

---

Probes — Liveness, Readiness, Startup

Das Verständnis, wann welcher Probe verwendet wird, ist entscheidend:

Probe	Fehleraktion	Verwendung für
startupProbe	Tötet Container bei langsamem Start	Langsam startende Apps (JVM, Python)
livenessProbe	Startet Container neu	Erkennung von Deadlocks / hängenden Prozessen
readinessProbe	Entfernt aus Service-Endpunkten	Vorübergehende Nichtverfügbarkeit (DB-Reconnect)

# Korrektes Muster: startupProbe deckt langsamen Start ab,
# dann übernehmen liveness/readiness
startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30  # 30 * 5s = 150s maximale Startzeit
  periodSeconds: 5

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  periodSeconds: 30
  failureThreshold: 3   # 3 * 30s = 90s vor Neustart

readinessProbe:
  httpGet:
    path: /ready         # Separater Endpunkt: prüft DB, Cache, etc.
    port: 8080
  periodSeconds: 10
  failureThreshold: 2

# FALSCH: initialDelaySeconds ohne startupProbe
# Wenn die App 60s zum Starten benötigt, setzen Sie stattdessen eine startupProbe
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60   # SCHLECHT: Willkürliches Warten, Race-Condition

---

Services und Ingress

Service-Typen

# ClusterIP (Standard) — nur intern
apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: my-namespace
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: ClusterIP

# LoadBalancer — externer Traffic (Cloud-Anbieter)
spec:
  type: LoadBalancer
  ports:
    - port: 443
      targetPort: 8080

Ingress mit TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: my-namespace
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - myapp.example.com
      secretName: my-app-tls
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

---

ConfigMaps und Secrets

ConfigMap — Nicht-sensitive Konfiguration

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
  namespace: my-namespace
data:
  LOG_LEVEL: "info"
  APP_ENV: "production"
  MAX_CONNECTIONS: "100"
  # Als Datei für komplexe Konfiguration mounten
  app.yaml: |
    server:
      port: 8080
      timeout: 30s

# ConfigMap als Datei mounten
volumes:
  - name: config
    configMap:
      name: my-app-config
      items:
        - key: app.yaml
          path: app.yaml
volumeMounts:
  - name: config
    mountPath: /etc/app
    readOnly: true

Secrets — Sensitive Daten

# Secret aus Literal erstellen (CLI, dann in Vault/SOPS speichern)
kubectl create secret generic my-app-secrets \
  --from-literal=db-password='s3cr3t' \
  --namespace=my-namespace \
  --dry-run=client -o yaml | kubectl apply -f -

apiVersion: v1
kind: Secret
metadata:
  name: my-app-secrets
  namespace: my-namespace
type: Opaque
# Werte sind base64-kodiert (NICHT verschlüsselt — verwenden Sie Sealed Secrets oder ESO für echte Verschlüsselung)
data:
  db-password: czNjcjN0  # base64 von 's3cr3t'

Wichtig: Rohe Kubernetes-Secrets sind nur base64-kodiert, nicht im Ruhezustand verschlüsselt, es sei denn, Ihr Cluster hat Verschlüsselung konfiguriert. Verwenden Sie Sealed Secrets oder External Secrets Operator für die Produktion.

---

Ressourcenanforderungen und -limits

resources:
  requests:       # Scheduler verwendet dies, um den Pod zu platzieren
    cpu: "100m"   # 100 Millicores = 0,1 CPU
    memory: "128Mi"
  limits:         # Container wird darüber getötet/gedrosselt
    cpu: "500m"
    memory: "256Mi"

Faustregeln:

Workload-Typ	CPU-Request	Memory-Request	Hinweise
Web-API	100–250m	128–256Mi	Limits auf das 2-4-fache der Requests setzen
Worker/Consumer	250–500m	256–512Mi	Memory-Limit = Request für Vorhersagbarkeit
JVM-App	500m–1	512Mi–2Gi	Über -Xmx hinaus Spielraum für JVM-Overhead lassen
Sidecar	10–50m	32–64Mi	Minimal halten

# FALSCH: Keine Requests oder Limits — unvorhersehbare Planung, OOM-Vertreibungen
containers:
  - name: app
    image: myapp:latest
    # Fehlende resources: {} — das ist gefährlich in der Produktion

# FALSCH: Limits ohne Requests — Requests standardmäßig auf Limits, überreserviert Kapazität
resources:
  limits:
    cpu: "2"
    memory: "1Gi"
  # Requests fehlen — standardmäßig auf Limits gesetzt

---

RBAC — Rollen und ServiceAccounts

Prinzip der geringsten Privilegien

Zwei Muster, abhängig davon, ob die App die Kubernetes-API aufruft:

Muster A — App benötigt KEINE Kubernetes-API (die meisten Apps)

Deaktivieren Sie das automatische Token-Mounting auf dem ServiceAccount. Die Role/RoleBinding sind nicht erforderlich.

# ServiceAccount mit deaktiviertem Token — sicherste Standardeinstellung
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
automountServiceAccountToken: false   # Kein K8s-API-Token in Pods injiziert

# Referenz im Deployment — kein Token, kein API-Zugriff
spec:
  template:
    spec:
      serviceAccountName: my-app-sa
      automountServiceAccountToken: false   # Sicherheitsgurt: auch auf Pod-Ebene gesetzt

Muster B — App BENÖTIGT die Kubernetes-API (Operatoren, Controller, Config-Watcher)

Aktivieren Sie das Token und gewähren Sie nur die tatsächlich erforderlichen Berechtigungen.

# 1. ServiceAccount — Token für diesen SA aktivieren
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
automountServiceAccountToken: true    # Token erforderlich: App ruft K8s-API auf

# 2. Role — nur das gewähren, was die App benötigt (namespace-beschränkt)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-app-role
  namespace: my-namespace
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]    # Nur-Lesen, spezifische Ressource
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["my-app-secrets"]  # Auf bestimmtes Secret per Name beschränken
    verbs: ["get"]

# 3. Role an ServiceAccount binden
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-rolebinding
  namespace: my-namespace
subjects:
  - kind: ServiceAccount
    name: my-app-sa
    namespace: my-namespace
roleRef:
  kind: Role
  apiGroup: rbac.authorization.k8s.io
  name: my-app-role

# 4. SA im Deployment referenzieren
spec:
  template:
    spec:
      serviceAccountName: my-app-sa
      # automountServiceAccountToken standardmäßig true von SA — Token wird injiziert

---

Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2      # Mindestens 2 für Hochverfügbarkeit
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70    # Hochskalieren, wenn durchschnittliche CPU > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

HPA erfordert, dass resources.requests auf allen Containern gesetzt ist — es berechnet die Auslastung als current / request.

---

PodDisruptionBudget (PDB)

Verhindert, dass während Knoten-Drain oder Rolling-Updates zu viele Pods ausfallen:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-namespace
spec:
  minAvailable: 2           # ODER verwenden Sie maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

---

Namespaces und Multi-Tenancy

# Namespace mit Ressourcenkontingenten erstellen
kubectl create namespace my-namespace

# ResourceQuota anwenden, um Namespace-Verbrauch zu begrenzen
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-namespace-quota
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 4Gi
    limits.cpu: "8"
    limits.memory: 8Gi
    pods: "20"
EOF

---

Jobs und CronJobs

# Einmaliger Job (DB-Migration, Datenverarbeitung)
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  namespace: my-namespace
spec:
  backoffLimit: 3          # Bei Fehler bis zu 3 Mal wiederholen
  ttlSecondsAfterFinished: 3600   # Nach 1h automatisch löschen
  template:
    spec:
      restartPolicy: OnFailure    # Für Jobs (nicht Always)
      containers:
        - name: migrate
          image: ghcr.io/org/my-app:1.0.0
          command: ["python", "manage.py", "migrate"]
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

# CronJob — geplanter Job (z.B. tägliche Bereinigung)
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup
  namespace: my-namespace
spec:
  schedule: "0 2 * * *"    # Täglich um 2:00 Uhr UTC
  concurrencyPolicy: Forbid  # Keine parallelen Ausführungen
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: ghcr.io/org/cleanup:1.0.0
              command: ["cleanup", "--age", "7d"]
              resources:
                requests:
                  cpu: "50m"
                  memory: "64Mi"

Hinweis: Defnieren Sie für CronJobs immer concurrencyPolicy, um die gleichzeitige Ausführung zu steuern, und legen Sie successfulJobsHistoryLimit/failedJobsHistoryLimit fest, um zu verhindern, dass der Namespace durch überflüssige Job-Ressourcen überfüllt wird.

---

kubectl-Debugging-Spickzettel

Häufige Diagnosebefehle

# Pod-Status und Ereignisse anzeigen
kubectl get pods -n my-namespace
kubectl describe pod <pod-name> -n my-namespace

# Pod-Logs anzeigen (bei mehreren Containern -c <container>)
kubectl logs <pod-name> -n my-namespace
kubectl logs --tail=50 -f <pod-name> -n my-namespace   # Live-Streaming

# In einen laufenden Container ausführen
kubectl exec -it <pod-name> -n my-namespace -- /bin/sh

# Deployment-Zustand prüfen
kubectl rollout status deployment/my-app -n my-namespace
kubectl rollout history deployment/my-app -n my-namespace

# Auf vorherige Revision zurückrollen
kubectl rollout undo deployment/my-app -n my-namespace
# Oder auf eine bestimmte Revision zurückrollen
kubectl rollout undo deployment/my-app --to-revision=2 -n my-namespace

# Port-Forward für lokalen Debug-Zugriff
kubectl port-forward pod/<pod-name> 8080:8080 -n my-namespace

# YAML mit Server-Seiten-Dry-Run validieren (VOR dem Ausführen prüfen)
kubectl apply -f manifest.yaml --dry-run=client -o yaml
kubectl apply -f manifest.yaml --dry-run=server   # Server-seitige Validierung

Fehlerdiagnose

Problem	Erste Schritte
CrashLoopBackOff	kubectl logs <pod> → kubectl describe pod <pod> (Letzter Zustand)
ImagePullBackOff	kubectl describe pod <pod> (Ereignisse). Prüfen Sie Image-Name, Tag und pullSecret.
Pod Pending	kubectl describe pod <pod> — unzureichende Ressourcen, PVC-Pending, oder Node-Selektor passt nicht.
OOMKilled	Pod wird wegen Speichermangels getötet. Erhöhen Sie memory.limits oder beheben Sie Speicherleck.
Init:Error	kubectl logs <pod> -c <init-container> — Problem im Init-Container.
Service erreicht keinen Pod	kubectl get endpoints <service> — prüfen, ob Endpunkte vorhanden sind. selector muss zu labels passen.
CreateContainerConfigError	kubectl describe pod <pod> — fehlende ConfigMap oder Secret, auf die verwiesen wird.

Erstellen Sie ein Alias für schnelleres Debuggen: alias k='kubectl', alias kd='kubectl describe', alias kl='kubectl logs'.

---

Anti-Patterns und Checkliste

Häufige Anti-Patterns

# ANTI-PATTERN 1: :latest verwenden — nicht reproduzierbar
image: myapp:latest   # SCHLECHT: Verwenden Sie einen eindeutigen Tag wie 1.2.3 oder $GIT_SHA

# ANTI-PATTERN 2: imagePullPolicy: Always (außer wenn :latest)
imagePullPolicy: Always   # NUR mit :latest erforderlich; sonst IfNotPresent verwenden

# ANTI-PATTERN 3: Privilegierte Container ohne Notwendigkeit
securityContext:
  privileged: true   # SCHLECHT: Nur in Ausnahmefällen; drop ALL als Standard

# ANTI-PATTERN 4: Kein Ressourcenlimit für Worker/Sidecars
# Worker ohne Speicherlimit können den Node überlasten

# ANTI-PATTERN 5: Hardcodierte Secrets im YAML
env:
  - name: DB_PASSWORD
    value: "hunter2"   # SCHLECHT: Niemals Secrets in Manifeste hardcodieren

# ANTI-PATTERN 6: readinessProbe ohne separaten Endpunkt
livenessProbe: ...
readinessProbe:         # Identisch mit liveness —  keine zusätzliche Information
  $ref: '#/livenessProbe'

Produktions-Checkliste

• securityContext auf Pod- und Containerebene definiert?
• readOnlyRootFilesystem: true (mit emptyDir für /tmp)?
• Alle Container haben resources.requests UND resources.limits?
• startupProbe für langsam startende Workloads konfiguriert?
• readinessProbe prüft, ob die App tatsächlich bereit ist (DB-Verbindung, Cache-Warmup)?
• livenessProbe verwendet einen separaten, leichten Endpunkt (kein DB-Check)?
• Keine initialDelaySeconds verwendet, wenn startupProbe möglich ist?
• serviceAccountName im Deployment gesetzt?
• automountServiceAccountToken: false auf SA, es sei denn, die App benötigt die K8s-API?
• RBAC-Rollen gewähren nur die Mindestberechtigungen (kein "*" in verbs)?
• Secrets sind base64-kodiert (und vorzugsweise mit einem externen Secrets-Manager in der Produktion)?
• HPA verwendet CPU und Memory-Metriken?
• PodDisruptionBudget ist für StatefulSets und geschäftskritische Deployments definiert?
• Jobs/CronJobs haben eine ttlSecondsAfterFinished zur Bereinigung?
• CronJobs haben concurrencyPolicy und Begrenzungen für den Verlauf der History?

---

Ressourcen und Referenzen

• Kubernetes-Dokumentation
• Best Practices: Aufbau großer Cluster
• Kubernetes-Patterns (Buch)