🚀 Containers, Docker, Kubernetes & GKE -Google Cloud
🚀 Complete Notes: Infrastructure → Docker → Kubernetes → GKE → Terraform → Helm
PART 1 — FIRST UNDERSTAND THE BIG PICTURE
Before learning individual terms, remember this architecture:
DEVELOPER │ ↓ Java Code │ ↓ Git │ ↓ CI/CD Pipeline │ ↓ Maven Build │ ↓ JAR │ ↓ Docker Image Build │ ↓ Container Registry (Artifact Registry) │ ↓ GKE │ Kubernetes │ ↓ Deployment │ ↓ Pod │ ↓ Container │ ↓ Java Application
But who creates the infrastructure?
Terraform │ ↓ GCP │ ┌─────────┼─────────┐ ↓ ↓ ↓ VPC IAM GKE │ ↓ Kubernetes
And users access your application through:
User ↓ Internet ↓ Load Balancer ↓ Ingress ↓ Service ↓ Pod ↓ Container ↓ Java Application
PART 2 — WHAT IS INFRASTRUCTURE?
Infrastructure means the resources required to run your application.
For example:
Infrastructure │ ├── CPU ├── RAM ├── Storage ├── Network └── Operating System
Your Java application needs these resources.
Example:
Java Application ↓ Needs CPU Needs RAM Needs Disk Needs Network ↓ Machine / Server
PART 3 — WHAT IS A SERVER?
A server is simply a computer that provides services to other computers.
Example:
User ↓ Internet ↓ Server ↓ Java Application ↓ Response
The server could be:
- Physical machine
- Virtual machine
- Cloud VM
- Kubernetes node
PART 4 — OPERATING SYSTEM
The OS manages the machine's resources and provides an environment for applications.
Examples:
Linux Windows macOS
Structure:
Hardware ↓ Operating System ↓ Applications
The OS manages:
- CPU
- RAM
- Files
- Processes
- Network
- Devices
PART 5 — PROCESS
A process is a program that is currently running.
For example:
app.jar ↓ Java starts ↓ Java process
If your Spring Boot application is running, a Java process is running.
PART 6 — VM
VM = Virtual Machine.
A VM is a virtual computer created on physical infrastructure using virtualization.
Physical Server ↓ Hypervisor ↓ ┌────┼────┐ ↓ ↓ ↓ VM1 VM2 VM3
Each VM can have:
CPU RAM Disk Network Guest OS Applications
PART 7 — HOST VS GUEST
This is important.
Host
The underlying physical machine/infrastructure running the virtualization layer.
Physical Machine ↓ Host
Guest
The VM running on that infrastructure.
Host ↓ VM ↓ Guest OS
Example:
Physical Infrastructure ↓ Hypervisor ↓ VM ↓ Ubuntu Linux ↓ Java App
Ubuntu is the guest OS.
PART 8 — WHY VM IS HEAVY
Each VM generally has its own guest OS environment.
VM 1 ├── Linux ├── Java └── App VM 2 ├── Linux ├── Java └── App VM 3 ├── Linux ├── Java └── App
The OS itself consumes resources.
Starting many VMs can therefore be slower and more resource-intensive.
PART 9 — CONTAINER
A container is an isolated environment for running an application and its dependencies.
Think of:
┌──────────────────────────┐ │ CONTAINER │ │ │ │ Java Application │ │ Java Runtime │ │ Libraries │ │ Dependencies │ │ Application Files │ └──────────────────────────┘ ↓ Host OS Kernel
The key difference:
A container normally shares the host OS kernel instead of carrying a complete guest OS like a VM.
PART 10 — WHY CONTAINERS?
Imagine your Java application requires:
Java 17 Spring Boot Library A v2 Library B v5
Your developer machine has exactly those versions.
But production has:
Java 11 Library A v1
You can get:
"It works on my machine."
Containers help package the application and required runtime/dependencies into a consistent image.
PART 11 — VM VS CONTAINER
VM
Physical Infrastructure ↓ Hypervisor ↓ VM ├── Guest OS ├── Runtime ├── Libraries └── Application
Container
Physical/Virtual Infrastructure ↓ Host OS ↓ Container Runtime ↓ Container ├── Runtime ├── Libraries └── Application
Remember:
VM virtualizes a complete machine environment.
Container provides isolated application/process environments while sharing the host kernel.
PART 12 — DOES CONTAINER PROVIDE INFRASTRUCTURE?
No.
This was one of your earlier confusions.
Container does not create physical CPU/RAM.
Instead:
Container ↓ Host OS ↓ VM / Physical Machine ↓ CPU + RAM + Disk + Network
The container consumes resources from the machine on which it runs.
PART 13 — DOCKER
Docker is a platform/toolset commonly used to build and run containers.
Simple:
Java Application ↓ Docker ↓ Docker Image ↓ Container
Docker helps package your application consistently.
PART 14 — DOCKERFILE
A Dockerfile describes how to build a container image.
Example concept:
FROM eclipse-temurin:17 COPY target/app.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"]
Meaning:
FROM ↓ Start with Java runtime image COPY ↓ Put your JAR into the image ENTRYPOINT ↓ Start Java application
PART 15 — IMAGE
A container image is an immutable package/template from which containers are created.
Example:
payment-service:v10
It can contain:
Java runtime Application JAR Libraries Files Startup configuration
Think:
Image = blueprint/package
Container = running instance
PART 16 — IMAGE VS CONTAINER
Image │ │ run ↓ Container
One image can create multiple containers:
my-app:v1 │ ┌─────────┼─────────┐ ↓ ↓ ↓ Container Container Container 1 2 3
PART 17 — CONTAINER RUNTIME
Something must actually run the container.
That's the job of a container runtime.
Conceptually:
Kubernetes ↓ kubelet ↓ Container Runtime ↓ Container
Modern Kubernetes environments commonly use runtimes such as containerd.
PART 18 — CONTAINER REGISTRY
Where do you store your Docker images?
In a container registry.
Google Cloud provides:
Artifact Registry
Think:
Artifact Registry │ ├── payment:v1 ├── payment:v2 ├── payment:v3 └── backend:v10
It is basically a warehouse for container images.
PART 19 — PUSH VS PULL
Push
You upload an image:
Docker ↓ Image ↓ Artifact Registry
Pull
Kubernetes needs the image:
GKE Node ↓ Container Runtime ↓ Artifact Registry ↓ Pull Image ↓ Create Container
PART 20 — NOW COME MAVEN
For a Java application, Maven builds your application.
Your project:
my-app/ │ ├── src/ │ ├── main/ │ └── test/ │ └── pom.xml
pom.xml contains information such as:
- Project information
- Dependencies
- Plugins
- Java configuration
- Build configuration
- Repository configuration
PART 21 — YOUR MAVEN COMMAND
You mentioned running something like:
mvn clean build -DskipTests deploy
Depending on your Maven setup, you may commonly see:
mvn clean package -DskipTests
and then:
mvn deploy -DskipTests
or a lifecycle command that reaches deploy.
The important thing is understanding the Maven lifecycle.
PART 22 — mvn
mvn
means:
Run Maven.
Maven reads:
pom.xml
and executes the requested lifecycle/phases.
PART 23 — clean
mvn clean
Deletes the previous build output.
Example:
target/ ├── app.jar ├── classes/ └── test-classes/
After clean:
target/
is removed.
Purpose:
Start the build from a clean state.
PART 24 — BUILD / PACKAGE
Maven compiles your Java code.
Conceptually:
Java Source ↓ Compile ↓ .class files ↓ Package ↓ JAR
Example:
target/ └── payment-service-1.0.0.jar
PART 25 — -DskipTests
-DskipTests
means:
Skip test execution.
So:
Compile ↓ Don't run tests ↓ Package
Important distinction:
-DskipTests
usually skips running tests but can still compile test sources.
Whereas:
-Dmaven.test.skip=true
skips test compilation and execution.
PART 26 — MAVEN DEPLOY
This is VERY important.
Maven:
deploy
does not mean:
Run my application in Kubernetes.
It generally means:
Publish the Maven artifact to a remote Maven repository.
Example:
Java ↓ Maven ↓ JAR ↓ Remote Maven Repository
Your organization may use something like:
JFrog Artifactory
PART 27 — WHAT GETS UPLOADED?
Suppose Maven generates:
payment-service-1.0.0.jar
Maven also has project metadata such as the POM.
Conceptually:
Artifactory ↓ payment-service ↓ 1.0.0 ├── JAR ├── POM └── metadata
PART 28 — HOW DOES MAVEN KNOW ARTIFACTORY?
Maven gets repository configuration from places such as:
pom.xml
and/or:
settings.xml
For example, a project may have distribution management configuration pointing to the company's Maven repository.
Credentials are commonly managed through Maven settings or CI/CD credentials.
PART 29 — MAVEN ARTIFACTORY VS CONTAINER ARTIFACT REGISTRY
Don't mix these.
Java artifact
app.jar ↓ Maven repository / Artifactory
Container image
app:v1 ↓ Container Registry / Artifact Registry
They may be different repositories even though both are used to store build artifacts.
PART 30 — NOW KUBERNETES
Kubernetes is:
An open-source platform for orchestrating containerized workloads.
Simple:
Kubernetes manages many containers across many machines.
Without Kubernetes:
Container 1 Container 2 Container 3 ... Container 100
You would have to manage them manually.
Kubernetes automates things such as:
- Scheduling
- Scaling
- Self-healing
- Deployment
- Rolling updates
- Rollbacks
- Service discovery
PART 31 — KUBERNETES CLUSTER
A cluster is a group of machines managed by Kubernetes.
Kubernetes Cluster │ ├── Node 1 ├── Node 2 └── Node 3
PART 32 — NODE
A node is a machine where Kubernetes workloads run.
In GKE, nodes are generally Compute Engine VMs.
GKE Cluster │ ├── Node 1 → VM ├── Node 2 → VM └── Node 3 → VM
Remember:
Node = machine where Pods run.
PART 33 — CONTROL PLANE
The control plane is the brain of Kubernetes.
Conceptually:
Control Plane │ ├── API Server ├── Scheduler ├── Controllers └── Cluster State
It manages the desired state of the cluster.
PART 34 — API SERVER
The Kubernetes API server is the main interface for Kubernetes operations.
When you run:
kubectl get pods
conceptually:
kubectl ↓ Kubernetes API Server ↓ Control Plane
PART 35 — SCHEDULER
Suppose Kubernetes needs to run a new Pod.
New Pod ↓ Scheduler ↓ Which node is suitable? ↓ Node 2
The scheduler considers things such as:
- Available resources
- Requests/limits
- Node constraints
- Affinity/anti-affinity
- Taints/tolerations
- Other scheduling rules
So Kubernetes doesn't simply randomly choose a machine.
PART 36 — POD
This is extremely important.
Pod is the smallest deployable unit in Kubernetes.
Usually:
Pod └── Container └── Java Application
Sometimes:
Pod ├── Main Container └── Sidecar Container
Containers in the same Pod share the Pod's network namespace and can share volumes.
For beginners:
Usually think: one Pod = one main application container.
PART 37 — NODE → POD → CONTAINER
Remember:
Cluster │ ├── Node 1 │ ├── Pod 1 │ │ └── Container │ │ │ └── Pod 2 │ └── Container │ └── Node 2 └── Pod 3 └── Container
PART 38 — DEPLOYMENT
A Deployment manages a desired number/version of Pods through ReplicaSets.
Example:
Deployment ↓ ReplicaSet ↓ Pod 1 Pod 2 Pod 3
If you specify:
replicas: 3
Kubernetes tries to maintain three Pods.
PART 39 — DESIRED STATE
This is one of Kubernetes' most important concepts.
You say:
I want 3 replicas.
Kubernetes continuously works toward:
Desired = 3
Suppose:
Current = 2
Kubernetes works to make:
Current → 3
This process is called reconciliation.
PART 40 — WHAT IF A POD DIES?
You have:
Pod 1 ✅ Pod 2 ❌ Pod 3 ✅
Deployment wants:
3 Pods
Kubernetes creates a replacement:
Pod 1 Pod 3 Pod 4
This is one part of Kubernetes' self-healing behavior.
PART 41 — REPLICA
A replica is another running copy of your application workload.
replicas: 3
means approximately:
Pod 1 Pod 2 Pod 3
More replicas provide more capacity and availability.
PART 42 — SERVICE
Pods are temporary.
A Pod can have:
10.1.0.5
Then it dies.
New Pod:
10.1.0.25
Therefore, don't make applications depend directly on changing Pod IPs.
A Service gives you a stable way to reach a logical group of Pods.
Service backend-service ↓ ┌────────┼────────┐ ↓ ↓ ↓ Pod 1 Pod 2 Pod 3
PART 43 — FRONTEND → BACKEND
Bad idea:
Frontend ↓ Pod IP
Better:
Frontend ↓ backend-service ↓ Pod 1 / Pod 2 / Pod 3
The backend Pods can change without requiring the frontend to track every Pod IP.
PART 44 — LOAD BALANCER
For external traffic:
Internet ↓ Load Balancer ↓ Service ↓ Pods
In GKE, Kubernetes services can integrate with Google Cloud load-balancing infrastructure depending on the Service configuration.
PART 45 — INGRESS
Ingress provides HTTP/HTTPS routing into Kubernetes.
Example:
example.com/ ↓ Frontend Service example.com/api ↓ Backend Service
Conceptually:
Internet ↓ Ingress ├── / → Frontend └── /api → Backend
PART 46 — SCALING
Suppose:
3 Pods
Traffic increases.
High traffic ↓ More Pods ↓ 10 Pods
PART 47 — HPA
HPA = Horizontal Pod Autoscaler.
It can change the number of Pods based on configured metrics.
Conceptually:
CPU increases ↓ HPA ↓ Increase Pods
When demand decreases:
Lower demand ↓ Reduce Pods
PART 48 — NODE AUTOSCALING
Don't confuse Pod scaling with Node scaling.
Pod scaling
3 Pods → 10 Pods
Node scaling
2 Nodes → 4 Nodes
If Pods need more compute capacity than existing nodes can provide, node autoscaling may add nodes.
Remember:
Pods = application workload capacity
Nodes = compute capacity
PART 49 — IMPERATIVE KUBERNETES
You directly tell Kubernetes what action to perform.
Example:
kubectl scale deployment my-app --replicas=5
You are saying:
"Do this action."
PART 50 — DECLARATIVE KUBERNETES
Instead of telling Kubernetes every action, define the desired state.
Example:
replicas: 5
Then:
kubectl apply -f deployment.yaml
You are saying:
"This is what I want. Make the cluster look like this."
Kubernetes continuously works toward that state.
PART 51 — ROLLING UPDATE
Suppose:
v1 v1 v1
You release v2.
Kubernetes can gradually replace old Pods:
v2 v1 v1
then:
v2 v2 v1
then:
v2 v2 v2
This is a rolling update.
PART 52 — ROLLBACK
If v2 is broken:
v2 ↓ Problem ↓ Rollback ↓ v1
Kubernetes Deployment rollout mechanisms can support rollback to a previous revision.
PART 53 — CONFIGMAP
ConfigMap stores non-sensitive configuration.
Example:
ENVIRONMENT=PROD PORT=8080
Application:
Pod ↓ ConfigMap ↓ Configuration
PART 54 — SECRET
Secrets are intended for sensitive configuration values.
For example:
Password Token Credential
Conceptually:
Secret ↓ Pod ↓ Application
In production, organizations often combine Kubernetes Secrets with cloud/external secret-management systems and appropriate access controls.
PART 55 — NAMESPACE
Namespace provides logical separation inside a cluster.
Cluster │ ├── dev │ ├── Pods │ └── Services │ ├── uat │ ├── Pods │ └── Services │ └── prod ├── Pods └── Services
PART 56 — HELM
Helm is a Kubernetes package manager and templating/deployment tool.
Instead of managing many raw YAML files separately:
deployment.yaml service.yaml configmap.yaml ingress.yaml
you can package them into a Helm Chart.
PART 57 — HELM CHART
Example:
my-app/ │ ├── Chart.yaml ├── values.yaml │ └── templates/ ├── deployment.yaml ├── service.yaml ├── configmap.yaml └── ingress.yaml
PART 58 — VALUES.YAML
values.yaml contains configurable values.
Example:
replicas: 3 image: repository: my-app tag: v10
You can have different values for environments:
DEV ↓ replicas = 1 UAT ↓ replicas = 2 PROD ↓ replicas = 5
PART 59 — HELM DEPLOYMENT
A command such as:
helm upgrade --install my-app ./my-chart
conceptually does:
Helm Chart ↓ Helm ↓ Render templates + values ↓ Kubernetes API ↓ Kubernetes Resources ↓ Deployment ↓ Pods ↓ Containers
So your earlier understanding was correct:
Helm communicates with Kubernetes; Kubernetes then creates/manages the workload.
PART 60 — TERRAFORM
Terraform = Infrastructure as Code (IaC).
Definition:
Terraform allows you to define and manage infrastructure using configuration files.
Instead of manually creating:
VPC Subnet GKE IAM Cloud SQL Networking
through the cloud console, Terraform can manage them as code.
PART 61 — TERRAFORM WORKFLOW
Typical flow:
Terraform Code ↓ terraform init ↓ terraform plan ↓ Review changes ↓ terraform apply ↓ Infrastructure created/updated
PART 62 — TERRAFORM VS KUBERNETES
This distinction is VERY important.
Terraform
What infrastructure should exist?
Kubernetes
How should my containerized application run?
Example:
Terraform ↓ VPC GKE IAM Cloud resources ↓ Kubernetes ↓ Deployment ↓ Pods ↓ Containers
PART 63 — TERRAFORM VS HELM
| Terraform | Helm |
|---|---|
| Infrastructure as Code | Kubernetes application packaging/deployment |
| VPC | Deployment |
| GKE | Service |
| IAM | ConfigMap |
| Cloud SQL | Ingress |
| Subnets | Kubernetes resources |
They solve different problems.
PART 64 — GKE
GKE = Google Kubernetes Engine.
GKE is Google's managed Kubernetes service.
Think:
Kubernetes ↓ Google Cloud managed offering ↓ GKE
PART 65 — KUBERNETES VS GKE
Kubernetes
Open-source container orchestration platform.
GKE
Google Cloud's managed Kubernetes service.
Kubernetes = technology GKE = Google Cloud service providing managed Kubernetes
PART 66 — GKE CONTROL PLANE
In GKE, Google manages the Kubernetes control plane.
Conceptually:
GKE │ Google manages Control Plane │ ↓ Nodes ↓ Pods ↓ Containers
You still interact with Kubernetes using tools/APIs such as:
kubectl
PART 67 — GKE AUTOPILOT
Autopilot provides more managed infrastructure.
Google manages more of the underlying cluster infrastructure, such as:
- Node provisioning/configuration
- Autoscaling
- Upgrades
- Baseline security configuration
- Baseline networking configuration
Think:
Autopilot ↓ Google manages more ↓ You manage less infrastructure
PART 68 — GKE STANDARD
Standard mode provides more control over cluster/node configuration.
Think:
Standard ↓ More infrastructure control ↓ More responsibility
Easy memory:
Autopilot = less infrastructure management
Standard = more infrastructure control
PART 69 — NODE POOL
A node pool is a group of nodes with similar configuration.
GKE Cluster │ ├── General Pool │ ├── Node 1 │ └── Node 2 │ └── High-Memory Pool ├── Node 3 └── Node 4
Useful when different workloads need different compute characteristics.
PART 70 — COMPLETE TERRAFORM → GKE FLOW
Infrastructure side:
Terraform ↓ GCP ↓ VPC ↓ Subnet ↓ GKE Cluster ↓ Nodes
Application side:
Java Code ↓ Maven ↓ JAR ↓ Docker ↓ Container Image ↓ Artifact Registry ↓ GKE ↓ Kubernetes ↓ Deployment ↓ Pod ↓ Container ↓ Java Application
PART 71 — COMPLETE REAL-WORLD CI/CD FLOW
This is probably the most useful picture for your actual work.
Developer ↓ Git ↓ Push Code ↓ CI/CD Pipeline ↓ Maven ↓ Compile ↓ Test ↓ Package ↓ JAR ↓ Maven Repository / Artifactory ↓ Docker Build ↓ Docker Image ↓ Artifact Registry ↓ Helm ↓ Kubernetes API ↓ GKE ↓ Deployment ↓ ReplicaSet ↓ Pods ↓ Containers ↓ Java Application
Infrastructure:
Terraform ↓ GCP ↓ Network ↓ GKE ↓ Nodes
PART 72 — REAL USER REQUEST FLOW
Once your application is running:
User ↓ DNS ↓ Load Balancer ↓ Ingress ↓ Service ↓ Pod ↓ Container ↓ Java Application ↓ Response
For example:
https://mycompany.com/api/payment
could conceptually flow:
Internet ↓ Load Balancer ↓ Ingress ↓ payment-service ↓ payment Pod ↓ Java/Spring Boot
PART 73 — WHAT HAPPENS IF POD DIES?
Pod 1 ❌ Pod 2 ✅ Pod 3 ✅
Desired:
3
Kubernetes notices:
Current = 2 Desired = 3
Then:
Create replacement ↓ Pod 4
PART 74 — WHAT HAPPENS IF TRAFFIC INCREASES?
Users increase ↓ Traffic increases ↓ HPA ↓ Pods increase ↓ 3 → 5 → 10
If there isn't enough node capacity:
Pods need more capacity ↓ Node Autoscaling ↓ More Nodes
PART 75 — WHAT HAPPENS WHEN YOU RELEASE V2?
First:
Java Code v2 ↓ Maven ↓ JAR v2
Then:
Docker ↓ image:v2
Then:
Artifact Registry ↓ image:v2
Then Helm/Kubernetes updates the workload:
Deployment ↓ Rolling Update ↓ New Pods ↓ Containers running v2
PART 76 — IF V2 FAILS
v2 ↓ Application problem ↓ Health check fails / deployment issue ↓ Rollback ↓ v1
This reduces the risk of taking the entire application down during a release.
PART 77 — HEALTH CHECKS
Kubernetes can use probes to determine application health.
Important concepts:
Liveness probe
Is the application still alive?
Readiness probe
Is the application ready to receive traffic?
Startup probe
Has the application finished starting?
Conceptually:
Container ↓ Health Checks ├── Startup ├── Readiness └── Liveness
PART 78 — RESOURCE REQUESTS AND LIMITS
You can specify how much CPU/memory a container requests and the maximum it can use.
Conceptually:
Container │ ├── CPU Request ├── CPU Limit ├── Memory Request └── Memory Limit
Request
"I need approximately this much capacity for scheduling."
Limit
"Don't allow me to exceed this configured maximum."
This information also influences scheduling and resource management.
PART 79 — STORAGE
Containers are generally treated as replaceable.
Don't assume data written only into the container filesystem will survive container replacement.
For persistent data:
Pod ↓ PersistentVolumeClaim ↓ Persistent Storage
This becomes important for stateful workloads such as databases.
PART 80 — STATEFULSET
For workloads that need stable identity/storage characteristics, Kubernetes provides StatefulSet.
Examples can include:
Databases Kafka Other stateful workloads
Conceptually:
StatefulSet ↓ Pod-0 Pod-1 Pod-2
Unlike ordinary stateless application Pods, these workloads may require stable identities and persistent storage.
PART 81 — DAEMONSET
DaemonSet is used when you want a Pod on nodes according to the DaemonSet's scheduling rules.
Conceptually:
Node 1 → Agent Node 2 → Agent Node 3 → Agent
Common use cases include node-level agents.
PART 82 — JOB
A Job runs a workload that is expected to complete.
Example:
Database migration ↓ Run once ↓ Complete
PART 83 — CRONJOB
CronJob runs Jobs on a schedule.
Example:
Every day at 2 AM ↓ Run Job ↓ Backup
PART 84 — RBAC
RBAC = Role-Based Access Control.
It controls:
Who can perform what actions on Kubernetes resources?
Example:
Developer ↓ Can view Pods Admin ↓ Can create/delete resources
Principle:
Least privilege.
Give only the permissions required.
PART 85 — SERVICE ACCOUNT
A Kubernetes workload can use a service identity to access resources.
In GKE, this can be integrated with Google Cloud identity mechanisms so workloads can access Google Cloud services without embedding long-lived credentials in the application.
This is an important advanced GKE security topic.
PART 86 — NETWORKING
At an advanced level, learn:
Pod networking Service networking Cluster IP NodePort LoadBalancer Ingress DNS NetworkPolicy VPC Subnets Firewall rules
Basic flow:
User ↓ Load Balancer ↓ Ingress ↓ Service ↓ Pod
Internal application communication:
Frontend Pod ↓ Backend Service ↓ Backend Pod
PART 87 — OBSERVABILITY
Production Kubernetes needs visibility.
Three major areas:
Logs Metrics Traces
Also understand:
Events Alerts Dashboards
You should be able to answer:
Is my application healthy?
Why did a Pod restart?
Why is CPU high?
Why are requests slow?
Why are requests failing?
PART 88 — LOGGING
Application:
Java App ↓ Logs ↓ Cloud logging / logging system
Typical things to investigate:
ERROR Exception Timeout Connection failure HTTP 500 Kafka failure Database failure
PART 89 — METRICS
Examples:
CPU Memory Request count Error rate Latency Pod restarts Node utilization
Example:
CPU = 90% ↓ Investigate
PART 90 — EXPERT LEVEL: RECONCILIATION
Kubernetes is fundamentally based on a desired state + reconciliation model.
You declare:
Desired: 5 replicas image = v10
Kubernetes continuously compares:
Desired State vs Current State
Then controllers take actions to reduce the difference.
This is the heart of Kubernetes.
PART 91 — EXPERT LEVEL: CONTROLLERS
Controllers watch resources and work to make actual state match desired state.
For example:
Deployment ↓ ReplicaSet ↓ Pods
If Pods disappear, the controllers work toward restoring the desired number.
PART 92 — EXPERT LEVEL: LABELS AND SELECTORS
Kubernetes resources use labels to identify workloads.
Example:
app: payment
A Service can select Pods:
app=payment
Conceptually:
Service ↓ Selector: app=payment ↓ Pod 1 → app=payment Pod 2 → app=payment Pod 3 → app=payment
This is how a Service knows which Pods belong to it.
PART 93 — EXPERT LEVEL: DEPLOYMENT → REPLICASET → POD
The hierarchy is important:
Deployment ↓ ReplicaSet ↓ Pods ↓ Containers
When you update the image:
v1 ↓ Deployment update ↓ New ReplicaSet ↓ New Pods ↓ v2 Containers
The old ReplicaSet can remain available for rollout history/rollback depending on configuration.
PART 94 — EXPERT LEVEL: IMAGE PULL
When Kubernetes needs a container:
Pod scheduled to Node ↓ kubelet ↓ Container Runtime ↓ Does image exist locally? ↓ If needed → pull image ↓ Artifact Registry ↓ Image downloaded ↓ Container created ↓ Application starts
PART 95 — EXPERT LEVEL: WHY POD IP CHANGES
Pod:
Pod A IP = 10.1.0.5
Pod dies.
New Pod:
Pod B IP = 10.1.0.9
Therefore:
Don't depend directly on Pod IP
Instead:
Service ↓ Pod
The Service gives stable discovery.
PART 96 — COMPLETE TECHNOLOGY DIFFERENCE
| Technology | Simple meaning |
|---|---|
| Linux | Operating System |
| Server | Computer providing services |
| VM | Virtual computer |
| Container | Isolated application environment |
| Docker | Container build/run tooling |
| Dockerfile | Instructions to build an image |
| Image | Package/template for container |
| Container Runtime | Runs containers |
| Artifact Registry | Stores container images |
| Maven | Builds Java application |
| JAR | Java application package |
| Artifactory | Maven/package repository in many enterprises |
| Kubernetes | Container orchestration |
| Cluster | Group of Kubernetes machines |
| Node | Machine running Pods |
| Pod | Smallest Kubernetes deployable unit |
| Deployment | Manages stateless application rollout/replicas |
| ReplicaSet | Maintains desired number of Pods |
| Service | Stable access to Pods |
| Ingress | HTTP/HTTPS routing |
| HPA | Scales Pods |
| Helm | Kubernetes packaging/deployment |
| Terraform | Infrastructure as Code |
| GKE | Managed Kubernetes on Google Cloud |
PART 97 — YOUR MAVEN → ARTIFACTORY FLOW
When you run:
mvn clean ... deploy
think:
pom.xml ↓ Maven ↓ Clean old target ↓ Compile ↓ Test / skip tests according to flags ↓ Package ↓ JAR ↓ Maven Deploy ↓ Remote Maven Repository ↓ Artifactory
This does NOT automatically mean Kubernetes deployment.
PART 98 — YOUR DOCKER FLOW
Then:
JAR ↓ Dockerfile ↓ docker build ↓ Docker Image ↓ docker push ↓ Artifact Registry
Example:
payment:v10
is now sitting in the registry.
PART 99 — YOUR HELM/GKE FLOW
Then:
Helm Chart ↓ values.yaml ↓ helm upgrade --install ↓ Kubernetes API ↓ Deployment ↓ ReplicaSet ↓ Pods ↓ Container Runtime ↓ Pull image from Artifact Registry ↓ Container ↓ Java Application
PART 100 — TERRAFORM FLOW
Infrastructure:
Terraform ↓ terraform plan ↓ terraform apply ↓ GCP ↓ VPC / Network ↓ GKE ↓ Nodes
Then application deployment happens on that infrastructure.
🏆 FINAL MASTER DIAGRAM
This is the diagram I want you to remember.
DEVELOPER │ ↓ Java Code │ ↓ Git │ ↓ CI/CD Pipeline │ ↓ Maven │ ┌──────────┴──────────┐ ↓ ↓ Compile Tests │ │ └──────────┬──────────┘ ↓ JAR │ ↓ Maven Repository / Artifactory │ ↓ Docker Build │ ↓ Docker Image │ ↓ Artifact Registry │ ↓ Helm Chart │ ↓ Kubernetes API │ ↓ GKE Kubernetes │ ┌───────┴───────┐ ↓ ↓ Control Plane Nodes │ ┌──────────┼──────────┐ ↓ ↓ ↓ Pod Pod Pod ↓ ↓ ↓ Container Container Container ↓ ↓ ↓ Java App Java App Java App
Infrastructure underneath:
TERRAFORM │ ↓ GCP │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ VPC IAM GKE │ ↓ Nodes │ ↓ Pods
User traffic:
USER │ ↓ Internet │ ↓ Load Balancer │ ↓ Ingress │ ↓ Service │ ┌─────────┼─────────┐ ↓ ↓ ↓ Pod Pod Pod ↓ ↓ ↓ Container Container Container ↓ ↓ ↓ Java App
🧠 THE 15 SENTENCES YOU SHOULD MEMORIZE
If you remember only these, you already have the core architecture:
- Server = computer that runs/provides services.
- OS = manages the computer's resources and processes.
- VM = virtual computer with its own guest OS environment.
- Container = isolated environment for running an application.
- Docker = commonly used to build/run container images.
- Image = package/template used to create containers.
- Artifact Registry = stores container images.
- Maven = builds Java applications.
- JAR = packaged Java application.
- Kubernetes = manages containerized applications.
- Node = machine where Kubernetes runs Pods.
- Pod = smallest Kubernetes deployable unit.
- Deployment = maintains application replicas and manages rollout.
- Service = stable way to access a group of Pods.
- Helm = packages/configures/deploys Kubernetes resources.
- Terraform = creates/manages infrastructure as code.
- GKE = Google's managed Kubernetes service.
🎯 THE ONE FLOW TO MEMORIZE FOR YOUR JOB
When someone says:
"Deploy the new Java version to GKE."
Think:
Java Code ↓ Git ↓ Maven ↓ JAR ↓ Docker Image ↓ Artifact Registry ↓ Helm ↓ Kubernetes ↓ GKE ↓ Deployment ↓ ReplicaSet ↓ Pods ↓ Containers ↓ Java Application
And remember:
Terraform → creates/manages infrastructure Maven → builds Java Docker → creates container image Artifactory → stores Maven artifacts Artifact Registry → stores container images Helm → packages/deploys Kubernetes configuration Kubernetes → manages application workloads GKE → Google-managed Kubernetes Pod → runs container(s) Service → provides stable access Ingress/Load Balancer → brings traffic from outside HPA → scales Pods Node Autoscaling → provides more compute capacity
Comments
Post a Comment