Creating Your First GKE Cluster
Introduction: Building Your First GKE Cluster
In the previous lesson, you prepared your environment by installing the gcloud and kubectl command-line tools. Now, you'll use those tools to create your first GKE cluster. This is the foundational step for the rest of the course, as you need a running cluster before you can deploy any applications.
By the end of this lesson, you'll have a fully functional, two-node Kubernetes cluster running on Google Cloud. You will create the cluster using a single gcloud command with command-line flags, connect to it with kubectl, verify its status, and finally, learn how to delete it to avoid extra costs. We use command-line flags because they provide a straightforward, imperative way to specify exactly what you want, making it easy to understand and reproduce your cluster configuration.
Enabling Required Google Cloud APIs
Before you can create a GKE cluster, you need to enable the Google Kubernetes Engine API in your Google Cloud project. Google Cloud organizes its services as APIs that must be explicitly enabled before use. This is a one-time setup step for each project.
Run the following command to enable the Container API, which is the service that powers GKE:
This command tells Google Cloud to activate the Kubernetes Engine service for your current project. The output will confirm that the API is being enabled:
If the API is already enabled, you'll see a message indicating that no changes were necessary. This command is safe to run multiple times. Once the API is enabled, you're ready to create your first cluster.
Creating the Cluster with gcloud
Now let's create your first GKE cluster. The gcloud container clusters create command is the primary tool for creating clusters, and you control the cluster's configuration by passing flags to this command. Here's the command you'll use:
Let's break down what each flag does:
my-gke-cluster: This is the name of your cluster. You'll use this name to reference the cluster in future commands.--num-nodes=2: This creates a cluster with two worker nodes. Each node is a virtual machine that runs your containerized applications.--region=us-central1: This specifies the Google Cloud region where your cluster will run. Regional clusters distribute nodes across multiple zones within the region for high availability.--machine-type=e2-medium: This sets the size of the virtual machines used for your worker nodes. Thee2-mediumtype provides2vCPUs and4GB of memory, which is cost-effective for learning.--release-channel=regular: This enrolls your cluster in the "regular" release channel, which provides a balance between stability and access to new features. Google automatically manages Kubernetes version upgrades for clusters in release channels.
The creation process takes 5 to 10 minutes because gcloud is provisioning significant infrastructure on your behalf. Here's what happens behind the scenes:
- GKE control plane: Google creates and manages the highly available Kubernetes control plane. This is the "brain" of your cluster, and it's fully managed by Google — you don't see or pay for the control plane nodes directly.
- VPC and networking: Google automatically configures networking, including a virtual private cloud (VPC), subnets, and firewall rules that allow your nodes to communicate securely.
- Worker nodes: Google creates Compute Engine virtual machine instances in multiple zones within your chosen region, configures them as Kubernetes nodes, and connects them to the control plane.
- Node pools: Your nodes are organized into a node pool, which is a group of nodes with the same configuration. This makes it easy to manage and scale groups of nodes together.
This automation is the primary benefit of using GKE, as it handles dozens of complex steps that would be tedious and error-prone to perform manually. The output you'll see looks something like this:
This output shows the cluster being created and health-checked. The final table displays key information about your cluster, including its name, location, Kubernetes version, and the number of nodes. Note that even though you specified --num-nodes=2, you might see 6 nodes in the output — this is because regional clusters create the specified number of nodes in each of three zones for high availability (2 nodes × 3 zones = 6 total nodes).
While you're waiting for the cluster to be created, you can open the Google Cloud Console and navigate to the Kubernetes Engine section to watch your cluster appear and become ready.
Enabling Autoscaling on a Node Pool
The cluster you created in the previous section has a fixed number of nodes. In production environments, traffic often varies throughout the day, so you may want your cluster to automatically add nodes during peak load and remove them when demand drops. GKE supports this through the cluster autoscaler, which you enable when creating the cluster.
To create a cluster with autoscaling enabled on its node pool, add three flags to the gcloud container clusters create command:
The three new flags work together:
--enable-autoscaling: Activates the cluster autoscaler for the node pool. Without this flag, the other two flags have no effect.--min-nodes=1: Sets the lower bound. The autoscaler will never scale the node pool below1node per zone, preventing the cluster from scaling down to zero.--max-nodes=4: Sets the upper bound. The autoscaler will never provision more than4nodes per zone, which protects you from runaway costs during unexpected traffic spikes.
The --num-nodes=2 flag still controls the initial size of the node pool when the cluster is first created. After that, the autoscaler takes over and adjusts the count within the min/max boundaries based on the resource requests of your running workloads.
Adding Labels to Your Cluster
You can attach labels to a cluster to help organize resources, track costs, and apply access controls. Labels are key-value pairs you specify with the --labels flag:
The --labels flag accepts a comma-separated list of key=value pairs. In this example, the cluster is tagged with an environment of dev and a team of backend. Labels are purely metadata — they do not affect how the cluster behaves — but they are invaluable for filtering resources in the Cloud Console and allocating costs across teams in billing reports.
Enabling Add-ons
Add-ons are optional cluster components that extend Kubernetes with additional functionality. You specify them with the --addons flag, passing a comma-separated list of add-on names:
Common add-ons include:
HttpLoadBalancing: Enables GKE's integration with Google Cloud Load Balancing, which is required for KubernetesIngressresources to provision external load balancers automatically.HorizontalPodAutoscaling: Enables the Horizontal Pod Autoscaler, which automatically adjusts the number of pod replicas based on CPU or memory utilization.NetworkPolicy: Enables KubernetesNetworkPolicyenforcement so you can control which pods are allowed to communicate with each other.
Some add-ons are enabled by default (such as HttpLoadBalancing and HorizontalPodAutoscaling), so you only need to specify this flag when you want to enable non-default add-ons or explicitly disable a default one.
Configuring Node Pool Disk Options
By default, each node in your cluster is provisioned with a standard persistent disk. You can customize the disk size and type for the node pool using two flags:
--disk-size: The size of the boot disk on each node, in gigabytes. The default is100GB. Reducing this to50GB lowers storage costs for development clusters where you don't need large local disk capacity.--disk-type: The type of persistent disk to use.pd-standarduses a standard (magnetic) persistent disk, which is the most cost-effective option.pd-ssduses a solid-state disk for higher I/O throughput, which is better suited for production workloads with demanding storage requirements.
Connecting kubectl to Your Cluster
Once your cluster is created, you need to configure kubectl so it knows how to connect to it. kubectl uses a configuration file (called kubeconfig), typically located at ~/.kube/config, that contains connection details for your clusters.
When gcloud creates your cluster, it can automatically update your kubeconfig file. However, if you're working on a different machine or if the kubeconfig wasn't updated for some reason, you can manually update it using this command:
This command retrieves the connection information for your cluster from Google Cloud and adds it to your kubeconfig file. The "context" it creates is a combination of cluster, user, and namespace information that tells kubectl where to send commands.
You'll see output confirming the update:
The kubeconfig file contains several key pieces of information to enable a secure connection:
- API server endpoint: The URL where
kubectlsends requests to the Kubernetes control plane. - Authentication credentials: Information that proves you are authorized to access the cluster. For GKE, this uses your Google Cloud credentials and the Google Cloud authentication plugin.
- Certificate authority data: The certificate
kubectluses to verify it's talking to the real cluster and not a malicious imposter.
All of this information is managed automatically by gcloud, so you don't need to worry about the details. The authentication happens seamlessly using your existing Google Cloud credentials.
Verifying Everything Works
Now that your cluster is created and kubectl is configured, let's verify everything is working correctly. The first thing to check is whether your worker nodes are running and ready. Run the following command:
This command asks the Kubernetes control plane to list all the nodes in your cluster. You should see output similar to this:
This output shows you have 6 nodes (2 per zone across 3 zones), all with a status of "Ready," which means they're healthy and ready to run containers. The node names include the cluster name, node pool name, zone identifier, and a unique ID. If you see all nodes with "Ready" status, your cluster is working correctly.
Next, let's check the namespaces in your cluster. Namespaces are a way to divide cluster resources between multiple users or applications. Run this command:
You should see the default namespaces that Kubernetes creates automatically, each with a specific purpose:
Let's understand what each namespace is for:
default: The namespace where your applications will run if you don't specify another one.kube-system: Contains Kubernetes system components like the DNS service, metrics server, and other critical add-ons that GKE installs automatically.kube-public: Readable by all users and typically used for cluster information that should be publicly accessible.kube-node-lease: Used for node heartbeat data that helps the control plane detect node failures quickly.
If you see these namespaces and your nodes are ready, congratulations! You have a fully functional, production-grade Kubernetes cluster running on Google Cloud.
Cleaning Up Your Cluster
When you're done experimenting, it's important to delete your cluster to avoid unnecessary Google Cloud charges for the worker nodes. Deleting a GKE cluster is straightforward. Run the following command:
This command tells gcloud to delete the cluster and all associated resources. You'll be prompted to confirm the deletion:
Type Y and press Enter to confirm. The deletion process takes about 5 to 10 minutes as Google Cloud carefully tears down all the resources.
The output will show the progress of deletion:
Using gcloud for deletion is important because it ensures a clean teardown of all cluster resources. If you were to delete resources manually from the Google Cloud Console, you might leave behind orphaned resources like persistent disks or load balancers that would continue to incur charges.
After deletion, your kubeconfig file will still contain the cluster's context, but it will no longer work since the cluster doesn't exist. You can safely ignore this or manually remove the context if you prefer a clean kubeconfig file.
Summary: What You've Accomplished
In this lesson, you created your first Google Kubernetes Engine cluster from scratch. You enabled the required Google Cloud APIs, then used the gcloud container clusters create command with specific flags to provision all the necessary infrastructure automatically. You configured kubectl to communicate with your new cluster using gcloud container clusters get-credentials, verified that the nodes were ready, and inspected the default namespaces. Finally, you learned the command to safely delete the cluster and all its resources to prevent unwanted costs.
The cluster you built is not just a toy — it's a real, production-grade Kubernetes cluster with the same architecture used to run large-scale applications. The skills you've developed here are directly applicable to managing production workloads.
Before practice: The commands you've learned to create and delete clusters take 5-10 minutes to complete in a real Google Cloud project. However, the upcoming practice exercises use an emulated terminal that provides instant feedback. This allows you to focus on understanding the different flags and options available with gcloud container clusters create without the long wait times.
In the next lesson, you'll build on this foundation by deploying your first containerized application to the cluster.
