19 - GKE Kubernetes Overview for Beginners

Welcome to Day 19 of Learn GCP in 30 Days! Today, we demystify the single most famous buzzword in enterprise cloud computing: Kubernetes and Google Kubernetes Engine (GKE).

🛳️ The Core Problem: The "500 Containers Chaos"

On Day 15, you learned that Docker lets you package an application into a portable container box.

Running 1 container on your laptop with docker run is easy. But imagine you work at an enterprise company with 500 microservice containers running across 50 servers:

What Existed Previously (Manual Container Management):

Engineers had to SSH into individual virtual machines, manually run docker run commands, write custom monitoring scripts, and manually replace dead containers at 3:00 AM.

Problems Faced:

• 💥 Zero Self-Healing: If a container crashes, it stays dead until an engineer manually logs in and restarts it.
• 🤯 Scheduling Nightmare: If you have 50 servers, which server has enough spare CPU/RAM to run Container #437?
• 🔌 Networking Spaghetti: When containers restart, their internal IP addresses change constantly. How do frontend containers find backend containers?
• 🐌 Manual Scaling: If website traffic triples during a flash sale, you must manually launch 30 new containers across multiple VMs and update load balancers.

How Present Technology Solves It:

Google invented Kubernetes (often called K8s) — based on its internal system called Borg that powers Google Search and YouTube:

1. The Automatic Ship Captain: Kubernetes acts as an automated captain that manages, monitors, and steers your container fleet 24/7.
2. Self-Healing: If a container crashes or a physical server dies, Kubernetes notices in 1 second, moves the workload, and launches a fresh replacement automatically.
3. Auto-Packing & Scaling: Kubernetes automatically places containers on whichever server has the most available room, and scales container counts up or down with traffic.
4. Google Kubernetes Engine (GKE): Google's fully managed cloud version where Google handles the Kubernetes control brain for you!

🎼 Real-World Analogy: The Orchestra Conductor & The Apartment Building

Let's use 2 simple real-world analogies:

Analogy 1: The Concert Orchestra Conductor

• 🎻 Individual Musicians = Docker Containers: Each musician plays their own specific instrument (Python backend, Node.js API, Redis cache).
• 🎼 The Conductor = Kubernetes: Standing at the front, keeping everyone in rhythm. If the 2nd violinist faints, the Conductor immediately cues a backup violinist to take their place without stopping the symphony!

Analogy 2: The Apartment Building (Kubernetes Components)

• 🏢 Node (The Building): A physical or virtual server with CPU and RAM.
• 🚪 Pod (The Apartment Flat): The smallest living unit. A Pod wraps and runs 1 (or more) Docker containers.
• 📋 Deployment (The Building Manager): The landlord who enforces a rule: "There must ALWAYS be exactly 3 occupied flats running the web app. If flat 2 catches fire, build flat 4 immediately!"
• 🛎️ Service (The Lobby Intercom): Gives visitors 1 single stable door address / phone number that routes calls to whichever flat is currently occupied.

🔑 Everyday Cloud Terms Explained in Plain English

1. The 5 Core Building Blocks of Kubernetes

2. GKE Autopilot vs. GKE Standard: Which to Pick?

Google Cloud provides two ways to run Kubernetes:

3. What is kubectl?

kubectl (pronounced "Cube-Control" or "Cube-Cuddle") is the official universal command-line tool used to talk to any Kubernetes cluster in the world.

🧪 Hands-on Lab Activity: Launch Your First GKE Workload

In this hands-on lab, we will:

1. Enable the Google Kubernetes Engine API.
2. Create a lightweight GKE Autopilot cluster.
3. Write a Kubernetes YAML Deployment manifest.
4. Deploy the workload and expose it to the internet using kubectl.
5. Test Kubernetes self-healing live!

Step 1: Enable the Kubernetes Engine API

Option A: Web Console UI

1. Open console.cloud.google.com.
2. Press /, type Kubernetes Engine API, and click on it.
3. Click Enable.

Option B: Cloud Shell CLI

gcloud services enable container.googleapis.com

Step 2: Create a GKE Autopilot Cluster

Let's create a fully managed Autopilot cluster in our region.

Option A: Web Console UI (Click-by-Click)

1. In the GCP Console, press / $\rightarrow$ type Kubernetes Engine $\rightarrow$ select Clusters.
2. Click Create at the top.
3. Under Autopilot (Recommended), click Configure.
4. Set:
   • Cluster name: my-first-gke-cluster
   • Region: asia-south1 (or your nearest region)
5. Click Create! (Note: GKE cluster creation provisions managed infrastructure and takes ~4-6 minutes).

Option B: Cloud Shell CLI (Fast Track)

gcloud container clusters create-auto my-first-gke-cluster \
    --region=asia-south1

Step 3: Connect kubectl to Your Cluster

Once the cluster is ready, run this command in Cloud Shell to download the security credentials so kubectl can communicate with your new cluster:

gcloud container clusters get-credentials my-first-gke-cluster \
    --region=asia-south1

Step 4: Write a Kubernetes Deployment & Service Manifest

In Kubernetes, we describe what we want using a declarative text file called a YAML manifest.

In Cloud Shell, create a directory and write app-deployment.yaml:

mkdir -p ~/gcp-k8s-lab && cd ~/gcp-k8s-lab

cat << 'EOF' > app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web-container
        image: us-docker.pkg.dev/cloudrun/container/hello
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
EOF

Anatomy Breakdown: What is happening in app-deployment.yaml?

Step 5: Deploy & Inspect Your Kubernetes Workload

1. Apply the YAML file to your cluster:

kubectl apply -f app-deployment.yaml

Output:

deployment.apps/web-app-deployment created
service/web-app-service created

2. Inspect Running Pods:

kubectl get pods

Output:

NAME                                   READY   STATUS    RESTARTS   AGE
web-app-deployment-5c8f8b76df-9p2x4    1/1     Running   0          35s
web-app-deployment-5c8f8b76df-m4k9z    1/1     Running   0          35s

3. Find the Public External IP of Your Service:

kubectl get service web-app-service --watch

(Wait ~1-2 minutes until EXTERNAL-IP changes from <pending> to a real public IP like 34.120.x.x. Press Ctrl + C to exit watch mode).

Open your browser and visit http://YOUR_EXTERNAL_IP to see your live web application running on Kubernetes!

Step 6: Test Kubernetes Self-Healing (Chaos Test 💥)

Let's simulate a crash to watch Kubernetes self-healing in action!

1. Delete one of your running Pods manually:
   bash

   POD_NAME=$(kubectl get pods -o jsonpath='{.items[0].metadata.name}')
   kubectl delete pod $POD_NAME
   

2. Check your pods immediately:
   bash

   kubectl get pods
   

3. What happened? You will see that the deleted pod was terminated, and Kubernetes immediately created a brand-new replacement Pod in under 2 seconds to obey the rule replicas: 2!

🧹 Step 7: Clean Up All Resources (Credit Safety Guarantee)

GKE clusters run multiple services. To guarantee your trial balance drops back to $0.00, delete the workload and the cluster:

Option A: Web Console UI

1. Go to Kubernetes Engine $\rightarrow$ Clusters.
2. Check the box next to my-first-gke-cluster $\rightarrow$ Click Delete at the top $\rightarrow$ Confirm.

Option B: Cloud Shell CLI

# 1. Delete Kubernetes deployment and service
kubectl delete -f app-deployment.yaml 2>/dev/null || true

# 2. Delete the GKE Cluster
gcloud container clusters delete my-first-gke-cluster \
    --region=asia-south1 \
    --quiet

# 3. Clean up local files
rm -rf ~/gcp-k8s-lab

Signal vs. Noise: Key Concepts & Noise Filter

Common Doubts & Interview Traps

Q1: Google Cloud Run vs. GKE: When should I choose GKE?

• Answer:
  • Choose Cloud Run for 90% of standard web apps, microservices, and APIs (simpler, zero Kubernetes YAML, scales to zero automatically).
  • Choose GKE when you need fine-grained control over multi-container Pod networking (sidecars), background daemonsets, GPU/ML training pipelines, or complex stateful workloads.

Q2: What happens if a physical Worker Node (VM) catches fire in GKE?

• Answer: The Kubernetes Control Plane detects that the Node stopped responding, reschedules all Pods that were on that damaged node, and starts them on healthy nodes in seconds with zero data loss.

Q3: Why do Pods need a Service in front of them?

• Answer: Because Pods are ephemeral (temporary). When a Pod crashes or updates, it gets deleted and replaced with a new Pod with a brand-new internal IP address. A Service provides 1 fixed, permanent IP address so clients never need to track changing Pod IPs.

Daily Practice Drill & Self-Check

Test your understanding of today's lesson:

// Try answering these:
1. What is the smallest deployable unit in Kubernetes that wraps a Docker container: a Node, a Pod, or a Cluster?
2. Which Kubernetes resource ensures that exactly 3 identical copies of your web app are always running: a Service or a Deployment?
3. In GKE Autopilot, do you pay for idle Virtual Machines 24/7 or do you pay only for the Pod CPU/RAM used?

🎉 Huge milestone! You have completed Day 19!

You have mastered Kubernetes architecture, Pods, Nodes, Deployments, Services, and deployed your first workload on Google Kubernetes Engine (GKE Autopilot)!

Tomorrow on Day 20, we conclude Week 3 with our Week 3 Capstone Hands-on Lab: Serverless API Pipeline!

← 18 - Eventarc and Pub/Sub Integration | Next Topic → 20 - Hands-on Lab - Serverless API Pipeline