Kubernetes Deployment vs. Service: Replacing Pods and Providing a Stable Endpoint

Calling a Pod's IP directly may work at first, then fail after a rollout or recovery. Pods are replaceable units of execution. Deployments and Services handle different parts of that change.

A Deployment declares the desired running state

A Deployment maintains the desired number of Pods through a ReplicaSet. A Service routes requests to ready endpoints with the matching app=web label. It does not create or replace Pods.

A Deployment manages which container image to run, how many replicas to keep, and how to roll out updates. If a Pod dies, the controllers can create a replacement. During a new release, the Deployment can replace Pods gradually. The application must report its startup and readiness state accurately so it does not receive traffic too early.

For example, set app: web on the Deployment's Pod template and declare two replicas. The controllers will work to maintain that state. When a Pod is replaced, its individual IP may change. That is why clients should not store Pod IPs as stable addresses.

A Service selects Pods by label and provides a stable name

A Service uses a selector to choose target Pods and provides a stable DNS name and virtual IP inside the cluster. If its selector does not match the labels on the Deployment's Pods, the YAML may apply successfully while the Service has no target endpoints. Check this relationship during deployment verification.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

The Deployment's Pod label and the Service selector both use app: web, so the resources are connected. The default Service type is for access within the cluster; this example alone does not expose the application to the internet. In a cluster where you applied these resources, use kubectl get pods --show-labels to inspect Pod labels and kubectl get endpointslices -l kubernetes.io/service-name=web to inspect the selected endpoints. If the Service has no endpoints, compare labels and selectors first. If endpoints exist but requests fail, check readiness and targetPort.

Key takeaways

A Deployment manages the Pod lifecycle and updates; a Service supplies a stable network endpoint in front of replaceable Pods. Do not treat a Pod IP as a stable contract. Check labels, selectors, and readiness together. Applying the resource definitions does not, by itself, prove that the traffic path works.