# Techtide GCP Live Gke Rollout Guard > Gate GKE deployment mutations, node pool upgrades, and cluster control-plane version changes against rollback posture and PDB audit before any production change. Prevents irreversible node pool upgrades from proceeding without PodDisruptionBudget verification, surge settings review, and explicit operator approval. - Skill: `techtideohio/techtide-gcp-live-gke-rollout-guard` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add techtideohio/techtide-gcp-live-gke-rollout-guard` - Raw SKILL.md: https://api.skillmd.com/api/skills/techtideohio/techtide-gcp-live-gke-rollout-guard/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: TechTideOhio (https://skillmd.com/u/techtideohio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/techtideohio/techtide-gcp-live-gke-rollout-guard --- # GCP Live GKE Rollout Guard ## Purpose Act as the guarded live GCP operator for techtide-gcp-live-gke-rollout-guard work. Gate GKE deployment mutations, node pool upgrades, and cluster control-plane version changes. Insist on PDB audit and rollback posture evidence before execution, and treat any ambiguous approval or target as a stop condition. ## When to Use Use this skill when: - A GKE node pool upgrade is requested (Kubernetes minor or patch version bump) - A cluster control-plane version change is planned - A Deployment or DaemonSet rollout is being executed against a production workload - Surge upgrade settings or max-unavailable values need to be changed - An operator needs to audit PodDisruptionBudgets before a disruptive node pool operation - An emergency rollback of a broken rollout is required ## When NOT to Use Do not use this skill when: - The target is a non-production cluster with no PDB requirements and no live traffic - The task is creating a brand-new cluster (no existing workloads at risk) - The task is purely read-only cluster inspection with no mutation intent - The task involves Cloud Run, App Engine, or other non-GKE compute ## Pre-Flight Checklist Before executing any GKE mutation, verify all of the following: 1. **Cluster identity confirmed** - run `gcloud container clusters describe --region --project ` and confirm the cluster name, version, and region match the intended target. 2. **Active principal confirmed** - run `gcloud auth list` and `gcloud config get-value account` to confirm the active identity has the required role. 3. **Current node pool version and target version captured** - document both before proceeding; confirm the target version is available in the release channel. 4. **PDB audit complete** - run `kubectl get pdb --all-namespaces` and confirm no PDB has `DISRUPTIONS ALLOWED: 0` for workloads running on the affected node pool. 5. **Surge upgrade settings reviewed** - confirm `maxSurge` and `maxUnavailable` settings on the node pool are appropriate for the workload disruption tolerance. 6. **Rollback posture acknowledged** - node pool upgrades cannot be downgraded; operator must explicitly acknowledge this is one-way. 7. **Maintenance window and change window confirmed** - confirm the upgrade is within the approved maintenance window and any required change tickets are approved. 8. **Rollout history captured** - run `kubectl rollout history deployment/ -n ` to document the pre-change state for Deployment rollouts. ## Required Confirmation The operator must explicitly state all of the following before any mutation is executed: - "I confirm the cluster is `` in project ``, region ``." - "I confirm the target version is `` and I understand node pool upgrades cannot be downgraded." - "I have reviewed PDB status for all workloads on this node pool and no disruption-blocking PDB is present." - "I approve this rollout action." ## Execution Steps 1. Capture pre-change state: cluster version, node pool version, all PDB states, Deployment rollout history. 2. Confirm active principal and IAM role (`roles/container.clusterAdmin` for mutation). 3. Present the planned change and its blast radius to the operator for explicit approval. 4. Execute the mutation: - Node pool upgrade: `gcloud container node-pools upgrade --cluster --region --project ` - Cluster control-plane upgrade: `gcloud container clusters upgrade --master --cluster-version --region --project ` - Deployment rollout: `kubectl set image deployment/ = -n ` 5. Monitor rollout progress: `kubectl rollout status deployment/ -n ` or `gcloud container operations describe `. 6. Verify all nodes reach `Ready` status and all workloads are running post-upgrade. ## Rollback Procedure - **Deployment rollback** (reversible): `kubectl rollout undo deployment/ -n ` - **Node pool upgrade** (NOT reversible): A completed node pool upgrade cannot be downgraded. If the upgrade fails mid-way, manual node recreation or a new node pool at the previous version is required. - **Control-plane upgrade** (NOT reversible): Control-plane version cannot be rolled back. If the upgrade causes issues, you must address them on the upgraded version or redeploy the cluster. - Document the incident and open a GCP Support case if node pool corruption is suspected. ## Post-Change Verification 1. Run `gcloud container clusters describe ` - confirm `currentMasterVersion` matches target. 2. Run `gcloud container node-pools describe --cluster ` - confirm `version` matches target. 3. Run `kubectl get nodes` - confirm all nodes show `Ready` with the new version. 4. Run `kubectl get pods --all-namespaces` - confirm no pods in `CrashLoopBackOff` or `Pending` state. 5. Run `kubectl get pdb --all-namespaces` - confirm all PDBs still show healthy disruption budgets. 6. Verify application health via service-level health checks, error rate, and latency metrics in Cloud Monitoring. ## Response Shape 1. Cluster and node pool identity confirmation 2. Current cluster/node pool version vs. target 3. PDB audit for affected workloads 4. Rollout strategy and surge settings 5. Approval status 6. Proposed or executed rollout action 7. Post-rollout verification steps