Deploying apps on Google Kubernetes Engine (GKE). If you build a containerised application but have to manually start it on a server, you are still doing most of the work. GKE automates the messy parts so you can focus on writing code, not managing servers. For the Google Professional Cloud Developer exam, understanding GKE is critical because it is Google's primary tool for running containerised applications at scale, and the exam tests your ability to deploy, update, and troubleshoot these deployments.
Jump to a section
A simple way to picture Deploying Apps on Google Kubernetes Engine (GKE)
12 hungry friends show up at your house for a dinner party. You are the host, and your kitchen is a single computer. You can only cook one dish at a time in your oven. To feed everyone, you would need to cook the lasagne, then the garlic bread, then the salad, one after the other. But your friends want to eat together, and they get impatient waiting 90 minutes for their food. This is the old way of running software on one server, one application at a time.
Now suppose you own a commercial kitchen with 20 ovens, 10 hobs, and 5 chefs. You tell your head chef, "I need to serve 12 people a three-course meal." The chef (GKE) immediately looks at your recipes (container images) and decides: three ovens for the lasagne, two hobs for the sauce, one chef for the salad. If a hob breaks, the chef automatically moves the sauce to another hob without you even noticing. If more guests arrive, the chef adds more cooking stations. You never touch a single burner. You just tell the chef what meal to serve, and everything else happens automatically.
This is exactly how Google Kubernetes Engine works. You provide the containerised application (the recipe), and GKE provides the chefs, the ovens, and the automatic repair system. The key measurement is not the number of guests, but the number of user requests your app must handle. 10, 1000, or 1 million, GKE scales the kitchen automatically.
Google Kubernetes Engine, or GKE, is a managed service that runs containerised applications. A container is a lightweight, standalone package that contains everything needed to run a piece of software: the code, the runtime, system tools, libraries, and settings. Think of it like a shipping container; it holds all the items securely, no matter what ship or truck carries it. Containers solve the "it works on my machine" problem because they isolate the application from the underlying server.
Before containers, IT professionals deployed applications directly onto a server's operating system. This caused conflicts: two apps might need different versions of the same library. Containers solve this by packaging each app with its own dependencies. But managing hundreds of containers across multiple servers becomes a nightmare. That is where Kubernetes comes in.
Kubernetes is an open-source system for automating the deployment, scaling, and management of containerised applications. It was originally developed by Google, based on their internal system Borg. GKE is Google Cloud's managed Kubernetes service. "Managed" means Google handles the control plane (the brain of Kubernetes) for you, including upgrades, repairs, and security patches. You just provide the worker machines (called nodes) and your containers.
Here is the core structure of GKE:
Cluster: A cluster is the entire Kubernetes system. It consists of a control plane and a set of worker machines called nodes. In GKE, the control plane is managed by Google.
Node: A node is a virtual machine (VM) that runs your containers. Each node has a container runtime (usually Docker) and an agent called kubelet that communicates with the control plane.
Pod: A pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share storage and network resources. Most pods contain a single container.
Deployment: A deployment tells Kubernetes how many copies of a pod you want running. You specify an application (via its container image) and a desired number of replicas. Kubernetes ensures that number of pods is always running, even if some nodes fail.
Service: A service is an abstraction that provides a stable network endpoint for a set of pods. Pods can be created and destroyed, so you cannot rely on their IP addresses. A service gives them a single, permanent IP address or DNS name.
When you deploy an app on GKE, here is what happens:
You create a container image from your application code using a file called a Dockerfile. This image is stored in a registry like Google Container Registry or Artifact Registry.
You define a YAML configuration file that describes your deployment: the container image, how many replicas, what ports to expose, and any environment variables.
You submit this YAML file to GKE using the command-line tool kubectl. The control plane receives the request and schedules the pods onto healthy nodes.
GKE pulls the container image from the registry onto the node and starts the container inside a pod.
You create a service to expose the pods to traffic. A LoadBalancer service type provisions a Google Cloud load balancer that distributes incoming requests across the pods.
Why does this matter? GKE provides several benefits over managing your own servers:
Automatic scaling: You define a target CPU utilisation (e.g., 70%). GKE automatically adds or removes pods to maintain that target.
Self-healing: If a node crashes, GKE reschedules the pods on another node. If a container fails, GKE restarts it.
Rolling updates: You can update your application with zero downtime. GKE updates pods one by one, ensuring some are always running.
Declarative model: You state what you want (e.g., 5 replicas of my app), and GKE makes it happen. You do not tell it how to do it.
For the PCD exam, you must know how to perform these actions using the Google Cloud Console (web UI), command-line tools (gcloud and kubectl), and automation (Infrastructure as Code with Terraform or Deployment Manager). You also need to understand how GKE integrates with other Google Cloud services like Cloud Logging for monitoring and Cloud IAM for access control.
Create a GKE cluster
In the Google Cloud Console, navigate to Kubernetes Engine and click 'Create Cluster'. Choose a name, region, and node configuration (e.g., 3 nodes of e2-medium). GKE provisions the control plane and the worker nodes. This is your orchestration environment.
Build and push a container image
Write a Dockerfile that defines your application (e.g., a Node.js web server). Build it using `docker build -t gcr.io/[project-id]/my-app:v1 .` and push it to Google Artifact Registry using `docker push`. This stores your app in a registry that GKE can pull from.
Define a Deployment manifest
Create a YAML file named `deployment.yaml` with apiVersion: apps/v1, kind: Deployment, metadata (name), and spec containing replicas: 3, a selector, and a template with the container image you pushed. This tells GKE how many copies of your app to run.
Apply the Deployment to the cluster
Use the command `kubectl apply -f deployment.yaml` to send the configuration to GKE. The control plane schedules the pods onto healthy nodes, pulls the container image, and starts the containers. Verify with `kubectl get pods`.
Expose the app with a Service
Create a `service.yaml` file with kind: Service, type: LoadBalancer, and a selector that matches your pod labels. Apply it with `kubectl apply -f service.yaml`. GKE provisions a Google Cloud load balancer and assigns an external IP. You can now access your app via that IP.
Configure autoscaling
Use `kubectl autoscale deployment my-app --cpu-percent=70 --min=2 --max=10` to create a HorizontalPodAutoscaler. Run `gcloud container clusters update my-cluster --enable-autoscaling --min-nodes=1 --max-nodes=5` to enable cluster autoscaling. This ensures your app scales with demand.
A real IT professional who deploys apps on GKE works for a company called "QuickCart", an e-commerce platform. QuickCart has a microservices architecture: one service handles user accounts, one manages product inventory, one processes payments, and one serves the frontend. Each service is containerised and runs on GKE.
Here is a typical day for the IT pro:
Morning stand-up: The team gets a notification that the payment service is running slowly. The pro opens the Google Cloud Console, navigates to GKE, and looks at the Workloads section. They see the payment service deployment has 3 pods, and CPU usage is at 95%. They decide to increase the number of replicas from 3 to 5 using the horizontal pod autoscaler. They increase the target CPU utilisation threshold to 80%. Within 5 minutes, GKE spins up two more pods, and latency drops back to normal.
Mid-morning deployment: The developer pushes a new version of the inventory service. The pro uses the following workflow:
The developer builds a new container image and tags it with the Git commit hash, pushing it to Google Artifact Registry.
The pro updates the deployment YAML file to reference the new image tag.
They run kubectl apply -f inventory-deployment.yaml to apply the change.
GKE performs a rolling update: it creates a new pod with the new image, waits for it to become healthy (based on a readiness probe), then terminates an old pod. This continues until all pods run the new version. There is zero downtime.
Afternoon incident: A node in the cluster crashes due to a hardware failure. The pro does not get paged because GKE automatically notices the node is unhealthy. The pods that were running on that node are automatically rescheduled onto healthy nodes. The pro only discovers the issue when they review the cluster's node list and see one node has a "NotReady" status. Google Cloud automatically recreates the node, and GKE places it back into service.
Capacity planning: The marketing team announces a flash sale. The pro needs to ensure the cluster can handle 10x traffic. They use cluster autoscaling, which automatically adds new nodes (more VMs) to the cluster when pods cannot be scheduled due to resource constraints. They also ensure the horizontal pod autoscaler is configured for each service. They test the setup by sending simulated traffic using a load testing tool.
The key actions the pro takes daily include:
Using kubectl to inspect pods, deployments, and services.
Writing and updating YAML manifests for deployments, services, and ingress resources.
Configuring horizontal pod autoscaling and cluster autoscaling.
Setting up alerts in Cloud Monitoring for high CPU, high memory, or pod crashes.
Managing secrets and configuration using ConfigMaps and Secrets objects, not hard-coded values.
Controlling access using Kubernetes RBAC (Role-Based Access Control) and Google Cloud IAM.
This shows that GKE is not just about running containers. It is about reliability, scalability, and automation. The IT pro's job shifts from manually fixing servers to designing systems that fix themselves.
The Google Professional Cloud Developer exam tests objective 1.2 "Deploy and manage containerized applications on GKE" through scenario-based multiple-choice questions. You will not be asked to write YAML from scratch, but you must understand the syntax and structure well enough to choose the correct YAML snippet.
Here are the exact concepts they love to test:
Deployment strategies: The exam heavily tests rolling updates versus blue/green deployments versus canary deployments. They will give a scenario like: "You need to update an application with zero downtime and rollback capability. The team wants to test 10% of traffic on the new version first." The correct answer involves a canary deployment using a service mesh like Anthos Service Mesh or a weighted load balancer. A trap is suggesting a rolling update when the key requirement is traffic splitting.
Readiness and liveness probes: They will ask which probe type ensures a pod only receives traffic when it is ready to serve requests. Readiness probes. They will also ask how to configure a startup probe for applications that take a long time to initialise. Traps: confusing readiness with liveness, or not knowing that startup probes delay readiness and liveness checks until the app starts.
Horizontal Pod Autoscaling (HPA): They test what metrics you can use for autoscaling (CPU, memory, or custom metrics). The trap: saying you can scale based on network I/O by default (you cannot, you need custom metrics adapter). Also, they test the formula for desired replicas: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)].
StatefulSets versus Deployments: If your app requires persistent storage with unique network identifiers (like a database), you must use a StatefulSet, not a Deployment. Trap: beginners choose Deployment because it is more common. The exam will give a scenario where each pod needs its own persistent volume claim.
GKE Ingress: They test the difference between a Kubernetes Ingress (Layer 7 load balancer) and a Service of type LoadBalancer (Layer 4 load balancer). For HTTP-based routing to multiple services, you need an Ingress. For TCP/UDP, you need a LoadBalancer service.
Pod Security Policies and Pod Security Admission: The exam may ask about security contexts, running containers as non-root, and using Google's Container-Optimized OS (COS) for node images.
Common traps in PCD exam questions:
Assuming GKE automatically provides persistent storage for pods (it does not; you must explicitly create PersistentVolumeClaims).
Confusing cluster autoscaling (adds/removes nodes) with horizontal pod autoscaling (adds/removes pods).
Thinking you can use any container image from a public registry without configuring image pull secrets (for private registries, you need a secret).
Believing that GKE supports Windows containers by default (it does, but only on Windows node pools, which are a premium feature).
Key concepts to memorise:
The difference between a StatefulSet and a Deployment.
The three probe types: liveness (is the app alive?), readiness (is it ready for traffic?), startup (has it started?).
The components of a YAML manifest: apiVersion, kind, metadata, spec.
How to expose an app: ClusterIP (internal), NodePort (exposes on each node's IP), LoadBalancer (creates external LB), Ingress (HTTP routing).
A container packages your app and its dependencies so it runs identically on any system, and GKE automates running many containers across multiple computers.
A GKE cluster has a control plane managed by Google and worker nodes (VMs) that run your pods; you only pay for the nodes.
Deployments define the desired number of identical pod replicas, and GKE self-heals by replacing failed pods automatically.
To expose your app to the internet, you must create a Service of type LoadBalancer or an Ingress resource.
Horizontal Pod Autoscaling adjusts the number of pods based on CPU, memory, or custom metrics, while cluster autoscaling adds or removes nodes.
Always use readiness probes to ensure pods only receive traffic when they are truly ready to serve requests.
StatefulSets are for stateful apps like databases that need stable network identities and persistent storage.
These come up on the exam all the time. Here's how to tell them apart.
Deployment
Used for stateless applications where pods are interchangeable.
Pods have random names and no persistent storage by default.
Scaling and updates happen in any order, all pods are identical.
StatefulSet
Used for stateful applications like databases requiring unique identities.
Each pod has a stable hostname and can have its own PersistentVolumeClaim.
Scaling and updates happen in a specific order (e.g., pod-0 then pod-1).
Horizontal Pod Autoscaler (HPA)
Scales the number of pod replicas within a deployment.
Reacts to CPU, memory, or custom metrics.
Does not add or remove nodes; only affects pod count.
Cluster Autoscaler
Scales the number of nodes (VMs) in the cluster.
Reacts to unschedulable pods when there are insufficient node resources.
Works with node pools and can also scale down to save costs.
Service type LoadBalancer
Provides a Layer 4 (TCP/UDP) load balancer with a single external IP.
Each Service gets its own load balancer and IP.
Best for non-HTTP protocols like gRPC or databases.
Ingress
Provides Layer 7 (HTTP/HTTPS) routing with host and path rules.
A single Ingress can route to multiple Services.
Supports TLS termination, URL rewriting, and virtual hosting.
Liveness Probe
Checks if the container is alive and running.
If it fails, Kubernetes restarts the container.
Used to catch deadlocks or infinite loops.
Readiness Probe
Checks if the container is ready to accept traffic.
If it fails, the pod is removed from the Service's endpoints.
Used to prevent sending requests to a pod that is still loading.
ConfigMap
Stores non-sensitive configuration data (e.g., app settings).
Data is stored in plain text (base64 encoded in YAML, but not encrypted).
Can be mounted as environment variables or files.
Secret
Stores sensitive data like passwords, API keys, and SSH keys.
Data is base64 encoded and can be encrypted at rest using Cloud KMS.
Should never be committed to version control without encryption.
Mistake
Kubernetes is the same as Docker.
Correct
Docker is a tool for creating and running containers. Kubernetes is a tool for orchestrating (managing) containers across multiple machines. They work together but are different. GKE uses Kubernetes, and your containers can be built with Docker.
Beginners hear 'containers' and 'Kubernetes' used interchangeably, but Docker is just one way to create containers, and Kubernetes manages them. The exam expects you to know the distinction.
Mistake
Once I deploy an app on GKE, it is automatically accessible on the internet.
Correct
By default, pods have internal IP addresses only. You must explicitly create a Service of type LoadBalancer or an Ingress to make the app accessible from outside the cluster.
The simplicity of 'deploying' can mislead people into thinking GKE automatically exposes the app, but security and networking require manual configuration.
Mistake
GKE automatically backs up my application data.
Correct
GKE only manages containers. Any data written inside a container is lost when the container restarts, unless you attach persistent storage using PersistentVolumeClaims or external services like Cloud SQL. GKE does not back up your data; you must configure backups yourself.
People assume 'managed' means everything is handled, but GKE manages the orchestration, not the data durability of your application.
Mistake
If a pod crashes, GKE automatically deletes it and never restarts it.
Correct
GKE uses Deployments to keep a desired number of replicas running. If a pod crashes, the Deployment controller automatically creates a new pod to replace it. The old pod is deleted only if it fails repeatedly.
This misconception comes from not understanding the declarative model. The Deployment ensures the actual state matches the desired state.
Mistake
You must manually install and upgrade Kubernetes on GKE.
Correct
GKE is a managed service, meaning Google automatically upgrades the control plane for you. You can choose automatic or manual upgrades for node pools, but you never install Kubernetes from scratch.
People familiar with self-managed Kubernetes assume the same effort applies. GKE removes that overhead.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A container is a running instance of your application. A pod is the smallest deployable unit in Kubernetes, which can contain one or more containers that share storage and network. Most commonly, a pod contains a single container.
By default, your app is not accessible from the internet. You must create a Service of type LoadBalancer or an Ingress resource. Use `kubectl get service` to find the external IP address assigned to the LoadBalancer.
GKE automatically detects that the node is unhealthy. The pods that were running on that node are rescheduled onto healthy nodes. The failed node is replaced by a new one if cluster autoscaling is enabled, or manually by Google Compute Engine.
Yes, but you should use a StatefulSet instead of a Deployment. StatefulSets provide stable network identities and persistent storage for each pod. You also need to create PersistentVolumeClaims to allocate storage.
Update your Deployment manifest with the new container image tag, then run `kubectl apply -f deployment.yaml`. GKE performs a rolling update, replacing pods one by one while keeping old pods running until the new ones are healthy.
Deployments are for stateless applications where pods are interchangeable. StatefulSets are for stateful applications where each pod has a unique identity and stable storage. StatefulSets guarantee ordered, graceful deployment and scaling.
You've finished Deploying Apps on Google Kubernetes Engine (GKE). Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?