gke-manifest-generation

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: