gke-reliability
Improves GKE workload reliability, using PDBs, health probes, and topology spread constraints. Use when configuring GKE workload reliability, setting up PDBs, or configuring GKE health probes (liveness, readiness, startup). Don't use for generating K8s YAML manifests (use gke-manifest-generation) or
- 0
- Installs
- —
- Rating
- —
- Success rate
- 1
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 89161506be45b634… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
GKE Reliability
Routing Note: To generate Kubernetes YAML manifests (
Deployment,StatefulSet,Service,ConfigMap,HTTPRoute,PodDisruptionBudget), opengke-manifest-generation/SKILL.md.
This reference covers high availability and reliability configuration for GKE clusters and workloads.
MCP Tools:
get_cluster,get_k8s_resource,describe_k8s_resource,apply_k8s_manifest,list_k8s_events
Golden Path Reliability Defaults
| Setting | Golden Path Value | Notes |
|---|---|---|
| Cluster type | Regional (4 zones: | Control plane replicated across |
| : : us-central1-a/b/c/f) : zones : | ||
| Upgrade strategy | SURGE (maxSurge: 1) | Rolling upgrades with extra |
| : : : capacity : | ||
| Auto-repair | true | Unhealthy nodes replaced |
| : : : automatically : | ||
| Auto-upgrade | true | Nodes follow control plane |
| : : : version : | ||
| Release channel | REGULAR | Balanced freshness and stability |
| Stateful HA | Enabled | Leader election for stateful |
| : : : workloads : |
Workflows
1. Verify Cluster High Availability
# MCP (preferred)
get_cluster(name="projects/<PROJECT>/locations/<REGION>/clusters/<CLUSTER>",
readMask="location,locations,nodePools.locations")
# gcloud fallback
gcloud container clusters describe <CLUSTER> --region <REGION> \
--format="json(location, locations)" \
--quiet
- If
locationis a region (e.g.,us-central1), the control plane is regional - If
locationshas multiple entries, nodes span multiple zones
2. Pod Disruption Budgets (PDBs)
PDBs ensure minimum pod availability during voluntary disruptions (node upgrades, autoscaler scale-down).
Check existing PDBs:
# MCP (preferred)
get_k8s_resource(parent="...", resourceType="poddisruptionbudget")
# kubectl fallback
kubectl get pdb --all-namespaces
Create PDB:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
namespace: default
spec:
minAvailable: 2 # Or use maxUnavailable: 1
selector:
matchLabels:
app: my-app
Every production Deployment with 2+ replicas should have a PDB.
3. Health Probes
Every production container should have liveness and readiness probes. Startup probes are recommended for slow-starting apps.
Check existing probes:
# MCP (preferred)
describe_k8s_resource(parent="...", resourceType="deployment", name="<APP>", namespace="<NS>")
# kubectl fallback
kubectl get deployment <APP> -n <NS> -o yaml | grep -E "livenessProbe|readinessProbe|startupProbe"
Recommended probe configuration:
spec:
containers:
- name: app
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
startupProbe: # For slow-starting apps
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 30 # 30 * 5s = 150s max startup time
- Readiness: Determines when a pod can accept traffic
- Liveness: Determines when to restart a container
- Startup: Disables liveness/readiness until the app is ready (prevents premature restarts)
4. Graceful Shutdown
Ensure applications handle SIGTERM and drain in-flight requests:
spec:
terminationGracePeriodSeconds: 30 # Default; increase for long-running requests
containers:
- name: app
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 5"] # Allow LB to deregister
5. Topology Spread Constraints
Distribute pods across zones and nodes to survive failures:
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: my-app
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: my-app
- Zone spread (
DoNotSchedule): Hard requirement -- pods must be balanced across zones - Node spread (
ScheduleAnyway): Best-effort -- prefer distribution but don't block scheduling
6. Replicas
| Workload Type | Minimum Replicas | Reason |
|---|---|---|
| Stateless web/API | 2 | Survive single pod/node |
| : : : failure : | ||
| Critical services | 3 | Survive zone failure with zone |
| : : : spread : | ||
| Stateful (databases) | 3 (with replication) | Application-level quorum |
| Batch/jobs | 1 | Ephemeral by nature |
Best Practices & Production Guidelines
- Regional clusters for production: Always use regional clusters to survive zone failures.
- PDBs for everything: Every production workload with 2+ replicas needs a PodDisruptionBudget (PDB) to protect against voluntary disruptions.
- Probes with Explicit Timeouts: Every production container must have both
liveness and readiness probes defined. Always explicitly define
initialDelaySeconds,periodSeconds, andtimeoutSecondsfor all probes. Never rely on the Kubernetes default timeout of 1 second if your application requires more, but always set a strict limit to prevent hanging connections. - Zone spreading: Use topology spread constraints to distribute pods across failure domains (zones and nodes).
- Graceful shutdown: Handle
SIGTERMand set appropriateterminationGracePeriodSecondswith apreStopsleep hook to allow load balancer deregistration. - Maintenance windows: Schedule upgrades during low-traffic periods (see
the
gke-upgradesskill).
Files
1- SKILL.md
965c75a0a77.0 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from google/skills8
Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for st
Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available model
Manages Agent Platform serving endpoints. Use when you need to create, list, describe, update, or delete serving endpoints for model deployment on Agent Platform. Also use when troubleshooting endpoint permission, quota, or resource busy errors. Don't use for deploying models to endpoints or for run
Measures and improves the quality of AI models and agents on Google Cloud using the Eval Quality Flywheel methodology. Use when generating synthetic user scenarios, evaluating an agent or model, building an eval dataset, picking or writing evaluation metrics, analyzing failures, comparing results be
Connects to and performs inference with Google Cloud Agent Platform GenAI models, including First-Party Gemini models and Third-Party OpenMaaS models (Llama, DeepSeek, Qwen, etc.). Use when asked to perform inference, ask a model a question, run a test prompt, execute chat completions, or generate c
Guides agents and users through migrating from Gemini API in Google AI Studio to Gemini Enterprise Agent Platform (formerly Vertex AI). Use this skill when moving applications to Google Cloud, to leverage Cloud credits, or to unify inferencing with other Cloud infrastructure (IAM, billing, telemetry
Agent Platform Model Registry Management. Use when you need to upload, list, describe, update, or delete machine learning models (and their versions) in the Agent Platform Model Registry. Don't use for model training, model deployment to endpoints, or managing non-Agent Platform models.
Manages and orchestrates prompts in Agent Platform. Use when you need to create, list, retrieve, version, or delete managed prompts in Agent Platform. Don't use for model training, model deployment to endpoints, or managing non-Agent Platform prompts.
Related devops skillsscan passed
Post-deploy canary monitoring. (gstack)
Operational controls for long-lived or cloud-hosted agent systems — runtime lifecycle (start, pause, stop, restart), observability (logs, metrics, traces), least-privilege safety scopes and kill switches, and rollout/rollback change management with audit logs and success/cost metrics. Use when runni
Build or maintain Cloudflare Sandbox apps on the stable @cloudflare/sandbox package. Use sandbox-next for preview apps and sandbox-migrate-to-next for stable-to-preview migrations.
Deploy tRPC on AWS Lambda with awsLambdaRequestHandler() from @trpc/server/adapters/aws-lambda for API Gateway v1 (REST, APIGatewayProxyEvent) and v2 (HTTP, APIGatewayProxyEventV2), and Lambda Function URLs. Enable response streaming with awsLambdaStreamingRequestHandler() wrapped in awslambda.strea
Prepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
Deploys and configures classic Firebase Hosting for static websites, single-page apps (SPAs), and microservices. Use when deploying static sites/SPAs, setting up custom domains, configuring firebase.json hosting settings (redirects, rewrites, headers, multi-site), or managing preview channels. Don't