I can run a Pod directly, so why is it considered "best practice" to use a Deployment? Also, since Pods are ephemeral and their IP addresses change, how does a Service provide a stable entry point for my users? I'm trying to understand how these three abstractions work together to provide high availability.
3 answers
A Pod is the smallest unit (containing one or more containers), but you never manage them directly because they are disposable. A Deployment manages the lifecycle of Pods, handling Scaling and Rolling Updates. If a Pod dies, the Deployment replaces it. A Service then provides a stable DNS name and IP, load-balancing traffic to the current set of healthy Pods.
Think of it this way: The Pod is the worker, the Deployment is the manager ensuring enough workers are present, and the Service is the receptionist who directs customers to an available worker. Without the Service, your frontend wouldn't know which of the shifting Pod IPs to talk to.
For networking, the Service uses "Labels" and "Selectors." It doesn't care about the Pod's name; it only cares if the Pod has the label app: my-web-app. This decoupled architecture is what makes Kubernetes so flexible and resilient to individual container failures.
Just be careful with your Selectors! If two different Deployments use the same label accidentally, your Service will start load-balancing traffic between two different versions of your app.
This separation of concerns allows for "Zero Downtime Deployments." You can update the version in the Deployment, and it will swap Pods one by one while the Service continues to route traffic to whichever ones are ready.