Understand Kubernetes Pods, Deployments and Services by Their Jobs

A practical approach

Step 1

Ask 'what runs my container?' The answer is a Pod, which you rarely create directly.

Step 2

Ask 'how many copies run, and how do they update?' The answer is a Deployment with replicas and a rolling update strategy.

Step 3

Ask 'how do other components find it?' The answer is a Service that selects Pods by label.

Step 4

Ask 'where does configuration come from?' The answer is ConfigMaps for settings and Secrets for credentials, injected as environment variables or files.

Step 5

Ask 'is it healthy?' Define readiness probes so traffic reaches only ready Pods, and liveness probes so stuck containers are restarted.

Worked example

A team deploys an API by creating a single Pod. When the node it runs on is drained for maintenance, the API disappears until someone recreates it. Replacing the Pod with a Deployment of three replicas, a Service in front and a readiness probe on a health endpoint keeps the API available during maintenance and during each release's rolling update.

A mistake to avoid

Do not use liveness probes that check external dependencies such as the database. If the database has a brief problem, every Pod fails liveness and restarts at once, turning a short outage into a longer one. Check dependencies in readiness instead.

Try it yourself

Using a local cluster, deploy a small web container with a Deployment of two replicas and a Service. Delete one Pod and watch the Deployment replace it, then change the image tag and watch a rolling update with kubectl rollout status.

Your implementation checklist

• Applications run through Deployments, not bare Pods
• Services provide stable access to Pods
• Configuration and secrets are separate from images
• Readiness and liveness probes have different purposes
• I can watch and roll back a rollout