GKE Alpha Features Enabled: Why Alpha Clusters Don't Belong in Production

Alpha clusters in Google Kubernetes Engine exist for a specific reason: they let you kick the tires on bleeding-edge Kubernetes features before they graduate to beta or stable. That is genuinely useful for experimentation. It is also a trap if one of those clusters quietly ends up serving real traffic, because Google designed alpha clusters to be disposable and short-lived.

The GKE Alpha Features Enabled check (gke_alphaenabled) looks at each cluster in your GCP project and reports any that were created with Kubernetes alpha features turned on. If you see this finding against a production or staging cluster, you have a ticking clock and a stability risk on your hands.

---

What this check detects

When you create a GKE cluster, you can pass a flag that enables all Kubernetes alpha APIs and features at once. Internally this sets the cluster's enableKubernetesAlpha field to true. The check inspects that field and flags any cluster where it is set.

An alpha cluster differs from a normal cluster in a few important ways:

• Every alpha API and feature gate is switched on, including ones that are experimental and may change or break between releases.
• The cluster has a hard 30-day lifespan. Google deletes it automatically when the clock runs out.
• It cannot be upgraded. You get whatever version it launched with until it expires.
• There is no production SLA, and node auto-upgrade and auto-repair are unavailable.

---

Why it matters

The headline problem is the 30-day expiry. If an alpha cluster is running anything you care about, it will be deleted out from under you with no recovery path. Teams that adopt an alpha cluster "just to test something" and then forget about it have watched workloads vanish overnight. Restoring from that situation means rebuilding the cluster, reapplying manifests, and recovering persistent data, all under pressure.

Beyond the deadline, there are real reliability and security concerns:

• Unstable APIs. Alpha features can be removed or change shape without notice. Code that depends on them can break on the next minor Kubernetes release, and on an alpha cluster you have no safe upgrade path to react.
• No patching. Because alpha clusters cannot be upgraded, you are stuck on the launch version. If a CVE lands in the control plane or node image, you cannot patch in place. You have to rebuild.
• Expanded attack surface. Every alpha feature gate is on, including ones that loosen defaults or expose experimental admission and scheduling behavior that has not been hardened. Some alpha features change how workloads are isolated or how privileges are granted.
• No support. With no SLA, an outage on an alpha cluster is yours to solve alone.

---

How to confirm the finding

You can verify which clusters have alpha enabled with the gcloud CLI. List your clusters and check the alpha field directly:

gcloud container clusters list \
  --format="table(name,location,enableKubernetesAlpha)"

For a single cluster, describe it and grep for the field:

gcloud container clusters describe my-cluster \
  --zone us-central1-a \
  --format="value(enableKubernetesAlpha)"

A return value of True confirms the cluster is an alpha cluster. You can also spot the expiry date, which tells you how long you have before Google deletes it:

gcloud container clusters describe my-cluster \
  --zone us-central1-a \
  --format="value(expireTime)"

---

How to fix it

Since you cannot toggle alpha off, remediation is a migration: stand up a fresh standard cluster, move workloads over, then decommission the alpha cluster.

Step 1: Create a replacement standard cluster

Create a new cluster without the alpha flag. This example mirrors common production defaults:

gcloud container clusters create my-cluster-prod \
  --zone us-central1-a \
  --num-nodes 3 \
  --enable-autoupgrade \
  --enable-autorepair \
  --release-channel regular

Using a release channel gives you managed, automatic version upgrades, which is the opposite of the frozen-version situation an alpha cluster leaves you in.

Step 2: Export and reapply your workloads

Point kubectl at the old cluster and export the resources you need. Be selective rather than dumping everything, since cluster-scoped and auto-generated objects will not transfer cleanly:

# Connect to the old alpha cluster
gcloud container clusters get-credentials my-cluster --zone us-central1-a

# Export workloads from a namespace
kubectl get deployments,services,configmaps,secrets,ingress \
  -n my-app -o yaml > my-app-export.yaml

Then switch context to the new cluster and apply:

gcloud container clusters get-credentials my-cluster-prod --zone us-central1-a
kubectl create namespace my-app
kubectl apply -f my-app-export.yaml

Step 3: Migrate persistent data

Stateful workloads need their data moved before you delete the old cluster. For Persistent Volumes backed by Compute Engine disks, snapshot the disk and recreate the PV against the snapshot in the new cluster, or use a backup tool such as Velero to capture volumes and namespaced resources together.

Step 4: Delete the alpha cluster

Once traffic is cut over and you have confirmed the new cluster is healthy, remove the alpha cluster.

gcloud container clusters delete my-cluster --zone us-central1-a

---

How to prevent it from happening again

The most reliable prevention is to make it hard to create an alpha cluster in the first place, and to catch any that slip through automatically.

Block alpha clusters with Organization Policy

GCP does not have a single canned constraint named "no alpha clusters," but you can enforce it with a custom Organization Policy that rejects clusters where enableKubernetesAlpha is true:

name: organizations/123456789/customConstraints/custom.denyGkeAlpha
resourceTypes:
  - container.googleapis.com/Cluster
methodTypes:
  - CREATE
condition: "resource.enableKubernetesAlpha == true"
actionType: DENY
displayName: Deny GKE alpha clusters
description: Blocks creation of GKE clusters with Kubernetes alpha features enabled.

Apply it with:

gcloud org-policies set-custom-constraint constraint.yaml
gcloud org-policies set-policy policy.yaml

Gate it in CI/CD with policy-as-code

If you provision GKE through Terraform, add a check that fails the pipeline when alpha is enabled. With Conftest and an OPA policy:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_container_cluster"
  resource.change.after.enable_kubernetes_alpha == true
  msg := sprintf("Cluster '%s' has Kubernetes alpha enabled, which is not allowed", [resource.address])
}

Run it against your plan output before apply:

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
conftest test tfplan.json

---

Best practices

• Keep alpha clusters in a dedicated sandbox project. If you genuinely need to test alpha features, isolate them in a project that has no path to production data or networks, and tag them clearly so nobody mistakes them for real infrastructure.
• Set a reminder, not a surprise. An alpha cluster's 30-day expiry should be tracked deliberately. Schedule its teardown rather than letting Google's auto-delete catch you off guard.
• Use release channels for everything you keep. The regular or stable channel gives you managed upgrades and security patches, which is the opposite of the frozen, unsupported state alpha clusters live in.
• Prefer feature flags over whole-cluster alpha. If you need one specific capability, check whether it is available as a beta feature you can enable selectively instead of flipping every alpha gate at once.
• Review GKE configuration in code review. The enable_kubernetes_alpha argument in Terraform should never make it into a merged module without a very deliberate, documented reason.

Alpha clusters are a fine tool for what they are built for: throwaway experimentation with the newest Kubernetes features. The moment one outlives its experiment, it becomes a liability with a deletion timer. Catch them early, keep them out of production, and enforce that boundary with policy so you are never the team explaining why a cluster disappeared overnight.