How to Deploy a Kubernetes Cluster Using the gcloud Command

If your infrastructure runs on Google Cloud Platform (GCP) and you prefer working from the command line, the Google Cloud SDK gives you everything you need to manage Kubernetes clusters without touching the GCP console. The SDK’s gcloud command lets you create, configure, inspect, and tear down Google Kubernetes Engine (GKE) clusters in seconds.

This guide walks through the essential steps: understanding key GKE concepts, deploying your first cluster, and safely deleting it when you’re done.

Prerequisites

Before you start, make sure you have the following in place:

• A Google Cloud Platform account with billing enabled and the Kubernetes Engine API activated for your project.
• The Google Cloud SDK installed and initialised on a Linux machine (gcloud init or gcloud auth login completed).
• A GCP project set as the active project (gcloud config set project PROJECT_ID).

Key Concepts to Know Before You Begin

Compute Zones and Regions

GCP infrastructure is divided into regions (broad geographic areas) and zones (isolated locations within a region). For example, the region us-central1 contains zones such as us-central1-a, us-central1-b, us-central1-c, and us-central1-f. You specify a zone when creating a zonal cluster. The full list of available zones is maintained in the GCP regions and zones documentation.

Cluster Types

• Zonal cluster — Runs a single control-plane replica and worker nodes in one compute zone. Good for non-production workloads where simplicity matters more than availability.
• Regional cluster — Spreads three control-plane replicas across three zones and runs worker nodes across multiple zones. Recommended for production workloads.
• Private cluster — A zonal or regional cluster whose control-plane and nodes are not reachable from the public internet. Suitable for security-sensitive environments.
• Alpha cluster — An experimental zonal or regional cluster with Kubernetes alpha features enabled. Not intended for production use.

Deploying Your First Cluster

The minimal command to create a standard zonal GKE cluster is:

gcloud container clusters create NAME --zone us-central1-a

Replace NAME with a lowercase, human-readable identifier for your cluster (e.g., my-first-cluster). Cluster names must be unique within a project and zone.

GKE provisions the control plane and a default node pool. You may see informational warnings during provisioning — these are normal. When the command completes, the output displays cluster details including the master IP address and machine type.

Useful Options for cluster create

The gcloud container clusters create command accepts a large number of flags. Some of the most commonly used are:

Flag	Purpose
--num-nodes	Number of nodes in each zone of the default node pool (default: 3).
--machine-type	Compute Engine machine type for nodes (e.g., e2-medium).
--disk-size	Boot disk size in GB for each node.
--enable-autoscaling	Enables cluster autoscaler for the default node pool.
--min-nodes / --max-nodes	Minimum and maximum node count when autoscaling is enabled.
--node-locations	Comma-separated list of zones in which nodes are created.
--enable-private-nodes	Creates a private cluster with no public node IP addresses.
--cluster-version	Kubernetes version to use for the cluster control plane and nodes.

For the complete reference, run gcloud container clusters create --help or consult the official gcloud reference documentation.

Connecting kubectl to Your New Cluster

Once the cluster is running, configure kubectl to communicate with it by fetching the cluster credentials:

gcloud container clusters get-credentials NAME --zone us-central1-aCode language: JavaScript (javascript)

This command updates your local ~/.kube/config file and sets the new cluster as the active context. You can then verify connectivity with:

kubectl get nodesCode language: JavaScript (javascript)

Listing Your Clusters

To see all clusters in your current project and their status, run:

gcloud container clusters listCode language: PHP (php)

The output shows each cluster’s name, location, master version, and current status. This is useful when you need to find a cluster name before deleting it.

Deleting a Cluster

When a cluster is no longer needed — for example, after a test — delete it to stop incurring costs:

gcloud container clusters delete NAME --zone ZONECode language: JavaScript (javascript)

Replace NAME with the cluster name and ZONE with the zone where it was created (e.g., us-central1-a). GKE will prompt you to confirm the deletion before proceeding.

To skip the interactive prompt in scripts or CI pipelines, add the --quiet flag:

gcloud container clusters delete NAME --zone ZONE --quietCode language: JavaScript (javascript)

Deletion takes several minutes. Once complete, all cluster resources — nodes, load balancers provisioned by Services, and the control plane — are removed from your project.

Next Steps

With a running cluster and kubectl configured, you can begin deploying workloads using standard Kubernetes manifests or Helm charts. Consider exploring:

• Node pools — Add specialised node pools (GPU nodes, high-memory nodes) with gcloud container node-pools create.
• Cluster autoscaler — Use --enable-autoscaling at creation time to automatically scale node counts with demand.
• Workload Identity — Bind Kubernetes service accounts to GCP IAM service accounts for secure, keyless authentication to GCP APIs.
• GKE Autopilot — A fully managed cluster mode where Google manages the node infrastructure, billing per Pod rather than per node.

Original article based on reporting from TechRepublic (techrepublic.com).