GKE Workload Reliability Guide
Reduce GKE workload disruption with high-availability configuration.
The skill names read and apply operations on Kubernetes resources, with no evidence of credential theft, covert exfiltration, or malicious behavior. However, apply_k8s_manifest can create external changes, while user confirmation, permission scope, data-flow disclosure, sensitive-data handling, and rollback are not specified, so points are deducted.
The workflows cover cluster checks, PDBs, probes, graceful termination, topology spreading, and replicas, making the happy path understandable. The table has visibly corrupted formatting, MCP/gcloud/kubectl availability is not documented, and abnormal-input handling, failure feedback, verification steps, and consistency checks are absent; under static calibration the score remains below 10.
Trigger scenarios and the non-fit boundary are relatively clear, and the skill addresses common GKE reliability configurations. Inputs, outputs, and invocation conditions are not formalized; workload and architecture boundaries are thin, Chinese-language support is unspecified, and examples assume particular regions and production conditions, so points are deducted.
The SKILL.md has clear sections, metadata, workflows, examples, and some limitation guidance. The README supplies installation instructions, the repository provides an Apache-2.0 license, and it states that the repository is under active development. The skill lacks its own version, changelog, explicit maintenance owner, dependency-installation notes, FAQ, and troubleshooting guidance, so points are deducted.
The material can directly support a partial GKE reliability checklist and YAML drafts, providing useful practical value. Several recommendations use overly absolute language such as applying to every production workload, and compatibility with the specific application, GKE version, or existing resources is not validated; no complete end-to-end output or execution confirmation is provided, so under static calibration the score remains below 7.
Concrete commands, resource types, and YAML examples provide limited auditability. The supplied material contains no skill-specific test suite, CI execution evidence, result samples, or external technical sources. The official publisher supports governance attribution only and cannot substitute for reproducible evidence, so points are deducted.
- Before using apply_k8s_manifest, obtain confirmation of the target cluster, namespace, resource scope, and exact changes, and prepare a verifiable rollback plan.
- Validate PDB, probe, topology, and replica recommendations against the application protocol, capacity, regional layout, and GKE/Kubernetes version; they should not be treated as universal production defaults.
- Failure cases, permission requirements, dependency setup, post-change verification, mainland-China reachability, and Chinese-language support are not documented.
What does this skill do, and when should you use it?
This skill covers high-availability and reliability configuration for GKE clusters and workloads. It addresses PodDisruptionBudgets, liveness, readiness and startup probes, graceful shutdown, topology spread constraints, and replica guidance. It also defines reliability defaults such as regional clusters, automatic repair, automatic upgrades, and SURGE upgrades. It does not cover disaster recovery or full cluster backups; that scope belongs to gke-backup-dr.
It uses the MCP get_cluster tool to inspect cluster location and node placement, with gcloud as a fallback. It uses get_k8s_resource and describe_k8s_resource to inspect PDBs, Deployments, and health probes, with kubectl fallback commands. It supplies Kubernetes YAML examples for PDBs, probes, graceful shutdown, and topology spread constraints, and lists minimum replica guidance by workload type. The SKILL.md also names apply_k8s_manifest and list_k8s_events, but provides no concrete examples for those calls.
- A GKE production administrator needs to verify whether the control plane is regional and nodes span multiple zones.
- A platform engineer needs PDB guidance for a production Deployment with at least two replicas during node upgrades or autoscaler scale-down.
- An application team needs to add liveness, readiness, and startup probes with explicit timeout settings.
- An SRE needs zone and node topology constraints to reduce the impact of zone or node failures.
- A service team needs SIGTERM handling, termination grace periods, and a preStop hook to allow load-balancer deregistration.
What are this skill's strengths and limitations?
- Covers several important reliability controls for production workloads.
- Includes directly reusable YAML examples for PDBs, probes, graceful shutdown, and topology constraints.
- Provides both MCP-first and gcloud/kubectl fallback paths.
- Clearly excludes disaster recovery and full cluster backup from its scope.
- It is primarily a reference guide and does not include a complete automation script.
- MCP service setup, cluster credentials, and permission configuration are undocumented.
- No test suite or platform validation evidence is provided.
- Probe settings, replica counts, and topology rules still require application-specific adjustment.
How do you install this skill?
Run npx skills add google/skills, then select skills/cloud/gke-reliability from the repository. The source does not document the exact installation directory or client configuration. The repository is licensed under Apache-2.0.
How do you use this skill?
In an Agent Skills-compatible client with the skill installed, make a concrete request such as: “Check whether my GKE cluster has regional high availability and recommend PDBs, health probes, and topology spread constraints for a production Deployment.” Prefer the MCP tools named in SKILL.md; when MCP is unavailable, use the documented gcloud or kubectl fallback commands. The source does not document credential setup, MCP service configuration, or a complete execution flow.
How does this skill compare with similar options?
Unlike gke-backup-dr, this skill focuses on workload high availability, probes, PDBs, and topology distribution rather than disaster recovery or full cluster backups. It references gke-upgrades for the dedicated upgrade workflow, while recommending low-traffic maintenance windows as a reliability practice.