Kubernetes Pods, Deployments and Services Explained
Three Kubernetes objects form the foundation of every application deployment: Pods, Deployments, and Services. Understanding how they work together is essential for running applications on Kubernetes.
Pods
A Pod is the smallest deployable unit in Kubernetes. It represents a group of one or more containers that share: - Network namespace (same IP address, same ports) - Storage volumes - Lifecycle (created and destroyed together)
Most pods contain a single container. Multi-container pods are used for sidecar patterns (logging agents, proxy sidecars, etc.).
Pods are ephemeral. When a pod is deleted or its node fails, Kubernetes does not restart the same pod. Instead, a controller creates a new pod to replace it. This is why Pods are almost never created directly; they are managed by Deployments.
Deployments
A Deployment manages a set of identical pods through a ReplicaSet. It declares: - How many replicas (copies) should be running - Which container image to use - Resource requests and limits - Update strategy
When you update a Deployment (change the image tag, modify environment variables), Kubernetes performs a rolling update by default: new pods are created gradually while old pods are terminated. If something goes wrong, you can roll back to the previous version.
Key Deployment features: - Declarative updates: describe the desired state, Kubernetes makes it happen - Scaling: change the replica count to scale up or down - Rollback: return to a previous revision if needed - Pause and resume: pause a rollout to inspect intermediate states
Services
A Service provides a stable network endpoint (IP address and DNS name) that routes traffic to a set of pods. Since pods get new IP addresses when replaced, a Service ensures clients always have a consistent address to connect to.
Service Types
ClusterIP (default): accessible only within the cluster. Used for internal service-to-service communication.
NodePort: exposes the service on a specific port on every node in the cluster. External traffic can reach the service through any node's IP and the NodePort.
LoadBalancer: provisions an external load balancer (in cloud environments) that routes traffic to the service. This is the standard way to expose services to the internet.
Service Discovery
Kubernetes provides automatic DNS-based service discovery. A service named my-app in namespace default is reachable at my-app.default.svc.cluster.local. Other pods can simply connect to my-app if they are in the same namespace.
How They Work Together
A typical deployment: 1. Create a Deployment that runs 3 replicas of your web application container 2. Create a Service that load-balances traffic across those 3 pods 3. Create an Ingress (optional) that routes external HTTP traffic to the Service
When a pod crashes, the Deployment controller creates a replacement. The Service automatically includes the new pod in its load balancing. Clients are unaffected.
Practical Example
A web application Deployment: - 3 replicas of the web server container - Each container requests 256 MB RAM and 0.5 CPU - Rolling update strategy: max 1 unavailable, max 1 surge
A Service: - Type: ClusterIP - Routes port 80 to the pod's port 8080 - Selects pods with label app: my-web-app
Best Practices
- Always use Deployments, not bare Pods
- Set resource requests and limits on every container
- Use readiness probes so Services only route to ready pods
- Use liveness probes so Kubernetes restarts unhealthy containers
- Label pods consistently for Service selector matching
Conclusion
Pods, Deployments, and Services are the building blocks of Kubernetes applications. Pods run containers, Deployments manage pod lifecycle and scaling, and Services provide stable networking. Mastering these three objects enables you to deploy and manage production applications on Kubernetes.