Revisión de manifests GKE para manufactura con Claude Code

En una fábrica, una pantalla de inspección caída a las 8 de la mañana no es solo una caída web. El equipo vuelve al papel, calidad pierde marcas de tiempo y antes del mediodía aparece una conciliación CSV. Este artículo revisa manifiestos de GKE con Claude Code antes de producción.

Key Points

La revisión de GKE en manufactura empieza por minutos de línea detenida, respaldo en papel, registros de calidad y rollback. Luego se miran image tag, replicas, probes, resources, exposición del Service, secretos y Workload Identity.

Workflow Before Production Release

Primero se ordena el horario: reunión, pico de inspección, corte de envíos, jobs nocturnos y ventana de mantenimiento. Después Claude Code revisa el diff YAML y crea una lista, pero operaciones y calidad aprueban.

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 Spanish 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

El error es pensar que un YAML válido ya está aprobado. Puede enrutar tráfico muy pronto, exponer una impresora de etiquetas o usar identidad demasiado amplia.

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

P. ¿GKE es demasiado para manufactura?\n\nR. A veces. Sirve cuando hay varios servicios internos, jobs y revisiones de release en una plataforma común.

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

En español mantuve el foco en horarios de fábrica, registros de calidad, etiquetas y CTA de consultoría. 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.