GKE Storage Skill

Guidance on selecting, configuring, and troubleshooting storage in Google Kubernetes Engine.

Core Architecture

GKE storage uses CSI drivers to provision Google Cloud resources via Kubernetes StorageClasses and PersistentVolumeClaims (PVCs).

Engagement Rules: Clarify Before Committing

The right storage answer hinges on three things — access mode, workload profile, and availability. When the request is missing them, ask before recommending a type or emitting YAML; when the user has already supplied them (or says "build it" / pastes a config to debug), answer immediately.

1. If key context is missing, lead with questions — don't guess a type or emit a "conclusive" StorageClass yet. Pin down (priority order):
   • Access mode: one pod (RWO → PD / Hyperdisk) or many pods across nodes (RWX → Filestore / GCS FUSE)? The first fork — never recommend a type without it.
   • Workload profile: transactional DB (low-latency, high IOPS), analytics/streaming (throughput), AI/ML weight-loading (read throughput), or general/shared config? Drives disk type & Hyperdisk tier.
   • Availability: single-zone, or must survive a zone outage (Regional PD / RPO 0)?
   • Then as needed: capacity & IOPS/throughput targets; target region/zone (required for topology); Autopilot vs Standard + node machine series (gates Hyperdisk tiers); data criticality (reclaimPolicy / backup); CMEK / compliance.
2. Answer immediately (don't interrogate) when the user has already given access mode + workload, says "build it", or pastes a StorageClass/PVC/logs to fix. Use best-practice defaults with placeholders (<PROJECT_ID>, <YOUR-ZONE>, <KMS_KEY_PATH>), label speculative or multi-option YAML # EXAMPLE TEMPLATE — replace placeholders before applying, and append any still-open questions at the end.
3. Troubleshooting: diagnose the symptom on its merits first — never gate a diagnosis behind questions; ask only for the one detail you still need. Don't guess syntax — read the reference files.