Kubernetes runs containers inside Pods, but production applications should normally be owned by a higher-level workload controller. For a stateless HTTP order service, a Deployment manages interchangeable replicas and a Service provides stable discovery over selected endpoints.
Quick answer
A Pod is the smallest deployable unit and shares lifecycle, networking, and selected storage among its containers. A ReplicaSet maintains a replica population. A Deployment owns ReplicaSets and coordinates declarative updates. A Service selects Pods by labels and publishes stable virtual networking; EndpointSlices represent the discovered backends and readiness conditions. A container restart is not a Pod replacement, and neither event proves the application completed an order correctly.
Learning objectives
- Trace a request from Service selection to a ready Pod while identifying the controller and data owner at every step.
- Diagnose label, selector, readiness, and rollout mismatches without directly operating naked Pods.
Prerequisites
Complete Production Container Images. Use the Cloud-Native Backend course and topic cluster for context.
Declarative workload and stable discovery
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 3
selector:
matchLabels: { app: orders }
template:
metadata:
labels: { app: orders }
spec:
containers:
- name: api
image: registry.example/orders@sha256:reviewed-digest
ports: [{ name: http, containerPort: 8080 }]
---
apiVersion: v1
kind: Service
metadata:
name: orders
spec:
selector: { app: orders }
ports: [{ name: http, port: 80, targetPort: http }]The manifest illustrates ownership and selection only. A deployable manifest also needs resource policy, probes, security context, configuration, identity, shutdown behavior, and environment-specific review.
Production failure scenario
A release changes the Pod label to app: order-api but leaves the Service selector at app: orders. The Deployment becomes Available and every Pod is Ready, yet the Service has no serving endpoints. Recreating Pods cannot repair a selector contract.
Compare Deployment template labels, Service selectors, EndpointSlices, readiness, and request evidence. Correct the declared configuration, wait for endpoints, then verify the customer path. Do not expose Pod IPs as a permanent workaround.
Common misconceptions
- A Pod is replaceable and its IP is not a stable application address.
- A Deployment does not route traffic; a Service and surrounding network path do.
- Desired replicas do not equal Ready or available replicas.
- A running container may still be unready or unable to complete business work.
- Manually deleting Pods changes symptoms but not an incorrect Deployment template.
Decision checklist
- Use controllers for durable workloads and Jobs for bounded completion work.
- Make selectors narrow, intentional, and covered by configuration review.
- Inspect EndpointSlices when Deployment and Service evidence disagree.
- Keep application, sidecar, and init-container lifecycle responsibilities explicit.
- Verify traffic and durable business outcomes after controller convergence.
Continue with Kubernetes Configuration, Secrets, and Workload Identity.
Keep controller ownership and traffic eligibility separate during every operational decision.
Related reading
- Load Balancing Explained separates upstream traffic distribution from Kubernetes Service selection.
- Liveness, Readiness, and Startup Health Checks explains why a running Pod may not be eligible for traffic.
- Kubernetes Probes and Graceful Shutdown follows the endpoint through admission and termination.
Official sources
- Kubernetes Pods, accessed August 18, 2026.
- Kubernetes Deployments, accessed August 18, 2026.
- Kubernetes Services, accessed August 18, 2026.
- Kubernetes EndpointSlices, accessed August 18, 2026.