🧩 Part 2: Pods, Deployments, and Services — Understanding the Core Building Blocks of Kubernetes
In Part 1, we explored why Kubernetes exists and how to start your journey as a User or Administrator.
Now, let’s dive into the core components that make Kubernetes work — the ones you’ll interact with daily.
By the end of this post, you’ll understand how applications are actually deployed, connected, and scaled inside a Kubernetes cluster.
🧱 Pods — The Smallest Unit in Kubernetes
Everything in Kubernetes starts with a Pod.
A Pod is the smallest deployable unit — an abstraction over a container.
Usually, one Pod runs one application (for example, a single container running Nginx or your backend app).
🔹 Key Points
Each Pod gets its own internal IP address.
Pods can communicate with each other using these IPs.
These are internal cluster IPs, not public.
Pods are ephemeral — if a container crashes, Kubernetes recreates the Pod automatically.
When a Pod is recreated, it gets a new IP address.
This creates a challenge 👇
If your application is connecting to a database Pod using its IP address, the connection breaks whenever the database Pod restarts (because the IP changes).
To solve this, Kubernetes introduces the concept of Services.
🌐 Services — Stable Networking in Kubernetes
A Service provides a permanent, stable IP address and DNS name to connect to Pods, even when the Pods are recreated.
Think of a Service as a virtual load balancer inside your cluster.
🔹 Key Points
Services route traffic to Pods based on labels.
The Service IP remains the same, even if Pods behind it are replaced.
The lifecycle of a Pod and a Service are independent.
Services can be internal or external.
🧭 Types of Services
ClusterIP (default): Used for internal communication (e.g., app → database).
NodePort: Exposes an application on each Node’s IP for basic external access.
LoadBalancer: Integrates with cloud load balancers for production use.
So, your frontend app might use a NodePort or LoadBalancer Service, while your database stays behind a ClusterIP Service for security.
🌍 Ingress — Gateway to the Outside World
Services handle traffic inside the cluster, but what if you want users to access your app via a browser like myapp.example.com?
That’s where Ingress comes in.
An Ingress acts as a reverse proxy and load balancer.
It sits at the edge of your cluster and routes HTTP/HTTPS traffic to the correct Service based on domain name or URL path.
🔹 Example Use Case
api.example.com→ API Serviceweb.example.com→ Frontend Service
Ingress controllers (like Nginx or Traefik) manage this routing efficiently, enabling SSL termination, path-based routing, and better scalability.
⚙️ Deployments — Managing Pods at Scale
Now, what happens if your application Pod crashes or needs an update?
If you rely on a single Pod, users experience downtime.
To prevent that, Kubernetes uses Deployments.
A Deployment defines a blueprint for Pods — how many replicas to run, what image to use, and how updates should happen.
Kubernetes ensures the actual cluster state matches this desired blueprint.
🔹 Key Points
Deployments manage ReplicaSets, which maintain the desired number of Pods.
Enable rolling updates (zero-downtime upgrades).
Support rollbacks if something goes wrong.
Automatically reschedule Pods on healthy nodes.
⚙️ Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v1
ports:
- containerPort: 80
With this, Kubernetes will always ensure 3 Pods are running — even if one fails.
🗄️ StatefulSets — Managing Stateful Applications (like Databases)
Deployments work great for stateless apps — web servers, APIs, etc.
But what about databases? They need stable identities and persistent storage.
If a database Pod restarts, it can’t just get a random new name or IP — otherwise data consistency breaks.
That’s where StatefulSets come in.
A StatefulSet manages Pods that maintain state across restarts.
🔹 Key Features
Each Pod gets a unique, stable hostname (like
db-0,db-1).Pods are created and terminated in order (important for clusters like MongoDB, Cassandra, MySQL replication).
Works with Persistent Volume Claims (PVCs) to keep data safe.
⚙️ Example
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: mysql
replicas: 2
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
Each replica gets its own persistent volume, keeping its data even if the Pod restarts.
🔐 ConfigMaps, Secrets, and Volumes
Real applications also need configuration, credentials, and persistent data.
🧩 ConfigMaps
Used to store non-sensitive configuration data like environment variables, URLs, and file paths.
🔐 Secrets
Used for sensitive data like passwords, API keys, or tokens.
(Automatically base64-encoded for security.)
💾 Volumes
Used for persistent storage so that data survives Pod restarts.
Volumes can come from local disks, NFS, or cloud storage providers (EBS, Azure Disk, etc.).
Together, these three components make your Kubernetes application configurable, secure, and persistent.
🧭 Wrapping Up
By now, you’ve seen how all these pieces fit together:
Ingress → Service → Deployment/StatefulSet → Pods → Containers
↓
ConfigMaps / Secrets / Volumes
Each component plays a specific role:
Pods — run your app.
Deployments — scale and manage Pods.
Services — give stable networking.
Ingress — exposes your app to the outside world.
StatefulSets — manage databases and stateful workloads.
ConfigMaps, Secrets, Volumes — handle configs, credentials, and data.
🚀 What’s Next
In Part 3, we’ll go deeper into Kubernetes Architecture —
understanding how the Control Plane, API Server, Scheduler, Controller Manager, and Kubelet work together behind the scenes to make everything function seamlessly.
This is where we move from using Kubernetes to truly understanding how it works internally.
Follow for more:
#Kubernetes #DevOps #CloudNative #Containers #CKA #LearningPathContainers #CloudNative #CKA #LearningPath
