Kubernetes mit Claude Code: Deployment, Service, Ingress und Rollback

YAML erzeugen, das man wirklich prüfen kann

Kubernetes betreibt containerisierte Anwendungen in einem Cluster. Für Einsteiger ist aber nicht der Cluster das erste Problem, sondern die Menge an Begriffen: Deployment, Service, Ingress, ConfigMap, Secret, Probes, Requests, Limits, Rollout und Rollback. Wenn du Claude Code nur bittest, Kubernetes-YAML zu generieren, entsteht leicht ein Manifest, das plausibel aussieht, aber latest nutzt, keine readinessProbe hat, Secrets in Git schreibt oder einen Service zu weit öffnet.

Dieser Guide nutzt Claude Code anders: als Werkzeug, das ein sicheres Grundgerüst baut und die Review-Fläche sichtbar macht. Das Beispiel verwendet nginx:1.27-alpine und eine HTML-Seite aus einer ConfigMap. Es braucht kein privates Image und kann in kind, minikube, Docker Desktop Kubernetes oder einem Testcluster ausgeführt werden.

Passe das Beispiel nur mit offiziellen Quellen an: Deployments, Services, Ingress, Probes, Ressourcen, ConfigMap, Secret und kubectl rollout. Ergänzend passen Docker Integration, CI/CD Setup, Code Review und Permissions Guide.

Praktische Anwendungsfälle

Beginne nicht mit einer großen Plattform. Baue zuerst eine kleine Einheit, die du deployen, prüfen, absichtlich beschädigen und zurückrollen kannst.

Fall	Ziel	Aufgabe für Claude Code
Erstes internes Tool	Eine Web-App hinter einen stabilen Service stellen	Deployment, ClusterIP Service, Probes, Requests und Limits
Training oder Workshop	Alle Teilnehmenden nutzen dieselben Befehle	Manifest mit Namespace, Prüfkommandos, Fehlerübung
Review vor Produktion	Gefährliche YAML-Änderungen finden	Selector-, Secret-, Probe-, Ingress- und Rollback-Prüfung
Pull-Request-Gate	Infrastrukturfehler vor dem Merge stoppen	dry-run CI und Review-Checkliste

Das Thema eignet sich auch für Monetarisierung, weil der Leser meist ein echtes Risiko vermeiden will. ClaudeCodeLab verbindet solche Guides mit kostenlosen Ressourcen, Templates und Claude Code Training und Beratung für Teams, die den Ablauf in ihr Repository übernehmen möchten.

Claude Code klare Grenzen geben

Ein guter Kubernetes-Prompt beschreibt auch, was nicht erzeugt werden darf. Sonst wählt das Modell vielleicht LoadBalancer, schreibt Beispiel-Secrets, ergänzt Cluster-RBAC oder nimmt einen Ingress Controller an, den dein Cluster nicht nutzt.

Erstelle ein Kubernetes-Beispiel für Einsteiger, das lokal getestet werden kann.

Anforderungen:
- namespace claude-k8s-demo
- nginx:1.27-alpine verwenden, kein privates Image
- ConfigMap mit einer HTML-Seite
- Deployment mit replicas 2, RollingUpdate, readinessProbe, livenessProbe und resources
- Service als ClusterIP
- optionaler Ingress mit host claude-k8s.local
- Secret-Policy erklären, aber keine echten Secret-Werte generieren
- Befehle für apply, rollout status, port-forward, Fehler und rollback angeben

Grenzen:
- kein NodePort und kein LoadBalancer
- keine echten Secret-Werte in YAML
- keine ClusterRole, ClusterRoleBinding oder destruktive Cleanup-Befehle

Damit wird die Review konkret: Labels, Selectors, Probes, Ports, Resources und Secrets. Wiederkehrende Regeln gehören in CLAUDE.md; siehe CLAUDE.md Best Practices.

Manifest zum Kopieren

Speichere diese Datei als k8s/claude-k8s-demo.yaml. Ingress braucht einen Controller; der Service lässt sich immer per port-forward prüfen.

apiVersion: v1
kind: Namespace
metadata:
  name: claude-k8s-demo
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-page
  namespace: claude-k8s-demo
data:
  APP_ENV: "demo"
  index.html: |
    <!doctype html>
    <html lang="de">
      <head><meta charset="utf-8" /><title>Claude Code Kubernetes Demo</title></head>
      <body><h1>Claude Code Kubernetes Demo</h1><p>Deployment, Service, ConfigMap, probes are running.</p></body>
    </html>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
  namespace: claude-k8s-demo
  labels:
    app: demo-web
spec:
  replicas: 2
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: demo-web
  template:
    metadata:
      labels:
        app: demo-web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - name: http
              containerPort: 80
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "250m"
              memory: "128Mi"
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 10
            periodSeconds: 10
          volumeMounts:
            - name: demo-page
              mountPath: /usr/share/nginx/html/index.html
              subPath: index.html
              readOnly: true
      volumes:
        - name: demo-page
          configMap:
            name: demo-page
---
apiVersion: v1
kind: Service
metadata:
  name: demo-web
  namespace: claude-k8s-demo
spec:
  type: ClusterIP
  selector:
    app: demo-web
  ports:
    - name: http
      port: 80
      targetPort: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-web
  namespace: claude-k8s-demo
spec:
  ingressClassName: nginx
  rules:
    - host: claude-k8s.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: demo-web
                port:
                  name: http

Der wichtigste Anfängerfehler ist ein Mismatch zwischen selector.matchLabels, Pod-Labels und Service-Selector. Bitte Claude Code ausdrücklich, diese drei Stellen gemeinsam zu prüfen.

Lokal prüfen

Prüfe zuerst mit kubectl cluster-info, dass du im richtigen Cluster bist.

kubectl apply -f k8s/claude-k8s-demo.yaml
kubectl -n claude-k8s-demo rollout status deployment/demo-web
kubectl -n claude-k8s-demo get pods -l app=demo-web
kubectl -n claude-k8s-demo get service demo-web
kubectl -n claude-k8s-demo port-forward service/demo-web 8080:80

In einem zweiten Terminal:

curl http://localhost:8080/

Ingress kommt danach. Erst Pod und Service beweisen, dann Hostrouting debuggen.

kubectl -n claude-k8s-demo get ingress demo-web
kubectl -n claude-k8s-demo describe ingress demo-web

ConfigMap, Secret und Rollback

ConfigMap ist für nicht geheime Konfiguration. Secret ist für sensible Werte, aber ein base64-codiertes Secret-Manifest gehört trotzdem nicht in Git. Base64 ist keine Verschlüsselung. In Produktion braucht ihr Secret Manager, External Secrets, Sealed Secrets, SOPS oder einen internen Vault-Prozess.

Für lokale Übungen:

kubectl -n claude-k8s-demo create secret generic demo-api-secret \
  --from-literal=API_TOKEN='replace-me-locally' \
  --dry-run=client \
  -o yaml > secret.local.yaml

kubectl apply -f secret.local.yaml

Rollout und Fehlerfall:

kubectl -n claude-k8s-demo set image deployment/demo-web nginx=nginx:1.27-alpine
kubectl -n claude-k8s-demo rollout status deployment/demo-web
kubectl -n claude-k8s-demo rollout history deployment/demo-web
kubectl -n claude-k8s-demo set image deployment/demo-web nginx=nginx:not-a-real-tag
kubectl -n claude-k8s-demo rollout status deployment/demo-web --timeout=30s
kubectl -n claude-k8s-demo rollout undo deployment/demo-web

Ein Rollback des Deployments nimmt nicht automatisch ConfigMaps, Secrets, Migrationen, DNS oder Feature Flags zurück. Das Runbook sollte diese Grenze klar nennen.

CI, Fehler und nächster Schritt

Ein minimales Pull-Request-Gate:

name: Kubernetes manifest review
on:
  pull_request:
    paths:
      - "k8s/**"
jobs:
  dry-run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/setup-kubectl@v4
        with:
          version: "v1.30.0"
      - run: kubectl apply --dry-run=client -f k8s/

Häufige Fehler sind latest in Produktion, verwechselte readiness/liveness-Probes, fehlende Resources, base64 als vermeintliche Sicherheit, Ingress-Debugging vor Service-Prüfung und ungeprüfte Claude-Code-Ausgaben. Gegenmittel sind offizielle Docs, CI, lokale Verifikation, klare Prompts und menschliche Reviews.

Dieses Beispiel ist klein. In echten Projekten kommen Docker-Builds, immutable Tags, TLS, Secret-Injection, Monitoring, RBAC, CI/CD und Incident-Kommunikation dazu. Einzelne Entwickler starten mit dem kostenlosen Cheatsheet. Teams können über Claude Code Training und Beratung Prompts, CLAUDE.md, Review-Regeln und Rollback-Übungen auf ihr Repository anpassen. Für diesen Artikel ist der Prüfpfad apply, rollout status, Pods, port-forward, curl, ungültiges Image, sichtbarer Fehler und rollout undo.

Kubernetes mit Claude Code: Deployment, Service, Ingress und Rollback

YAML erzeugen, das man wirklich prüfen kann

Praktische Anwendungsfälle

Claude Code klare Grenzen geben

Manifest zum Kopieren

Lokal prüfen

ConfigMap, Secret und Rollback

CI, Fehler und nächster Schritt

Kostenloses PDF: Claude-Code-Cheatsheet

Ähnliche Artikel

Claude Code Workflow von Obsidian zu CLAUDE.md

Claude Code Revenue CTA Routing: Artikel zu PDF, Gumroad und Beratung führen

Claude-Code-Team-Handoff-Regeln: Belege, Berechtigungen, Rollback und Umsatzpfade