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.

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.

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. The e2-medium type provides 2 vCPUs and 4 GB 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 minutes because is provisioning significant infrastructure on your behalf. Here's what happens behind the scenes:

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 below 1 node per zone, preventing the cluster from scaling down to zero.
• --max-nodes=4: Sets the upper bound. The autoscaler will never provision more than 4 nodes 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.

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.

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 Kubernetes Ingress resources 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 Kubernetes NetworkPolicy enforcement 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.

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 is 100 GB. Reducing this to 50 GB 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-standard uses a standard (magnetic) persistent disk, which is the most cost-effective option. pd-ssd uses a solid-state disk for higher I/O throughput, which is better suited for production workloads with demanding storage requirements.

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 kubectl sends 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 kubectl uses to verify it's talking to the real cluster and not a malicious imposter.

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:

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.

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.