This chapter covers containers and Kubernetes on Google Cloud Platform (GCP), a core topic for the Google Cloud Digital Leader (GCDL) exam. Understanding these technologies is essential because they represent a paradigm shift in how applications are built, deployed, and scaled. Approximately 15-20% of exam questions touch on container and Kubernetes concepts, including the benefits of containers, the role of Kubernetes, and Google Kubernetes Engine (GKE) features. This chapter will equip you with the precise knowledge needed to answer questions about containerization, orchestration, and GCP's managed Kubernetes service.
Jump to a section
Imagine a global shipping company that needs to transport goods from factories to stores. Before containers, each item was individually wrapped and handled, leading to inefficiency and damage. Containers standardize packaging: any item fits in a standard 20- or 40-foot container, which can be loaded onto a truck, train, or ship without repacking. Similarly, a software container packages an application with all its dependencies (libraries, binaries, config) into a standardized unit. Now, the shipping company has a fleet manager who orchestrates thousands of containers across multiple ships and ports. The manager decides which ship gets which containers, monitors each container's journey, and if a ship is delayed, reroutes containers to another ship. This is Kubernetes: it schedules containers onto nodes (ships), monitors health, and automatically restarts failed containers. The manager uses labels (like destination port) to group containers and ensure they arrive together. In the same way, Kubernetes uses labels and selectors to group pods. The manager also ensures that each container gets the right resources (cranes, dock space) — analogous to CPU and memory requests/limits. Without the manager, containers would be manually placed, leading to underutilization or overload. Kubernetes provides automated deployment, scaling, and management of containerized applications.
What Are Containers and Why Do They Exist?
Containers are a lightweight form of virtualization that packages an application and its dependencies together in a standardized unit. Unlike virtual machines (VMs), which include a full guest operating system, containers share the host OS kernel. This makes them more efficient in terms of resource usage and startup time. The primary reason containers exist is to solve the "it works on my machine" problem: by bundling the application with everything it needs (libraries, runtime, system tools, config), containers ensure consistent behavior across development, testing, and production environments.
How Containers Work Internally
Containers leverage Linux kernel features: namespaces and cgroups. Namespaces provide isolation: each container gets its own view of the system (process IDs, network interfaces, mount points, etc.). For example, PID namespace makes processes inside the container see only their own process tree. cgroups (control groups) limit and monitor resource usage: CPU, memory, disk I/O, and network. When a container starts, the container runtime (e.g., Docker, containerd) creates these namespaces and cgroups, then runs the application process inside them. The container image is a layered filesystem: each layer is a set of changes (e.g., adding a file). Layers are read-only and shared between containers, saving disk space and network bandwidth when pulling images.
Key Components, Values, and Defaults
Container Image: A read-only template with instructions for creating a container. Images are stored in a registry, like Google Container Registry (GCR) or Artifact Registry. Default tag: latest.
Container Runtime: Software that runs containers. Docker is the most common, but Kubernetes uses containerd or CRI-O.
Pod: The smallest deployable unit in Kubernetes. A pod encapsulates one or more containers with shared storage and network. Containers in a pod share the same IP address and port space, and can communicate via localhost. Default: containers in a pod share the same lifecycle.
Node: A worker machine (VM or physical) that runs pods. Each node runs a kubelet agent that communicates with the control plane.
Control Plane: The brain of Kubernetes, consisting of components like kube-apiserver, etcd (distributed key-value store), kube-scheduler, and kube-controller-manager.
Service: An abstraction that defines a logical set of pods and a policy to access them. Services provide stable IP and DNS names. Types: ClusterIP (default, internal), NodePort (expose on node port), LoadBalancer (external load balancer, often cloud-provider-specific).
Deployment: A controller that manages a set of identical pods (replicas). It ensures the desired number of pods are running, supports rolling updates and rollbacks.
Namespace: A virtual cluster within a physical cluster. Used to organize resources, provide isolation, and manage quotas. Default namespaces: default, kube-system, kube-public.
ConfigMap and Secret: Store configuration data and sensitive information (e.g., passwords) separately from container images. ConfigMaps are not encrypted; Secrets are base64-encoded but not encrypted at rest by default (use encryption at rest or external secrets manager).
Resource Requests and Limits: Specify minimum and maximum CPU/memory for a container. If a container exceeds its limit, it may be throttled (CPU) or OOM-killed (memory). Default: no limits.
Horizontal Pod Autoscaler (HPA): Automatically scales the number of pods based on CPU/memory utilization or custom metrics. Default sync period: 15 seconds.
Cluster Autoscaler: Automatically adjusts the number of nodes in a node pool based on pod resource requests.
Configuration and Verification Commands
kubectl run nginx --image=nginx creates a pod.
kubectl create deployment my-app --image=my-app:1.0 creates a deployment.
kubectl expose deployment my-app --type=LoadBalancer --port=80 --target-port=8080 creates a service.
kubectl get pods -n my-namespace lists pods.
kubectl describe pod my-pod shows detailed status.
kubectl logs my-pod fetches logs.
kubectl exec -it my-pod -- /bin/bash gets a shell.
kubectl get events --sort-by='.lastTimestamp' shows cluster events.
gcloud container clusters create my-cluster --num-nodes=3 --zone=us-central1-a creates a GKE cluster.
gcloud container clusters get-credentials my-cluster --zone=us-central1-a configures kubectl.
How Containers and Kubernetes Interact with GCP
GCP offers Google Kubernetes Engine (GKE), a managed Kubernetes service. GKE automatically provisions and manages the control plane, upgrades nodes, and integrates with other GCP services like Cloud Load Balancing, Cloud Monitoring, and Cloud Logging. GKE supports node pools (groups of nodes with same configuration), automatic node repair, and auto-scaling. GKE also integrates with Container Registry (GCR) and Artifact Registry for image storage. For networking, GKE uses VPC-native clusters (alias IP ranges) for better performance and security. GKE can also use Cloud NAT for outbound internet access from private clusters.
Key Exam-Relevant Details
GKE Cluster Types: Zonal (single zone) and Regional (multi-zone). Regional clusters have higher availability.
Node Auto-Repair: GKE automatically repairs unhealthy nodes by recreating them. Default: enabled.
Node Auto-Upgrade: GKE automatically upgrades node versions to match control plane. Default: enabled.
Workload Identity: Allows GKE pods to authenticate to GCP APIs using IAM service accounts without managing keys.
GKE Sandbox: Provides an additional layer of isolation using gVisor, a sandboxed kernel.
GKE Autopilot: A mode where GKE manages the entire cluster infrastructure, including node provisioning and scaling. You only define workloads.
Cloud Run: A managed compute platform that runs stateless containers in a serverless fashion. It automatically scales based on request volume.
Cloud Build: CI/CD service that can build container images and deploy to GKE or Cloud Run.
Artifact Registry: Next-generation container registry with vulnerability scanning and IAM integration.
Create a Container Image
Start with a Dockerfile that defines the application and its dependencies. For example, a Python app uses `FROM python:3.9-slim`, copies code, installs packages with `pip`, and sets the entrypoint. The Dockerfile is built using `docker build -t my-app:1.0 .`. The image is stored locally and can be pushed to a registry like Google Container Registry (GCR) with `docker push gcr.io/my-project/my-app:1.0`. Images are composed of layers; each instruction in the Dockerfile creates a layer. Layers are cached and reused to speed up builds.
Deploy a GKE Cluster
Use the gcloud command `gcloud container clusters create my-cluster --num-nodes=3 --zone=us-central1-a`. This provisions a Kubernetes control plane and three worker nodes (VMs). GKE manages the control plane (API server, etcd, scheduler) automatically. Nodes are Compute Engine instances with a container runtime (containerd) and kubelet. The cluster is configured with VPC-native networking using alias IP ranges. After creation, authenticate with `gcloud container clusters get-credentials my-cluster --zone=us-central1-a` to configure kubectl.
Define a Deployment
Create a YAML file (e.g., deployment.yaml) that specifies the desired state: `apiVersion: apps/v1`, `kind: Deployment`, metadata with name and labels, spec with replicas (e.g., 3), selector matching labels, and template for pods. The pod template includes containers with image name (e.g., `gcr.io/my-project/my-app:1.0`), ports, resource requests/limits. Apply with `kubectl apply -f deployment.yaml`. The deployment controller creates a ReplicaSet, which creates the pods. The scheduler assigns pods to nodes based on resource availability and constraints.
Expose the Application via Service
To make the application accessible, create a Service. For external access, use `type: LoadBalancer`. The YAML specifies `apiVersion: v1`, `kind: Service`, metadata with name, selector matching pod labels, ports (e.g., port 80, targetPort 8080). Apply with `kubectl apply -f service.yaml`. GKE provisions a Google Cloud Load Balancer (external TCP/UDP LB). The Service gets an external IP. Traffic is load-balanced across healthy pods. For internal access, use `type: ClusterIP` (default) or `type: NodePort`.
Scale and Monitor
Use `kubectl scale deployment my-app --replicas=5` to manually scale. For automatic scaling, create a HorizontalPodAutoscaler (HPA) that targets CPU utilization (e.g., 80%). The HPA controller adjusts replicas every 15 seconds. Monitor with `kubectl get hpa` and `kubectl top pods`. GKE integrates with Cloud Monitoring for metrics. View logs with `kubectl logs` or via Cloud Logging. Use `kubectl describe pod` to see events. If a pod fails, the ReplicaSet recreates it. Node failures trigger GKE node auto-repair.
Enterprise Scenario 1: E-commerce Platform Migration
A large online retailer runs a monolithic application on VMs. They want to adopt microservices for faster feature releases. They containerize each microservice (user service, product catalog, payment, etc.) and deploy on GKE. They use a regional cluster for high availability, with node pools for different machine types (e.g., compute-optimized for CPU-bound services, memory-optimized for caching). They configure Horizontal Pod Autoscalers based on CPU and request latency. For secure inter-service communication, they use Kubernetes NetworkPolicies to restrict traffic. They integrate Cloud NAT for outbound internet from private nodes. Common issue: misconfigured resource requests cause pods to be evicted; they set requests to 80% of actual usage after monitoring. Scaling: they have 50 microservices, 200 pods, and 3 nodes initially, scaling to 20 nodes during Black Friday.
Enterprise Scenario 2: CI/CD Pipeline for SaaS
A SaaS company uses Cloud Build to build container images from GitHub commits. Each build triggers a new image tag (e.g., v1.2.3-build.456). Cloud Build pushes to Artifact Registry, then deploys to a GKE cluster using a deployment YAML with the new tag. They use canary deployments: a separate deployment with 10% of replicas runs the new version, and a service with session affinity routes a subset of users. They use GKE's built-in rollback feature: kubectl rollout undo deployment/my-app. They monitor error rates with Cloud Monitoring and automatically rollback if errors spike. Misconfiguration: forgetting to update the image tag in the deployment YAML leads to no change; they use Cloud Build substitutions to inject the tag.
Enterprise Scenario 3: Batch Processing with Jobs
A financial services firm runs daily batch jobs to process transactions. They use Kubernetes Jobs and CronJobs. Each job spins up a pod, processes a queue of transactions, and exits. They use a GKE cluster with preemptible (spot) VMs to reduce costs. They set pod anti-affinity to spread jobs across nodes. To handle failures, they configure job backoffLimit (default 6) and activeDeadlineSeconds. They use Cloud Storage for input/output data. Common problem: jobs failing due to insufficient memory; they set resource limits based on historical data. They also use node auto-scaling to add nodes during peak hours.
GCDL Objective Coverage
This topic aligns with Objective 4.2: "Explain the benefits of containers and Kubernetes on Google Cloud." The exam tests your understanding of:
Container benefits: portability, consistency, efficiency, isolation.
Kubernetes benefits: automated deployment, scaling, self-healing, load balancing.
GKE features: managed control plane, auto-repair, auto-upgrade, Autopilot, Workload Identity.
Differences between VMs and containers.
When to use Cloud Run vs GKE.
Common Wrong Answers and Traps
Containers are just like VMs but smaller. Wrong: VMs have separate OS kernels; containers share the host kernel. The exam may ask about resource efficiency. The correct answer is that containers are more lightweight because they don't require a full OS per instance.
Kubernetes always requires manual node management. Wrong: GKE Autopilot and node auto-repair/upgrade automate node management. The exam tests Autopilot as a fully managed option.
Pods are the same as containers. Wrong: A pod can run multiple containers that share resources. The exam may ask about the smallest deployable unit in Kubernetes (pod, not container).
Services always provide external IPs. Wrong: ClusterIP is internal only. The exam tests service types.
Specific Numbers, Values, and Terms
Default replica count: 1 (if not specified).
HPA default sync period: 15 seconds.
HPA default stabilization window: 5 minutes.
GKE Autopilot: no node management; you only define workloads.
Workload Identity: maps Kubernetes service accounts to IAM service accounts.
GKE Sandbox: uses gVisor for kernel isolation.
Cloud Run: max request timeout 60 minutes, max concurrent requests 80 (default).
Artifact Registry: supports Docker, Maven, npm, etc.
Edge Cases and Exceptions
Stateful applications: Use StatefulSet instead of Deployment for stateful apps (e.g., databases). StatefulSets provide stable network IDs and persistent storage.
DaemonSet: Runs a pod on every node (e.g., logging agent).
InitContainers: Run before app containers finish startup.
PodDisruptionBudget: Limits number of pods that can be down simultaneously during voluntary disruptions.
GKE Regional clusters: Have higher availability but cost more.
Elimination Strategy
When faced with a question about containers vs VMs, eliminate answers that imply containers have separate kernels. For Kubernetes questions, eliminate answers that say Kubernetes requires manual scaling (HPA exists). For GKE, eliminate answers that say you must manage control plane (GKE manages it). If the question asks about smallest deployable unit, eliminate any answer that says 'container' (correct is 'pod').
Containers share the host OS kernel, making them more lightweight than VMs.
Kubernetes automates deployment, scaling, and management of containerized applications.
The smallest deployable unit in Kubernetes is a pod, not a container.
GKE is Google's managed Kubernetes service; it offers zonal and regional clusters.
GKE Autopilot fully manages nodes; you only define workloads.
Workload Identity allows GKE pods to authenticate to GCP services without keys.
Cloud Run is serverless and scales to zero; ideal for stateless HTTP services.
Horizontal Pod Autoscaler scales pods based on CPU/memory with a 15-second sync period.
GKE node auto-repair and auto-upgrade are enabled by default.
Artifact Registry replaces Container Registry with multi-format support and vulnerability scanning.
These come up on the exam all the time. Here's how to tell them apart.
Virtual Machines
Each VM includes a full guest OS (kernel, libraries, etc.).
VM startup time is minutes.
VMs provide strong isolation via hypervisor.
VM images are large (GBs).
VMs are less efficient in resource usage due to OS overhead.
Containers
Containers share the host OS kernel.
Container startup time is seconds.
Containers provide process-level isolation via namespaces.
Container images are small (MBs).
Containers are more efficient, allowing higher density on a host.
Google Kubernetes Engine (GKE)
GKE is a managed Kubernetes service for container orchestration.
You define and manage nodes (unless Autopilot).
GKE supports complex deployments, stateful apps, and custom networking.
GKE can run long-running services and batch jobs.
You pay for underlying nodes (Compute Engine instances).
Cloud Run
Cloud Run is a serverless container platform.
No node management; fully managed by Google.
Cloud Run automatically scales to zero when not in use.
Cloud Run is ideal for stateless HTTP-driven applications.
You pay per request and compute time (no idle cost).
Mistake
Containers provide the same level of isolation as virtual machines.
Correct
Containers share the host OS kernel, so they have weaker isolation than VMs. A kernel exploit can compromise all containers on a host. GKE Sandbox (gVisor) provides an extra layer of kernel isolation.
Mistake
Kubernetes requires manual node management.
Correct
GKE offers node auto-repair and auto-upgrade. In Autopilot mode, GKE manages nodes entirely. You only define workloads.
Mistake
A pod is just a container.
Correct
A pod is a group of one or more containers that share the same network namespace and storage. Containers in a pod can communicate via localhost. The pod is the smallest deployable unit in Kubernetes.
Mistake
Kubernetes services always provide a stable external IP.
Correct
Only LoadBalancer and NodePort services provide external access. ClusterIP services are internal only. Ingress resources can also expose services externally.
Mistake
Containers are always stateless.
Correct
Containers can be stateful, but Kubernetes StatefulSets are designed for stateful applications. Persistent volumes can be attached to pods to store data.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Containers share the host OS kernel, while VMs have their own guest OS. Containers are lighter (MBs vs GBs), start in seconds vs minutes, and allow higher density. VMs provide stronger isolation because they are separated by a hypervisor. Containers use namespaces and cgroups for isolation.
A pod is the smallest deployable unit in Kubernetes. It encapsulates one or more containers that share the same network namespace (same IP) and storage volumes. Containers in a pod can communicate via localhost. Pods are ephemeral; they can be replaced by a Deployment.
GKE is a managed Kubernetes cluster where you control nodes (unless Autopilot). It supports any workload type, including stateful and batch. Cloud Run is serverless and automatically scales to zero; it only runs stateless HTTP containers. Cloud Run is simpler but less flexible.
GKE has node auto-repair enabled by default. It monitors node health via the kubelet. If a node is unhealthy for a period (e.g., 5 minutes), GKE recreates it. Pods on the failed node are rescheduled to healthy nodes.
Workload Identity is a GKE feature that allows pods to authenticate to Google Cloud APIs using IAM service accounts. You bind a Kubernetes service account to an IAM service account. Pods then automatically obtain credentials without needing to manage keys.
Yes, using StatefulSets. StatefulSets provide stable network identities (e.g., pod-0, pod-1) and persistent storage via PersistentVolumeClaims. They are ideal for databases and other stateful workloads.
The default service type is ClusterIP, which exposes the service on a cluster-internal IP. It is only accessible from within the cluster. To expose externally, use NodePort or LoadBalancer.
You've just covered Containers and Kubernetes on GCP — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?