Manufacturing GKE manifest review with Claude Code

Factory में सुबह 8 बजे inspection screen बंद होना सिर्फ web outage नहीं है। operator paper पर लौटते हैं, QA timestamp खोता है, और दोपहर से पहले CSV मिलान जमा हो जाता है। यह लेख production release से पहले Claude Code से GKE manifest review कराता है।

Key Points

Manufacturing GKE review line stop minutes, paper fallback, quality records और rollback time से शुरू होता है। फिर image tag, replicas, probes, resources, Service exposure, secrets और Workload Identity देखे जाते हैं।

Workflow Before Production Release

पहले factory schedule देखें: morning meeting, inspection peak, shipping cutoff, night jobs और maintenance window। Claude Code YAML diff पढ़कर checklist बनाता है; operations और QA release approve करते हैं।

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

गलती यह है कि valid YAML को production approval मान लिया जाए। manifest traffic जल्दी भेज सकता है, internal label printer खोल सकता है, या बहुत broad identity चला सकता है।

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

Q. क्या manufacturing के लिए GKE बहुत बड़ा है?\n\nA. कभी-कभी। जब कई internal services, jobs और rollback checks एक platform पर चाहिए हों, तब GKE उचित हो सकता है।

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

Hindi version में factory schedule, quality records, label printing और consultation CTA रखा गया। 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.