Skip to main content
Google Cloud Platform (GCP)
CHAPTER 09

Google Kubernetes Engine (GKE)

Updated: May 15, 2026
30 min read

# CHAPTER 9

Google Kubernetes Engine (GKE)

1. Introduction

Managing 50 Virtual Machines by hand is an operational nightmare. The modern cloud has moved past raw VMs and embraced Container Orchestration. Google invented Kubernetes to manage their own massive global infrastructure, and they offer it to the public as Google Kubernetes Engine (GKE). GKE is universally recognized as the most advanced, polished, and powerful managed Kubernetes service in the world. In this chapter, we will transition from VMs to Containers, deploy a GKE cluster, and orchestrate our first application.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define Containerization and Container Orchestration.
  • Understand the benefits of a Managed Kubernetes Service.
  • Differentiate between GKE Standard and GKE Autopilot.
  • Create a GKE cluster via the Google Cloud Console.
  • Deploy a scalable application into the cluster.

3. Beginner-Friendly Explanation

Imagine running a delivery company.
  • Virtual Machines (The Old Way): You buy a massive delivery truck. Even if you only need to deliver a single shoebox, you have to drive the whole truck. It wastes gas and space.
  • Containers (Docker): You package the shoebox perfectly. It runs exactly the same anywhere.
  • Kubernetes (GKE): The ultimate logistics manager. You tell the manager: "I need 50 shoeboxes delivered constantly." The manager (GKE) automatically buys the exact number of trucks needed, loads the boxes perfectly, and if a truck breaks down on the highway, the manager instantly buys a new truck and moves the boxes for you automatically.

4. Why Use GKE? (The Managed Advantage)

A Kubernetes cluster has two parts: The Brain (Control Plane/Master Nodes) and The Muscle (Worker Nodes). If you build Kubernetes yourself, you have to manage the Brain. It is incredibly complex to keep it online. With GKE, Google manages the Brain for you. They handle the backups, the security patches, and the high-availability of the Master Nodes invisibly. You only manage the Worker Nodes (the actual servers running your apps).

5. GKE Standard vs. GKE Autopilot

GCP offers two flavors of Kubernetes:
  1. 1. GKE Standard: You choose the exact size of your Worker Node VMs (e.g., e2-medium). You pay for the VMs 24/7, even if your containers aren't doing any work. (Maximum control).
  1. 2. GKE Autopilot: The future of Kubernetes. Google manages the Brain AND the Worker Nodes! You don't pick VMs. You just say "Run this container," and Google provisions the exact micro-slice of CPU needed. You pay *strictly per Pod*. (Maximum automation, zero maintenance).

6. The Core Objects: Pods, Deployments, and Services

  • Pod: The smallest unit in Kubernetes. It wraps your Docker container.
  • Deployment: The manager. You write a YAML file saying "I want 3 Pods running." The Deployment ensures 3 Pods are *always* running.
  • Service: The network door. Pod IPs change constantly. A Service provides a permanent IP address so users can reliably reach your Pods.

7. Mini Project: Deploy an App on GKE

Let's orchestrate a real containerized application.

Step-by-Step Tutorial: *(We will use GKE Autopilot for simplicity!)*

  1. 1. In the GCP Console, navigate to Kubernetes Engine > Clusters.
  1. 2. Click Create.
  1. 3. Click Configure next to Autopilot.
  1. 4. Name: my-first-cluster. Choose a region near you. Click Create.
*(Wait 5-10 minutes. Google is provisioning massive infrastructure behind the scenes!)*
  1. 5. Once the cluster is green, click the three dots next to it and select Connect.
  1. 6. Click Run in Cloud Shell. (This opens a terminal pre-authenticated to your cluster).
  1. 7. Press Enter to execute the connection command.
  1. 8. Let's deploy an Nginx web server. Run this imperative command:

bash
1 
kubectl create deployment my-web-app --image=nginx
  1. 9. Verify the Pod is running:
bash
1 
kubectl get pods
  1. 10. The app is running, but it's hidden inside the cluster. Let's expose it to the internet by creating a LoadBalancer Service:
bash
1 
kubectl expose deployment my-web-app --type=LoadBalancer --port=80
  1. 11. Find your new Public IP address:
bash
1 
kubectl get service

*(Wait a minute until the EXTERNAL-IP changes from <pending> to a real IP address).*

  1. 12. Copy the External IP and paste it into your browser. You are looking at an Nginx web server running on world-class Google Kubernetes infrastructure!

8. Real-World Scenarios

A popular mobile game runs its backend on GKE. On Friday nights, traffic spikes by 1000%. Because they use Kubernetes, the Horizontal Pod Autoscaler (HPA) automatically detects the CPU strain and scales the backend from 10 Pods to 100 Pods. If the underlying VMs run out of RAM, the Cluster Autoscaler automatically asks Google to spin up more physical VMs to hold the Pods. On Monday morning, everything automatically shrinks back down to save money. Zero human intervention required.

9. Best Practices

  • Never Use :latest Tags: When deploying containers to GKE, never specify your image as my-app:latest. If you need to roll back a buggy update, GKE won't know which "latest" is the good one. Always use specific version tags or Git commit hashes (e.g., my-app:v1.2.4).

10. Cost Optimization Tips

  • Delete Unused Clusters! GKE Autopilot charges a baseline management fee of ~$70/month per cluster, plus the cost of the Pods. If you follow the Mini Project above, make sure to delete the cluster when you are done learning to avoid draining your free credits!

11. CLI Examples

To scale your deployment from 1 replica to 5 replicas via Cloud Shell:
bash
1 
kubectl scale deployment my-web-app --replicas=5

12. Exercises

  1. 1. What is the fundamental operational difference between GKE Standard and GKE Autopilot?
  1. 2. Why is a Kubernetes "Service" required to expose a "Deployment" to the public internet?

13. FAQs

Q: Do I need to learn Docker before learning GKE? A: Yes! Kubernetes is the orchestrator; Docker is the packaging format. You must know how to build a Docker container before you can tell Kubernetes to run it. (We cover this in the next chapter!).

14. Interview Questions

  • Q: Explain the Shared Responsibility Model within the context of a Managed Kubernetes Service like GKE Standard. Which architectural components are you responsible for, and which are abstracted by Google?
  • Q: Describe the architectural interplay between the Horizontal Pod Autoscaler (HPA) and the Cluster Autoscaler in ensuring a GKE application survives a massive, sudden traffic spike.

15. Summary

In Chapter 9, we elevated our infrastructure from static VMs to dynamic, self-healing orchestration. We introduced Google Kubernetes Engine (GKE) as the industry standard for managing containerized workloads. We differentiated between the immense control of GKE Standard and the serverless automation of GKE Autopilot. Finally, utilizing Cloud Shell and kubectl, we successfully deployed, scaled, and publicly exposed a highly available web application across a distributed cluster.

16. Next Chapter Recommendation

We told GKE to pull the nginx image from the public internet. But what if we write our own custom Python or Node.js code? Where do we store our private images? Proceed to Chapter 10: Docker and Container Registry.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Google Cloud DNS
Next Chapter Docker and Container Registry

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

❓ Related Quizzes 6