Kubernetes mit Claude Code 2026
Kubernetes ist der Standard für Container-Orchestrierung in Production — skalierbar, selbstheilend, deklarativ. Claude Code generiert vollständige K8s-Manifeste: Deployments, Services, Ingress, Health Checks und Helm Charts für produktionsreife Cluster-Deployments.
Inhaltsverzeichnis
- Kubernetes Grundkonzepte — Pod, Deployment, Service, Ingress, Namespace
- kubectl und Manifeste — YAML schreiben, apply, rollout status
- ConfigMaps und Secrets — Env, Volume Mounts, Sealed Secrets
- Health Checks — livenessProbe, readinessProbe, startupProbe, Ressourcen
- Helm Charts — Chart-Struktur, values.yaml, Template-Syntax, install/upgrade
- Claude Code für K8s — Manifest-Generierung, Debugging-Workflows
1. Kubernetes Grundkonzepte
Kubernetes (K8s) ist ein Open-Source-System zur automatisierten Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen. Wer die Kernkonzepte beherrscht, kann mit Claude Code innerhalb von Minuten produktionsreife Infrastruktur beschreiben.
⬡ Pod
Kleinste deploybare Einheit in K8s. Enthält einen oder mehrere Container, die sich Netzwerk und Storage teilen. Pods sind ephemer — stirbt ein Pod, ersetzt K8s ihn automatisch.
⬡ Deployment
Deklarativer Controller für Pods und ReplicaSets. Definiert gewünschten Zustand (Replicas, Image, Update-Strategie). K8s konvergiert kontinuierlich zum Soll-Zustand.
⬡ Service
Stabiler Netzwerk-Endpunkt für eine Gruppe von Pods. Typen: ClusterIP (intern), NodePort (extern via Node), LoadBalancer (Cloud-LB), ExternalName (DNS-Alias).
⬡ Ingress
HTTP/HTTPS-Router, der externen Traffic zu internen Services leitet. Unterstützt TLS-Terminierung, Path- und Host-basiertes Routing, Rate Limiting.
⬡ Namespace
Virtuelles Cluster-Partitioning. Trennt Ressourcen nach Team, Umgebung (dev/staging/prod) oder Mandant. Basis für RBAC und Resource Quotas.
⬡ ReplicaSet
Garantiert dass eine bestimmte Anzahl identischer Pods läuft. Wird meist indirekt über ein Deployment verwaltet — direktes Erstellen von ReplicaSets ist selten nötig.
Architektur Control Plane & Worker Nodes
Der K8s-Cluster besteht aus dem Control Plane (API-Server, etcd, Scheduler, Controller Manager) und Worker Nodes (kubelet, kube-proxy, Container Runtime). Claude Code kennt diese Architektur und generiert Manifeste, die optimal mit der jeweiligen Schicht interagieren.
💡 Claude Code Prompt-Tipp: Beschreibe deine Anwendung auf hohem Level — "Eine Node.js API mit Redis Cache, 3 Replicas, persistent Storage für Uploads" — und Claude Code generiert alle notwendigen K8s-Ressourcen als vollständige YAML-Manifeste.
Namespaces Umgebungen sauber trennen
# Namespace für jede Umgebung anlegen
$ kubectl create namespace production
$ kubectl create namespace staging
$ kubectl create namespace development
# Alle Ressourcen im Namespace auflisten
$ kubectl get all -n production
# Standard-Namespace setzen (nicht immer -n schreiben)
$ kubectl config set-context --current --namespace=production
2. kubectl und Manifeste
kubectl ist das Schweizer Taschenmesser für K8s-Administration. Zusammen mit YAML-Manifesten lässt sich Infrastructure-as-Code vollständig deklarativ beschreiben. Claude Code generiert produktionsreife Manifeste auf Abruf — inklusive Best Practices für Update-Strategien und Resource-Management.
Deployment Vollständiges Deployment-Manifest
# deployment.yaml — generiert von Claude Code
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
namespace: production
labels:
app: webapp
version: "2.1.0"
spec:
replicas: 3
selector:
matchLabels:
app: webapp
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: webapp
version: "2.1.0"
spec:
containers:
- name: webapp
image: myregistry.io/webapp:2.1.0
ports:
- containerPort: 3000
protocol: TCP
env:
- name: NODE_ENV
value: "production"
- name: PORT
value: "3000"
Service ClusterIP Service für interne Kommunikation
# service.yaml — Service für das Deployment
apiVersion: v1
kind: Service
metadata:
name: webapp-service
namespace: production
labels:
app: webapp
spec:
type: ClusterIP
selector:
app: webapp
ports:
- name: http
port: 80
targetPort: 3000
protocol: TCP
Ingress HTTPS Ingress mit TLS-Terminierung
# ingress.yaml — TLS-Ingress mit nginx-ingress-controller
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: webapp-ingress
namespace: production
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/ssl-redirect: "true"
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
ingressClassName: nginx
tls:
- hosts:
- app.mycompany.com
secretName: webapp-tls
rules:
- host: app.mycompany.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp-service
port:
number: 80
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 8080
kubectl Wichtige Befehle im Arbeitsalltag
# Manifest anwenden (idempotent)
$ kubectl apply -f deployment.yaml
deployment.apps/webapp created
# Mehrere Manifeste auf einmal anwenden
$ kubectl apply -f ./k8s/
# Rollout-Status beobachten
$ kubectl rollout status deployment/webapp -n production
Waiting for deployment "webapp" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "webapp" successfully rolled out
# Rollback bei Problemen
$ kubectl rollout undo deployment/webapp -n production
# Deployment skalieren
$ kubectl scale deployment webapp --replicas=5 -n production
# Pod-Logs einsehen
$ kubectl logs -f deployment/webapp -n production --tail=100
# In laufenden Container einloggen
$ kubectl exec -it <pod-name> -n production -- /bin/sh
# Ressourcen-Verbrauch anzeigen
$ kubectl top pods -n production
💡 Profi-Tipp: Mit
kubectl diff -f deployment.yaml siehst du vor dem Apply, was sich im Cluster ändern würde — wie ein Dry-Run mit echtem Diff. Claude Code schlägt diesen Befehl automatisch vor, bevor es Änderungen an bestehenden Deployments anwendet.
3. ConfigMaps und Secrets
Konfiguration gehört nicht ins Container-Image — sie gehört in ConfigMaps und Secrets. ConfigMaps speichern nicht-sensible Konfiguration, Secrets verschlüsselt sensible Daten wie Passwörter und API-Keys. Claude Code generiert beide Ressourcentypen und zeigt, wie man sie korrekt in Pods einbindet.
ConfigMap Anwendungskonfiguration extern halten
# configmap.yaml — App-Konfiguration
apiVersion: v1
kind: ConfigMap
metadata:
name: webapp-config
namespace: production
data:
# Einfache Key-Value Paare
LOG_LEVEL: "info"
MAX_CONNECTIONS: "100"
CACHE_TTL: "3600"
API_ENDPOINT: "https://api.mycompany.com"
# Multi-line Konfigurationsdateien
app.properties: |
server.port=3000
spring.datasource.url=jdbc:postgresql://db:5432/mydb
spring.cache.type=redis
nginx.conf: |
server {
listen 80;
location / {
proxy_pass http://localhost:3000;
}
}
Secret Sensible Daten sicher verwalten
# secret.yaml — Base64-kodierte Secrets
apiVersion: v1
kind: Secret
metadata:
name: webapp-secrets
namespace: production
type: Opaque
data:
# echo -n "mypassword" | base64
DB_PASSWORD: bXlwYXNzd29yZA==
JWT_SECRET: c3VwZXJzZWNyZXRrZXkyMDI2
API_KEY: YXBpa2V5LWhlcmUtMTIzNDU2
---
# Secret direkt mit kubectl erstellen (kein YAML erforderlich)
$ kubectl create secret generic webapp-secrets \
--from-literal=DB_PASSWORD=mypassword \
--from-literal=JWT_SECRET=supersecretkey2026 \
--from-literal=API_KEY=apikey-here-123456 \
-n production
Einbindung ConfigMap und Secret in Pods verwenden
# deployment.yaml — ConfigMap + Secret einbinden
spec:
containers:
- name: webapp
image: myregistry.io/webapp:2.1.0
# Einzelne Werte als Env-Variablen
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: webapp-secrets
key: DB_PASSWORD
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: webapp-config
key: LOG_LEVEL
# Alle ConfigMap-Keys als Env-Variablen (envFrom)
envFrom:
- configMapRef:
name: webapp-config
- secretRef:
name: webapp-secrets
# ConfigMap als Datei mounten
volumeMounts:
- name: config-volume
mountPath: /etc/config
- name: nginx-config
mountPath: /etc/nginx/conf.d
volumes:
- name: config-volume
configMap:
name: webapp-config
- name: nginx-config
configMap:
name: webapp-config
items:
- key: nginx.conf
path: default.conf
Sealed Secrets Secrets sicher in Git speichern
# Sealed Secrets Controller installieren
$ helm install sealed-secrets \
sealed-secrets/sealed-secrets \
-n kube-system
# kubeseal installieren (CLI)
$ brew install kubeseal
# Normales Secret verschlüsseln → SealedSecret
$ kubectl create secret generic webapp-secrets \
--from-literal=DB_PASSWORD=mypassword \
--dry-run=client -o yaml | \
kubeseal --format yaml > sealed-secret.yaml
# sealed-secret.yaml kann sicher in Git committed werden!
# Der Controller entschlüsselt es automatisch im Cluster
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: webapp-secrets
namespace: production
spec:
encryptedData:
DB_PASSWORD: AgBvK2x7Nqm4...<langer verschlüsselter Wert>
⚠️ Sicherheitshinweis: Niemals unverschlüsselte Secrets in Git committen! Nutze Sealed Secrets oder externe Secret-Manager wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault. Claude Code weist automatisch auf dieses Antipattern hin und schlägt die passende Alternative vor.
4. Health Checks und Ressourcen
Kubernetes braucht Informationen darüber, ob ein Container gesund ist und Traffic empfangen kann. Die drei Probe-Typen livenessProbe, readinessProbe und startupProbe geben K8s diese Informationen. Kombiniert mit Resource Limits sorgen sie für stabile, produktionsreife Deployments.
🔴 livenessProbe
Prüft ob der Container noch lebt. Schlägt sie fehl, wird der Container neu gestartet. Für Deadlock-Erkennung gedacht — nie zu aggressiv konfigurieren.
🟢 readinessProbe
Prüft ob der Container bereit ist, Traffic zu empfangen. Schlägt sie fehl, wird der Pod aus dem Service-Loadbalancer entfernt, aber NICHT neu gestartet.
🟡 startupProbe
Gibt langsam startenden Containern Zeit zum Hochfahren. Solange sie fehlschlägt, werden liveness/readiness deaktiviert. Ideal für Legacy-Anwendungen.
📊 Resources
requests: Minimum-Garantie (für Scheduling). limits: Maximum (Container wird beendet wenn überschritten). Immer beides setzen für stabile Cluster.
Health Checks Vollständige Probe-Konfiguration
# deployment.yaml — alle drei Probe-Typen + Resources
spec:
containers:
- name: webapp
image: myregistry.io/webapp:2.1.0
ports:
- containerPort: 3000
# Ressourcen-Anforderungen und Limits
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
# Startup: langsam startende Apps — bis 5 Minuten Zeit
startupProbe:
httpGet:
path: /health/startup
port: 3000
failureThreshold: 30
periodSeconds: 10
# 30 * 10s = 300s = 5 Minuten maximale Startzeit
# Liveness: läuft der Container noch? → Neustart bei Fail
livenessProbe:
httpGet:
path: /health/live
port: 3000
httpHeaders:
- name: X-Health-Check
value: "kubernetes"
initialDelaySeconds: 15
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
# Readiness: bereit für Traffic? → Entfernen aus LB bei Fail
readinessProbe:
httpGet:
path: /health/ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3
successThreshold: 2
Endpoints Health-Check-Endpoints in der App implementieren
// Node.js Express — Health Check Endpoints
const express = require('express');
const app = express();
// Startup: nur prüfen ob der Server läuft
app.get('/health/startup', (req, res) => {
res.status(200).json({ status: 'starting' });
});
// Liveness: keine externen Dependencies prüfen!
// Nur interne App-Gesundheit (Deadlocks, Memory-Leaks)
app.get('/health/live', (req, res) => {
const memUsage = process.memoryUsage();
if (memUsage.heapUsed > 400 * 1024 * 1024) {
// Mehr als 400MB Heap → ungesund
res.status(503).json({ status: 'unhealthy', reason: 'memory' });
return;
}
res.status(200).json({ status: 'alive' });
});
// Readiness: externe Dependencies prüfen
// Datenbank, Cache, externe APIs
app.get('/health/ready', async (req, res) => {
try {
await db.query('SELECT 1'); // DB-Check
await redis.ping(); // Cache-Check
res.status(200).json({ status: 'ready' });
} catch (err) {
res.status(503).json({ status: 'not ready', error: err.message });
}
});
Resource Quotas Namespace-Limits für stabile Cluster
# resourcequota.yaml — Limits für den Namespace
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
pods: "50"
services: "20"
---
# limitrange.yaml — Default Limits für Pods ohne explizite Angabe
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
- default:
memory: 256Mi
cpu: 200m
defaultRequest:
memory: 64Mi
cpu: 50m
type: Container
5. Helm Charts
Helm ist der Package Manager für Kubernetes. Mit Helm werden K8s-Manifeste zu wiederverwendbaren, versionierten Paketen — sogenannten Charts. Claude Code kann komplette Helm Chart Strukturen generieren, Values anpassen und Upgrade-Strategien entwickeln.
Chart-Struktur Anatomie eines Helm Charts
# Helm Chart Verzeichnisstruktur (von Claude Code generiert)
webapp-chart/
├── Chart.yaml # Chart-Metadaten (Name, Version, AppVersion)
├── values.yaml # Standard-Werte (überschreibbar)
├── values-prod.yaml # Production-spezifische Werte
├── values-staging.yaml # Staging-spezifische Werte
├── templates/
│ ├── _helpers.tpl # Wiederverwendbare Template-Funktionen
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── configmap.yaml
│ ├── secret.yaml
│ ├── hpa.yaml # HorizontalPodAutoscaler
│ ├── serviceaccount.yaml
│ └── NOTES.txt # Installationshinweise
└── charts/ # Sub-Charts (Dependencies)
Chart.yaml Chart-Metadaten definieren
# Chart.yaml
apiVersion: v2
name: webapp
description: A Helm chart for the WebApp application
type: application
version: 1.3.0 # Chart-Version (semver)
appVersion: "2.1.0" # App-Version (informativ)
keywords:
- webapp
- nodejs
- api
maintainers:
- name: Platform Team
email: platform@mycompany.com
dependencies:
- name: redis
version: 17.x.x
repository: https://charts.bitnami.com/bitnami
condition: redis.enabled
values.yaml Konfigurierbare Standardwerte
# values.yaml — alle konfigurierbaren Parameter
replicaCount: 3
image:
repository: myregistry.io/webapp
tag: "2.1.0"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 80
targetPort: 3000
ingress:
enabled: true
className: nginx
host: app.mycompany.com
tls: true
clusterIssuer: letsencrypt-prod
resources:
requests:
memory: 128Mi
cpu: 100m
limits:
memory: 512Mi
cpu: 500m
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 70
redis:
enabled: true
auth:
enabled: true
env:
LOG_LEVEL: info
NODE_ENV: production
Templates Helm Template-Syntax mit {{ .Values.xxx }}
# templates/deployment.yaml — Helm Template
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "webapp.fullname" . }}
namespace: {{ .Release.Namespace }}
labels:
{{- include "webapp.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
selector:
matchLabels:
{{- include "webapp.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "webapp.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- containerPort: {{ .Values.service.targetPort }}
resources:
{{- toYaml .Values.resources | nindent 10 }}
{{- if .Values.env }}
env:
{{- range $key, $val := .Values.env }}
- name: {{ $key }}
value: {{ $val | quote }}
{{- end }}
{{- end }}
Befehle Helm install, upgrade, rollback
# Helm Repository hinzufügen
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm repo update
# Chart installieren (erste Installation)
$ helm install webapp ./webapp-chart \
-n production \
-f values-prod.yaml \
--create-namespace
# Upgrade (bei Änderungen)
$ helm upgrade webapp ./webapp-chart \
-n production \
-f values-prod.yaml \
--atomic \
--timeout 5m0s
# Install ODER Upgrade (idempotent)
$ helm upgrade --install webapp ./webapp-chart \
-n production \
-f values-prod.yaml
# Releases auflisten
$ helm list -n production
NAME NAMESPACE REVISION STATUS CHART APP VERSION
webapp production 3 deployed webapp-1.3.0 2.1.0
# Rollback auf vorherige Version
$ helm rollback webapp 2 -n production
# Template rendern (Dry-Run)
$ helm template webapp ./webapp-chart -f values-prod.yaml
# Chart deinstallieren
$ helm uninstall webapp -n production
💡 Helm Best Practice: Nutze
--atomic beim Upgrade. Bei Fehlern wird automatisch auf die vorherige Version zurückgerollt. Kombiniert mit --timeout 5m0s ist das ein sicheres Production-Upgrade-Pattern. Claude Code empfiehlt diese Flags standardmäßig.
6. Claude Code für Kubernetes
Claude Code ist mehr als ein Manifest-Generator — es ist ein vollständiger K8s-Arbeitspartner. Es erklärt unbekannte Ressourcentypen, debuggt fehlschlagende Deployments, optimiert bestehende Konfigurationen und erstellt komplette GitOps-Workflows für Production-Cluster.
Manifest-Generierung Produktionsreife K8s-Infrastruktur auf Abruf
Claude Code generiert vollständige Kubernetes-Manifeste aus natürlichsprachlichen Beschreibungen — inklusive aller Best Practices:
- Rolling Update Strategien mit konfigurierbaren maxUnavailable/maxSurge
- Health Checks (liveness, readiness, startup) mit sinnvollen Schwellenwerten
- Resource Requests und Limits basierend auf typischen Workload-Profilen
- Security Context (runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false)
- Pod Disruption Budgets für hochverfügbare Dienste
- Anti-Affinity Rules für Pods über mehrere Nodes
# Claude Code Prompt-Beispiele:
"Erstelle ein Kubernetes Deployment für eine FastAPI-App
mit 3 Replicas, PostgreSQL-Verbindung via Secret,
Redis Cache, HPA bis 15 Replicas und HTTPS Ingress
mit cert-manager auf api.mycompany.com"
"Konvertiere diesen Docker Compose File in Kubernetes
Manifeste mit korrekt konfigurierten Services und
einem Namespace für jede Umgebung"
"Erkläre mir kubectl explain deployment.spec.strategy
und zeige Best-Practice-Beispiele für die
Update-Strategie in einer Production-Umgebung"
kubectl explain K8s API-Dokumentation direkt im Terminal
# Alle Felder eines Resources erklären lassen
$ kubectl explain deployment
$ kubectl explain deployment.spec
$ kubectl explain deployment.spec.template.spec.containers
$ kubectl explain pod.spec.containers.livenessProbe
# Claude Code kann kubectl explain-Output interpretieren
# und in verständliche Empfehlungen übersetzen
# Alle verfügbaren API-Ressourcen anzeigen
$ kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
deployments deploy apps/v1 true Deployment
services svc v1 true Service
ingresses ing networking.k8s.io/v1 true Ingress
configmaps cm v1 true ConfigMap
secrets v1 true Secret
horizontalpodautoscalers hpa autoscaling/v2 true HorizontalPodAutoscaler
Debugging Problematische Deployments diagnostizieren
# Deployment-Status prüfen
$ kubectl get pods -n production
NAME READY STATUS RESTARTS AGE
webapp-7d9b5f8c9-xk2p1 0/1 CrashLoopBackOff 5 8m
# Events für Pod anzeigen (häufig erste Diagnose)
$ kubectl describe pod webapp-7d9b5f8c9-xk2p1 -n production
# Logs des abgestürzten Containers
$ kubectl logs webapp-7d9b5f8c9-xk2p1 -n production --previous
# Debug-Container in laufenden Pod injizieren (K8s 1.23+)
$ kubectl debug -it webapp-7d9b5f8c9-xk2p1 \
--image=busybox --target=webapp -n production
# Pod für Debugging starten (kopierter Pod mit Shell)
$ kubectl debug webapp-7d9b5f8c9-xk2p1 \
-it --copy-to=debug-pod \
--image=ubuntu -n production
# Netzwerk-Debugging: temporären Pod starten
$ kubectl run netdebug \
--image=nicolaka/netshoot \
--rm -it -n production -- /bin/bash
GitOps Kompletter GitOps-Workflow mit ArgoCD
# argocd-app.yaml — ArgoCD Application für GitOps
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: webapp-production
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/mycompany/k8s-manifests
targetRevision: main
path: apps/webapp/production
# Helm-Quelle alternativ:
helm:
valueFiles:
- values-prod.yaml
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true # Entfernt Ressourcen die nicht mehr im Git sind
selfHeal: true # Korrigiert manuelle Cluster-Änderungen
syncOptions:
- CreateNamespace=true
- PrunePropagationPolicy=foreground
HPA Automatische horizontale Skalierung
# hpa.yaml — HorizontalPodAutoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: webapp-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: webapp
minReplicas: 2
maxReplicas: 15
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: AverageValue
averageValue: 400Mi
behavior:
scaleUp:
stabilizationWindowSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
# HPA Status beobachten
$ kubectl get hpa -n production -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
webapp-hpa Deployment/webapp 42%/70%, 210Mi 2 15 3
Security Context Pods sicher ausführen
# deployment.yaml — Security Best Practices
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: webapp
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
volumeMounts:
- name: tmp-volume
mountPath: /tmp
- name: cache-volume
mountPath: /app/.cache
volumes:
- name: tmp-volume
emptyDir: {}
- name: cache-volume
emptyDir: {}
Workflow Claude Code K8s-Debugging-Workflow
Typischer Ablauf wenn ein Deployment fehlschlägt:
- Symptom beschreiben: "Mein Deployment bleibt auf 0/3 Pods hängen" → Claude Code fragt nach kubectl-Output
- kubectl describe: Claude Code analysiert Events und identifiziert die Root Cause (ImagePullBackOff, OOMKilled, Scheduling-Fehler etc.)
- Fix generieren: Korrektes Manifest mit der Lösung — z.B. imagePullSecrets, erhöhte Memory-Limits, Node-Affinity
- Verify: Claude Code zeigt kubectl-Befehle zur Verifikation des erfolgreichen Rollouts
- Prevention: Empfehlungen für Monitoring und Alerting damit das Problem nicht wieder auftritt
💡 Claude Code im DevOps-Mastery-Kurs: Im vollständigen K8s-Modul lernst du, wie Claude Code als DevOps-Copilot eingesetzt wird — von der lokalen Minikube-Entwicklung bis zu Production-Clustern auf AWS EKS, Google GKE oder Azure AKS. Inklusive GitOps mit ArgoCD, Monitoring mit Prometheus/Grafana und automatisierten Rollout-Pipelines.
DevOps-Modul im Kurs
Im Claude Code Mastery Kurs: vollständiges Kubernetes-Modul — von lokalem Minikube bis Production-Cluster mit Helm, ArgoCD und GitOps-Workflows.
14 Tage kostenlos testen →