Architecting with Google Kubernetes Engine: Foundations
Architecting with Google Kubernetes Engine: Foundations is a Google Cloud course that teaches you how to run containerized applications using Kubernetes on Google Cloud. It is the first course in the GKE learning series.
By Google Cloud Training
Learn cloud infrastructure, containers, and Kubernetes architecture.
What you will learn
1. Introduction to Google Cloud
Cloud computing and Google Cloud Platform (GCP)
Regions, zones, and resource hierarchy
Compute Engine and other compute options
Cloud Console and Cloud Shell
2. Containers and Kubernetes
What containers and Docker images are
Building container images with Cloud Build
Storing images in a registry
Why Kubernetes is used
3. Kubernetes architecture
Pods and Nodes
Control plane and worker nodes
Deployments, ReplicaSets, and Services
Creating a GKE cluster and deploying applications
Topics summarized from the official course outline.
Understand it with a simple example
Suppose you have a Spring Boot application.
Spring Boot application
Your Java code
Docker container image
Package your application and dependencies
Kubernetes on GKE
Deploy, restart, and scale application instances
Users access your application
For example, if your application receives more traffic, Kubernetes can run more replicas to handle the load.
Where should you start?
Learn basic Docker concepts.
Understand Pods, Nodes, Deployments, and Services.
Learn GCP regions, zones, and projects.
Practise creating a GKE cluster and deploying a sample application.
Continue to the Google Skills course.
Lesson 1: Understand the big picture
Before learning commands, understand what problem Kubernetes and GKE solve.
Imagine you're building an online shopping application with:
React for the frontend.
Spring Boot for the backend.
MySQL for the database.
Initially, you might run everything on one computer. But when thousands of users start accessing your application, you need reliable servers, networking, deployment, scaling, and recovery when something fails.
Here is the progression:
Your application -Java code, frontend, dependencies
Docker / container image -Package the application consistently
Kubernetes -Orchestrates containers across machines
Google Kubernetes Engine -Google Cloud's managed Kubernetes service
The key idea is that these are different technologies with different responsibilities. Docker packages an application; Kubernetes orchestrates containerized workloads; GKE provides managed Kubernetes infrastructure on Google Cloud.
Lesson 2: Five concepts you must understand first
1. Cloud computing
Cloud computing gives you access to computing resources without having to own the physical machines.
For example, if you need a server for your Spring Boot application, you can rent a virtual machine using Google Cloud Compute Engine.
2. Virtual machine (VM)
A virtual machine is a software-based computer running on physical hardware.
Each VM can have its own operating system, CPU allocation, memory, and disk.
Example: you create an Ubuntu VM, install Java, and run:
java -jar application.jarYour application now runs on that virtual machine.
3. Container
A container packages an application and its required dependencies so it can run consistently in different environments.
For example, your Spring Boot application might need Java 21. Rather than manually installing the correct Java version everywhere, you can package the application in a container image with the required runtime.
4. Kubernetes
Kubernetes is an open-source system for managing containerized applications.
It helps you:
Run multiple application instances.
Restart containers when they fail.
Scale workloads up or down.
Distribute workloads across machines.
Expose applications through networking services.
5. Google Kubernetes Engine (GKE)
GKE is Google's managed Kubernetes service.
Instead of setting up and maintaining the entire Kubernetes control plane yourself, Google manages that part of the service. You still configure workloads, permissions, networking, scaling, and other relevant infrastructure.
Lesson 3: Regions, zones, projects, and billing
These are foundational Google Cloud concepts.
Term | Meaning | Example |
|---|---|---|
Region | Geographical area | Mumbai: |
Zone | Deployment area within a region |
|
Project | Logical boundary for resources and configuration |
|
Billing account | Account used to pay for eligible resource usage | Company's cloud billing account |
IAM | Identity and Access Management | Control who can create a cluster |
Remember: a project is not a server, and a region is not a Kubernetes cluster. A project can contain many resources, including clusters, virtual machines, databases, and storage.
Section 2: Introduction to Containers and Kubernetes
In this section, we'll learn how an application goes from Java source code to a container that can run on Google Kubernetes Engine (GKE).
I'll use a Spring Boot application as our running example. The concepts also apply to Node.js, Python, and other applications.
2.1 First, understand the problem
Imagine you've developed a Spring Boot application on your laptop.
It works perfectly on your machine, but when you deploy it to another server, it fails.
Why?
Your laptop has Java 21, but the server has Java 17.
A required library or configuration is missing.
The operating system or environment behaves differently.
The server has different environment variables.
This is a common software deployment problem.
The solution: containers. They help package an application with its runtime and dependencies so it behaves more consistently across environments.
2.2 What is Docker?
Docker is a platform and ecosystem for building, distributing, and running containers.
Think of Docker as a way to package your application into a standardized unit.
Spring Boot source code
Java classes, controllers, services
Docker image
Application + runtime + required dependencies
Laptop
Server
GKE
The same image can be run in different compatible environments.
Docker is not Kubernetes. Docker helps you build and run containers; Kubernetes manages containerized workloads across a cluster of machines.
2.3 The four terms you must know
These terms are essential for the rest of the course.
1. Application
Your actual program, such as a Spring Boot REST API.
2. Dockerfile
A text file containing instructions for building a container image.
3. Image
A packaged, versioned template used to create containers.
4. Container
A running instance of an image, with its own isolated process environment.
A simple analogy:
Dockerfile: Recipe.
Image: Prepared package.
Container: Running instance created from that package.
One image can be used to run multiple containers.
2.4 Install Docker and understand the workflow
To practise locally, install Docker Desktop for Windows, then start it.
Open a terminal and run:
docker --version
docker run hello-worldThe second command downloads the hello-world image if necessary, creates a container, and runs it. If successful, Docker prints a confirmation message.
If Docker isn't installed yet, you can still learn the concepts below before running the commands.
2.5 Build your first container image
Let's create a tiny Java application so you can see how the whole process works.
First, create a file named Main.java:
public class Main {
public static void main(String[] args) {
System.out.println("Hello from Docker!");
}
}Now create another file in the same directory named Dockerfile (without a file extension):
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY Main.java .
RUN javac Main.java
CMD ["java", "Main"]Let's understand every line.
Instruction | Meaning |
|---|---|
| Selects a base image with Java 21. |
| Sets the working directory inside the image. |
| Copies the Java file into the image. |
| Compiles the Java program while building the image. |
| Specifies the default command when the container starts. |
Now run these commands in the directory containing both files:
# Build an image named my-java-app
docker build -t my-java-app:v1 .
# Create and run a container
docker run --rm my-java-app:v1Expected output:
Hello from Docker!What happened?
Docker read the Dockerfile.
Docker created an image containing the Java runtime and compiled program.
Docker created a container from that image.
The container ran the Java program.
The program finished, and
--rmremoved the stopped container.
Important: my-java-app:v1 is an image name with a version tag. The image and container are not the same thing.
2.6 What happens when you build an image?
A Docker image consists of layers. Instructions such as FROM, COPY, and RUN can contribute layers to the image.
Example image structure
Application layer
Compiled Java program
Application build layer
Files copied and compiled during the build
Base image
Java runtime and operating-system components
Simplified illustration; the actual layer structure depends on the Dockerfile and base image.
Why are layers useful?
Docker can reuse cached layers when rebuilding an image.
Images can share common base layers.
You can distribute a versioned image rather than manually installing the application on every server.
For production Spring Boot applications, teams often use multi-stage builds or build tools to create smaller, more secure runtime images.
2.7 How do you distribute an image?
Suppose you've built an image on your laptop. How does GKE get it?
You generally push the image to a container registry.
A registry is a service that stores and distributes container images.
Google Cloud provides Artifact Registry for this purpose.
Your laptop
Build the Docker image
Artifact Registry
Store the image in Google Cloud
GKE
Pull the image and run it in a Pod
The process is:
Build the image.
Push it to a registry.
Configure your Kubernetes workload to reference the image.
Kubernetes arranges for the image to be pulled and the container to run.
An image name might look like this:
asia-south1-docker.pkg.dev/my-project/my-repo/my-java-app:v1Here:
asia-south1is the Artifact Registry region.my-projectis your Google Cloud project ID.my-repois the repository name.my-java-appis the image name.v1is the version tag.
These are example values, not an existing registry you can use directly.
2.8 What is Google Cloud Build?
So far, we built the image using Docker on our own computer.
But in a real company, you may want Google Cloud to build your image automatically when you update your application.
That's where Cloud Build comes in.
Cloud Build is a service that can execute build steps, such as compiling code, running tests, and building container images.
For example:
Developer pushes code
Updated Spring Boot application
Cloud Build
Build and test the application; create an image
Artifact Registry
Store the new image version
GKE deployment
Deploy the selected image version
This is the foundation of a CI/CD workflow:
CI (Continuous Integration): Automatically build and test code changes.
CD (Continuous Delivery/Deployment): Prepare or automatically release changes to an environment, depending on the pipeline configuration.
Cloud Build does not automatically deploy every image to GKE just because the image was built. You must configure the deployment step or connect an appropriate release workflow.
2.9 Containers versus virtual machines
This is a common interview and assessment question.
Feature | Virtual machine | Container |
|---|---|---|
Contains | Guest operating system and application | Application and required dependencies |
Typical size | Larger | Usually smaller |
Startup | Often slower | Often faster |
Isolation | Virtualized hardware and OS boundary | OS-level process isolation |
Common use | Full server environments | Portable application workloads |
Containers are not automatically more secure than VMs; both require proper configuration and security controls.
A container usually shares the host's kernel, while a VM runs its own guest operating system. That is one reason containers often have lower overhead.
2.10 Why do we need Kubernetes?
Imagine your Spring Boot application is running in a container.
Initially, one container serves 100 users. Then traffic increases to 10,000 users. You may need more application replicas.
You could start containers manually, but then you must also manage:
Which machine runs each container.
What happens when a container crashes.
How users reach the correct application instance.
How to increase or decrease replicas.
How to update the application without disrupting service.
Kubernetes automates much of this coordination.
Example: Three application replicas
Pod 1
App replica
Pod 2
App replica
Pod 3
App replica
Kubernetes maintains the desired number of replicas when configured to do so and when sufficient resources are available.
A Pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share certain resources, such as networking.
We'll explore Pods, Deployments, Services, and Nodes in detail in Section 3.
2.11 Section 2 revision
Remember this complete workflow:
Write code: Create a Spring Boot application.
Build an image: Use Docker or an image-building tool.
Store the image: Push it to Artifact Registry.
Deploy: Tell Kubernetes which image to run.
Operate: Kubernetes manages the desired state of your workloads.
Use GKE: Run Kubernetes on Google Cloud with a managed control plane.
Useful official resources:
Section 2 quiz
Test yourself
5 questions
1. What is the difference between an image and a container?
2. Which Google Cloud service stores container images?
3. What is the primary purpose of Cloud Build?
4. What is a Pod?
5. Why do we use Kubernetes?
Comments
Post a Comment