gke-manifest-generation

Files (6)

• SKILL.md
• ai-inference.md · references/
• attribution.md · references/
• basic-workload.md · references/
• gateway-api.md · references/
• network-policy.md · references/

SKILL.md (first lines)

# 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.

## Attribution

**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you
MUST read [Usage Attribution](references/attribution.md). For commands executed
directly in the terminal (never in generated scripts, Terraform, or user code),
prefix `gcloud` with
`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-manifest-generation)"`
and append `agent-skills/1.0 (skill:gke-manifest-generation)` to `User-Agent` headers.

## 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:

    ```yaml
    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:

    ```yaml
    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 internet.
-   **Port Naming**: Always assign clear, standard names to service and

From google/skills, Apache-2.0.

More from google/skills