GKE-Manifest-Review für Fertigung mit Claude Code

In einer Fertigung ist ein ausgefallener Prüfbildschirm um 8 Uhr kein normaler Webfehler. Mitarbeitende wechseln auf Papier, Qualität verliert Zeitstempel, und mittags wartet CSV-Abgleich. Dieser Artikel prüft GKE-Manifeste mit Claude Code vor dem Produktionsrelease.

Key Points

Der GKE-Review in der Fertigung beginnt mit Stillstandsminuten, Papier-Fallback, Qualitätsdaten und Rollback-Zeit. Danach folgen image tag, replicas, probes, resources, Service-Exposure, secrets und Workload Identity.

Workflow Before Production Release

Zuerst wird der Fabrikplan sichtbar: Morgenrunde, Prüfspitzen, Versandschluss, Nachtjobs und Wartungsfenster. Claude Code liest den YAML-Diff und erstellt die Liste; Betrieb und Qualität entscheiden.

Review area	File or screen	Stop condition
Image	Deployment YAML and CI artifact	latest tag or unapproved local build
Probes	readiness, liveness, startup	traffic reaches a pod before it is ready
Resources	requests and limits	no CPU or memory boundary
Exposure	Service and Ingress	unexpected LoadBalancer or public endpoint
Identity	serviceAccountName and IAM	default account or secret keys in YAML

What Claude Code Does and What Humans Decide

Claude Code drafts the checklist, kubectl commands, rollback notes, and short release message. Humans decide release time, allowed downtime, quality records, personal data, credentials, external exposure, and factory approval. That split matters because a manifest can be valid while the line cannot accept the risk.

3 Use Cases

Use case 1: Review inspection API Deployment

• Input: Deployment YAML, image tag, inspection screen peak time, incident notes.
• Output: release checklist for image, replicas, probes, resources, and rollback.
• Human review: QA approval, paper fallback, release time, and line owner.

Use case 2: Check label printing exposure

• Input: Service, Ingress, Namespace, terminal IP range, authentication note.
• Output: exposure review, allowed network, and command list.
• Human review: whether the service should ever be reachable outside the factory network.

Use case 3: Review quality aggregation job identity

• Input: CronJob, ServiceAccount, IAM role, BigQuery dataset, Cloud Storage bucket.
• Output: Workload Identity checklist, broad role warning, and secret handling note.
• Human review: dataset scope, inspection images, vendor data, and audit log retention.

Copy-Paste Prompt

Act as a German manufacturing GKE production release reviewer.
Goal: prevent inspection screens, progress boards, label printing, and quality aggregation jobs from failing after a manifest change.

Review:
- Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / CronJob YAML
- CI image tag
- planned release time
- factory peak time
- rollback note

Return:
1. release / hold / reject decision
2. five manifest lines a beginner should inspect today
3. missing probes, resources, replicas, identity, or exposure controls
4. kubectl verification commands
5. rollback commands
6. short message for factory operations

Working Check Code

// verify-gke-manifest.mjs
// No dependencies. Run with: node verify-gke-manifest.mjs
const manifest = `
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inspection-api
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: asia-northeast1-docker.pkg.dev/factory/prod/inspection-api:latest
          env:
            - name: CAMERA_API_KEY
              value: "plain-secret"
---
apiVersion: v1
kind: Service
metadata:
  name: inspection-api
spec:
  type: LoadBalancer
  ports:
    - port: 80
`;

const checks = [
  {
    name: "pinned image tag",
    failed: /:latest\b/.test(manifest),
    fix: "use a digest or release tag approved by QA"
  },
  {
    name: "replica count",
    failed: /replicas:\s*1\b/.test(manifest),
    fix: "set replicas to at least 2 for customer-facing production screens"
  },
  {
    name: "readiness probe",
    failed: !/readinessProbe:/.test(manifest),
    fix: "add readinessProbe before routing traffic"
  },
  {
    name: "liveness probe",
    failed: !/livenessProbe:/.test(manifest),
    fix: "add livenessProbe with a safe initial delay"
  },
  {
    name: "resources",
    failed: !/resources:\s*[\s\S]*requests:\s*[\s\S]*limits:/.test(manifest),
    fix: "set CPU and memory requests and limits"
  },
  {
    name: "plain secret",
    failed: /API_KEY[\s\S]*value:\s*["'][^"']+["']/.test(manifest),
    fix: "move secrets to Secret Manager or an approved secret flow"
  },
  {
    name: "service exposure",
    failed: /type:\s*LoadBalancer/.test(manifest),
    fix: "confirm whether an internal Service or controlled Ingress is intended"
  },
  {
    name: "service account",
    failed: !/serviceAccountName:/.test(manifest),
    fix: "use a named Kubernetes service account and Workload Identity"
  }
];

const failures = checks.filter((check) => check.failed);
if (failures.length > 0) {
  console.table(failures.map(({ name, fix }) => ({ name, fix })));
  process.exitCode = 1;
} else {
  console.log("GKE manifest release checklist passed.");
}

Pitfall: Common Failure Cases

Der Fehler ist, syntaktisch gültige YAML als Freigabe zu behandeln. Das Manifest kann Traffic zu früh routen, Labeldrucker öffnen oder eine zu breite Identität nutzen.

The first failure is trusting a successful apply. Kubernetes accepts many manifests that are unsafe for a factory release. Add a production checklist before apply.

The second failure is using liveness and readiness without understanding the difference. Readiness controls traffic. Liveness restarts a container. A slow inspection API can be killed by an aggressive liveness probe.

The third failure is treating base64 as security. Secret manifests need a real policy, not plain credentials in Git.

FAQ

F. Ist GKE für Fertigung zu groß?\n\nA. Manchmal. Es passt, wenn mehrere interne Dienste, Jobs und Release-Prüfungen eine gemeinsame Plattform brauchen.

Q. Should every factory system run on GKE?

A. No. Small internal tools may fit Cloud Run, a VM, or an existing platform. GKE makes sense when several services, jobs, rollouts, identity rules, and operational checks need one platform.

Q. What should beginners check first?

A. Image tag, replicas, readinessProbe, resources, and serviceAccountName. Those five lines catch many risky releases.

Q. Where should teams go next?

A. Teams that need manifests, CI review, Workload Identity, and rollback drills can start from ClaudeCodeLab training.

What I Verified

Die deutsche Version bleibt bei Fertigungsplan, Qualitätsdaten, Labeldruck und Beratungspfad. I checked GKE best practices, GKE Workload Identity, Kubernetes Deployments, Kubernetes probes, and Kubernetes resource management. I also checked the CTA, internal link, executable JavaScript, and locale coverage.