SkarpSkarp

Chapter 11 of 27

Deploying Containers with Google Kubernetes Engine

Kubernetes on Google Cloud offers powerful orchestration; learn how to stand up clusters, deploy workloads, and choose between GKE modes for exam scenarios.

27 min readen

Where GKE Fits in Your Compute Choices

Your Compute Options

For this exam you must recognize when to use the four compute choices: Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions.

What GKE Is

Google Kubernetes Engine (GKE) is a managed Kubernetes service where Google runs the Kubernetes control plane and you deploy containerized workloads.

When to Choose GKE

Choose GKE when you need full Kubernetes features, many microservices, portability across Kubernetes environments, or more control than Cloud Run but less than raw VMs.

GKE Core Concepts: Clusters, Nodes, Pods, Services

Cluster and Nodes

A cluster is your Kubernetes environment. In GKE it includes a managed control plane and worker nodes, which are Compute Engine VMs that run your containers.

Pods and Deployments

A pod is the smallest deployable unit, often one container. A Deployment manages replica sets and pods, keeping the desired number of replicas running.

Services and Google Cloud

A Service gives pods a stable IP and DNS name. In GKE, LoadBalancer Services create Google Cloud load balancers and export logs and metrics to Cloud Logging and Monitoring.

GKE Autopilot vs Standard: Choosing the Right Mode

Autopilot Mode

GKE Autopilot: Google manages nodes, you pay mainly for pod resources, and you focus on Kubernetes objects, not VM sizing or node maintenance.

Standard Mode

GKE Standard: You manage node pools and VM types, pay per node VM, and can customize hardware, autoscaling, and advanced scheduling.

Exam Clues

Exam clue: simplicity, small teams, reduced ops → Autopilot. Custom machine types, GPUs, detailed node control → Standard.

Hands-on: Creating a GKE Autopilot Cluster (Console and gcloud)

Prerequisites

Conceptually you need: a project with billing, permissions like container.admin, and a VPC/subnet where GKE can create resources.

Console Steps (Autopilot)

Console: Kubernetes Engine → Clusters → Create → choose Autopilot, name it (for example `autopilot-demo`), pick a region, keep defaults, then Create.

gcloud Command

CLI: use `gcloud container clusters create-auto autopilot-demo --region=us-central1`. Remember: `create-auto` = Autopilot, `create` = Standard.

Regional vs Zonal GKE Clusters and Private Clusters

Zonal Clusters

Zonal clusters run control plane and nodes in one zone. They are cheaper and simpler but less resilient to zone failures.

Regional Clusters

Regional clusters spread the control plane and optionally nodes across multiple zones in a region for higher availability.

Private Clusters

Private clusters keep node IPs internal only, often with private control plane access, used when internet exposure must be minimized.

Hands-on: Creating a Standard GKE Cluster and Getting Credentials

Practice the basic `gcloud` flow to create a Standard cluster, then connect with `kubectl`.

```bash

1. Set default region/zone (example values)

gcloud config set compute/region us-central1

gcloud config set compute/zone us-central1-a

2. Create a small Standard zonal cluster

gcloud container clusters create standard-demo \

--num-nodes=2 \

--machine-type=e2-medium \

--zone=us-central1-a

3. Fetch kubeconfig credentials so kubectl can talk to the cluster

gcloud container clusters get-credentials standard-demo \

--zone=us-central1-a

4. Verify access

kubectl get nodes

```

Key flags to remember for the exam:

  • `gcloud container clusters create` → Standard cluster.
  • `--num-nodes`, `--machine-type` → node pool sizing.
  • `gcloud container clusters get-credentials` → updates your local kubeconfig so `kubectl` can reach the cluster.

In Autopilot, you still run `get-credentials`, but node sizing flags are not used because Google manages nodes.

Deploying a Basic Containerized App to GKE

Once you have `kubectl` access, deploying a simple app uses standard Kubernetes YAML. This example deploys a basic web app and exposes it via a Service.

```yaml

deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: hello-deployment

spec:

replicas: 3

selector:

matchLabels:

app: hello

template:

metadata:

labels:

app: hello

spec:

containers:

  • name: hello-container

image: gcr.io/google-samples/hello-app:1.0

ports:

  • containerPort: 8080

```

```yaml

service.yaml

apiVersion: v1

kind: Service

metadata:

name: hello-service

spec:

type: LoadBalancer

selector:

app: hello

ports:

  • port: 80

targetPort: 8080

```

Apply these manifests:

```bash

kubectl apply -f deployment.yaml

kubectl apply -f service.yaml

kubectl get pods

kubectl get service hello-service

```

In GKE, the `LoadBalancer` Service provisions a Google Cloud external load balancer and assigns an external IP. When the IP is in the `EXTERNAL-IP` column, you can curl or browse to it.

Exam tip: know that `type: LoadBalancer` maps to a Google Cloud load balancer; `ClusterIP` is internal-only; `NodePort` exposes on each node's IP and a high port.

Thought Exercise: Choosing Compute and Cluster Type

Work through this scenario mentally and pick your design.

Scenario:

  • You have 15 microservices, each packaged as a Docker container.
  • The team already uses Kubernetes manifests (Deployments and Services) in a dev environment.
  • Production requires high availability within a single region.
  • The team is small and wants minimal node management.

Questions to consider:

  1. Which compute product is the best fit: Compute Engine, Google Kubernetes Engine, Cloud Run, or Cloud Functions?
  2. Within GKE, would you choose Autopilot or Standard? Why?
  3. Would you make the cluster zonal or regional?

Suggested reasoning (compare with your own):

  • Because you already have Kubernetes manifests and multiple microservices, Google Kubernetes Engine is a natural fit.
  • The team wants minimal node management, so Autopilot likely aligns better than Standard.
  • Production requires high availability within one region, so a regional Autopilot cluster is appropriate.

On the exam, similar scenarios appear as multiple-choice questions. Practice mapping requirements (Kubernetes, HA, small team, control needs) to the right combination of product, mode, and topology.

Quick Check: GKE Modes and Cluster Types

Test your understanding of Autopilot vs Standard and regional vs zonal clusters.

A small team wants to run a production microservices app in GKE. They want high availability within a region and as little node management as possible. Which combination is the best fit?

  1. Standard GKE, zonal cluster
  2. Autopilot GKE, regional cluster
  3. Standard GKE, regional cluster with custom node pools
  4. Cloud Run with no GKE cluster
Show Answer

Answer: B) Autopilot GKE, regional cluster

The team explicitly wants GKE with minimal node management and high availability in a region. Autopilot minimizes node ops and a regional cluster provides higher availability. Standard with custom node pools adds more management overhead. Cloud Run is a different product, not GKE.

IAM, Service Accounts, and Basic Security for GKE

IAM and GKE

IAM controls who can create and manage GKE clusters. Roles like `roles/container.admin` let users run `gcloud container` commands against your project.

Service Accounts in GKE

A service account is a special kind of account used by a workload. Nodes and pods can use service accounts to call Google Cloud APIs securely.

Workload Identity

Workload Identity maps Kubernetes service accounts to Google Cloud service accounts, avoiding long-lived keys inside containers.

Quick Check: Services and Exposure

Confirm you understand how Services expose workloads in GKE.

In a GKE cluster, you deploy a Deployment with three replicas. You want users on the internet to reach the app over HTTP with a stable IP. Which Service type should you use?

  1. ClusterIP
  2. NodePort
  3. LoadBalancer
  4. Headless Service
Show Answer

Answer: C) LoadBalancer

A `LoadBalancer` Service in GKE provisions a Google Cloud external load balancer and assigns a stable external IP. `ClusterIP` is internal-only, `NodePort` exposes high ports on node IPs, and headless Services do not allocate a cluster IP.

When to Consider GKE Enterprise Features (Conceptual Only)

What is GKE Enterprise?

GKE Enterprise is an enterprise Kubernetes platform layer around GKE, aimed at multi-cluster management, policy, and security at scale.

When It Matters

Large or regulated organizations with many clusters or hybrid setups may use GKE Enterprise for centralized config and policy management.

Exam Focus

For this exam, know it exists conceptually but focus on single-cluster GKE operations, modes, and basic deployments.

Key GKE Terms Review

Use these flashcards to reinforce the most important GKE concepts for the exam.

Google Kubernetes Engine (GKE)
A managed Kubernetes service on Google Cloud where Google runs the Kubernetes control plane and you run containerized workloads on worker nodes.
GKE Autopilot mode
An operation mode where Google fully manages the cluster's nodes and you are billed mainly for pod resources, focusing on workloads instead of infrastructure.
GKE Standard mode
An operation mode where you manage node pools, machine types, and some maintenance, and are billed per node VM plus related cluster costs.
Zonal vs Regional cluster
Zonal: control plane and nodes in one zone, lower cost but less resilient. Regional: control plane (and often nodes) spread across zones in a region for higher availability.
Private GKE cluster
A cluster where nodes have internal IPs only and control plane access can be private, reducing exposure to the public internet.
Pod
The smallest deployable Kubernetes unit, usually one container, sharing network and storage with any sidecar containers.
Deployment
A Kubernetes object that manages stateless applications by maintaining a desired number of pod replicas and enabling rolling updates.
Service (type LoadBalancer)
A Kubernetes Service that exposes pods externally. In GKE it provisions a Google Cloud external load balancer with a stable external IP.
gcloud container clusters get-credentials
The command that retrieves cluster credentials and updates your kubeconfig so that kubectl can communicate with a GKE cluster.
Workload Identity (GKE)
A feature that maps Kubernetes service accounts to Google Cloud service accounts so workloads can call Google Cloud APIs without storing keys.

Key Terms

Pod
The smallest deployable Kubernetes unit, containing one or more containers that share networking and storage.
Deployment
A Kubernetes resource that manages stateless applications by ensuring a specified number of pod replicas and enabling rolling updates and rollbacks.
GKE Standard
An operation mode where you manage node pools, machine types, and some maintenance, and are billed per node VM plus related cluster costs.
GKE Autopilot
An operation mode where Google fully manages the cluster's nodes and you are billed mainly for pod resources, focusing on workloads instead of infrastructure.
Zonal cluster
A GKE cluster whose control plane and nodes run in a single zone, offering lower cost and simplicity but less resilience to zone failures.
Private cluster
A GKE cluster where nodes use internal IP addresses only and control plane access can be private, minimizing public internet exposure.
Regional cluster
A GKE cluster whose control plane, and optionally nodes, span multiple zones in a region to provide higher availability.
Workload Identity
A GKE feature that maps Kubernetes service accounts to Google Cloud service accounts, allowing workloads to access Google Cloud APIs without long-lived keys.
Service (Kubernetes)
A Kubernetes abstraction that provides stable networking (IP and DNS) and load balancing for a set of pods.
Google Kubernetes Engine (GKE)
A managed Kubernetes service on Google Cloud where Google runs the Kubernetes control plane and you run containerized workloads on worker nodes.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself