Revisão de manifests GKE para manufatura com Claude Code

Em uma fábrica, a tela de inspeção fora do ar às 8h não é só falha web. Operadores voltam ao papel, qualidade perde horários e o CSV de conciliação aparece antes do almoço. Este artigo revisa manifests GKE com Claude Code antes da produção.

Key Points

A revisão de GKE na manufatura começa por minutos parados, plano em papel, registros de qualidade e rollback. Depois entram image tag, replicas, probes, resources, exposição do Service, secrets e Workload Identity.

Workflow Before Production Release

Primeiro vem o calendário da fábrica: reunião, pico de inspeção, corte de envio, jobs noturnos e manutenção. Claude Code lê o diff YAML e cria a checklist; operações e qualidade aprovam.

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

O erro é tratar YAML válido como aprovação de produção. Ele ainda pode mandar tráfego cedo demais, expor impressora de etiqueta ou usar identidade ampla.

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 é demais para manufatura?\n\nR. Às vezes. Faz sentido quando vários serviços, jobs e revisões de release compartilham uma plataforma.

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

Em português, mantive agenda de fábrica, qualidade, impressão de etiquetas e CTA de consultoria. 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.