/gke-manifest-generation

name: gke-manifest-generation
metadata:
  category: Containers
description: >-
  Generates and updates secure, production-ready Kubernetes YAML manifests optimized for GKE Autopilot and GKE Standard clusters. Use when creating or modifying GKE deployment manifests, configuring container security contexts, setting CPU/memory resource limits, defining readiness/liveness/startup probes, mounting secrets and volumes, configuring GKE Gateway API routes, targeting Spot VMs, or deploying AI model inference workloads (vLLM, TGI, Gemma). Don't use for live cluster operations, pod troubleshooting (use gke-workload-troubleshooting), or cluster infrastructure provisioning (use gke-cluster-creation).

GKE Manifest Generation Skill

This skill provides guidelines, tooling integration, and templates to translate natural language descriptions or application code changes into secure, compliant, and cost-effective Kubernetes YAML manifests optimized for both GKE Autopilot and GKE Standard clusters.

Core Rules & Verification

When generating or updating YAML manifests, you **must** strictly adhere to the following rules:

1. Namespace & Resource Isolation

• **Explicit Namespace**: Always declare `namespace: {namespace}` explicitly

in the metadata of every resource (Deployments, Services, ConfigMaps, Secrets, PVCs, Roles, bindings). Map it to the namespace configured in your active `SETTINGS.md`. Never omit the namespace.

• **Dedicated ServiceAccount**: Avoid using the namespace's `default`

ServiceAccount. Always create and reference a dedicated `ServiceAccount` (e.g., `devteam-agent-sa`) for each microservice.

2. GKE Resource Tuning (Autopilot & Standard)

• **Resources Requests & Limits**: Always specify CPU and Memory requests and

limits for all containers.

• *GKE Autopilot*: Requests determine pod billing directly; requests and

limits must be equal. If they differ, Autopilot will automatically scale requests up to match limits, which can significantly increase costs.

• *GKE Standard*: Requests ensure stable scheduling and bin-packing;

limits prevent resource starvation/noisy-neighbor issues.

• **Density Defaults**: For stateless apps or sidecars on GKE Standard,

default to conservative requests (e.g., `requests.cpu: "100m"` or `"200m"`, `requests.memory: "256Mi"` or `"512Mi"`) with burstable limits. Use a reasonable overcommit ratio for limits (e.g., 2x to 4x requests, like `limits.cpu: "400m"` to `"800m"`, and `limits.memory: "512Mi"` to `"1Gi"`). Avoid excessive overcommit limits (like `limits.cpu: "4"` for a `100m` request) to prevent severe CPU throttling and latency degradation under heavy scheduling load, particularly in environments without guaranteed node shares.

• **Spot VMs for Staging/Dev**: For non-production workloads (e.g., namespaces

containing `-test`, `-dev`, or `-staging`), or if the user requests cost optimization, automatically target GKE Spot VMs. This requires injecting both the `nodeSelector` targeting Spot VMs AND the corresponding toleration to tolerate the Spot VM taint:

    nodeSelector:
      cloud.google.com/gke-spot: "true"
    tolerations:
      - key: "cloud.google.com/gke-spot"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

(On GKE Standard, this assumes a Spot node pool is configured).

3. Container Security Hardening (Pod Security Standards)

• **Non-Root Execution**: Always configure `securityContext` at the Pod level

(and container level if overriding) to run as a non-root user (e.g., `runAsNonRoot: true`, `runAsUser: 10000`, `runAsGroup: 10000`, `fsGroup: 10000`). This is strictly enforced on GKE Autopilot and is a critical security baseline for GKE Standard.

• **Minimal Privileges**: Always set `allowPrivilegeEscalation: false` and

`seccompProfile: {type: RuntimeDefault}`.

• **Read-Only Root Filesystem**: Set `readOnlyRootFilesystem: true` to prevent

modifications to the container image filesystem.

• *Writable Directory Fallback*: If `readOnlyRootFilesystem` is enabled,

mount a local `emptyDir` volume to `/tmp` or `/var/run/` to allow applications (like Java/Nginx) to write temp files without crashing.

• **Secret Volume Mounting**: Prefer mounting Secrets as read-only files

(configured in the `volumes` spec with `defaultMode: 0400`) instead of mapping them as environment variables, unless the application framework exclusively supports env-var based configuration. This prevents secrets leaking into application logs.

4. Health Checking (Mandatory Probes)

• **Liveness & Readiness Probes**: Every Deployment container must define both

`livenessProbe` and `readinessProbe`.

• **Web/API**: Use `httpGet` probes.
• **TCP Services**: Use `tcpSocket` probes.
• **Databases/Caches**: Use command-based `exec` probes (e.g.,

`exec.command: ["redis-cli", "ping"]`).

• **Startup Probes for Slow-Starting Apps**: For applications with slow boot

times (e.g., Java spring boot, complex Python scripts, LLM model servers), you **must** also define a `startupProbe`. When a `startupProbe` is defined, the liveness and readiness probes are disabled until it succeeds, preventing Kubernetes from prematurely killing the pod during startup:

    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

• **Sensible Defaults**: Set `initialDelaySeconds: 5` to `15` depending on

startup time (e.g., Java requires a longer delay than Go/Nginx).

5. Services & Ingress Routing

• **Internal ClusterIP**: Default all internal microservices to `type:

ClusterIP`. Never use `type: LoadBalancer` or `NodePort` unless the workload is explicitly intended to be publicly accessible from the i