Scope inspiration:

gke_kubectl.sh, gke_kube_creds.sh.

This series follows the repo’s GCP inventory flow so every step builds a repeatable, audit-friendly picture of your environment. Part 5 is the operational guardrail: safe

kubectl

workflows that keep you from accidentally targeting the wrong cluster.

---

What this script does (walkthrough)

gke_kubectl.sh

wraps kubectl in an isolated context so your command always targets the intended GKE cluster.

1. Resolve GKE context or cluster coordinates (

   CLOUDSDK_CORE_PROJECT

   ,

   CLOUDSDK_COMPUTE_REGION

   ,

   CLOUDSDK_CONTAINER_CLUSTER

   ).
2. Create an isolated kubeconfig so the script doesn’t mutate your global context.
3. Reuse an existing context when it already exists to reduce noise and speed execution.
4. Fallback to

   gcloud container clusters get-credentials

   only when required.

---

Operational caveats and gotchas

• The script is built to avoid cross-environment mishaps. If you rely on your global kubeconfig, use this wrapper instead to prevent context bleed.
• You may need to explicitly set CLOUDSDK_ variables* if your gcloud config does not already have them or points to the wrong project/region.
• For repeated usage, consider hardcoding the context or cluster coordinates in a local copy as suggested in the script comments.

---

Example command usage

# Run a safe command against a fixed GKE cluster
CLOUDSDK_CORE_PROJECT=my-project \
CLOUDSDK_COMPUTE_REGION=us-central1 \
CLOUDSDK_CONTAINER_CLUSTER=my-cluster \
  gcp/gke_kubectl.sh get nodes

# If you already populated contexts for all clusters
# (use gke_kube_creds.sh to prefetch credentials)
GKE_CONTEXT=gke_my-project_us-central1_my-cluster \
  gcp/gke_kubectl.sh get ns