A Pod runs one or more tightly coupled containers with shared networking and storage. A Deployment declares and updates a replicated set of Pods through ReplicaSets. A Service selects Pods by labels and gives clients a stable network endpoint. Together they separate replaceable instances from desired state and discovery.
Who this is for: Developers and new platform operators who need to deploy and troubleshoot stateless applications on an existing Kubernetes cluster.
- Treat Pods as replaceable instances and place long-lived desired state in controllers.
- Make selectors and labels a reviewed contract because they connect Services and Deployments.
- Use readiness, rollout status, and endpoints to verify that new Pods can receive traffic safely.
Use Pods as the execution unit
Containers in one Pod share an IP address, port space, and attached volumes. Put containers together only when they need a shared lifecycle or very close cooperation, such as an application and a purpose-built helper. Ordinary services that scale independently belong in separate Pods. A Pod's name and address can change whenever it is replaced.
The Pod specification defines images, commands, ports, resources, health probes, volumes, identity, and security context. Kubernetes schedules the Pod onto a node that can satisfy its requests and constraints. A bare Pod is rarely appropriate for a long-running application because no workload controller recreates it after deletion or manages revisions.
Declare application state with Deployments
A Deployment describes the desired replicas and Pod template for a stateless workload. Its controller creates a ReplicaSet, which maintains the requested Pod count. Changing the template creates a new revision and normally performs a rolling update according to availability and surge settings. Scaling the Deployment changes replica count without changing application identity.
Use resource requests, readiness probes, and a rollout strategy that preserves enough serving capacity. Follow rollout status rather than assuming an accepted API object means success. Keep revision history suitable for operational needs and understand that rolling back a Deployment changes its Pod template, not external database migrations or other stateful side effects.
Provide discovery through Services
A Service selects Pods, usually through labels, and exposes them through a stable virtual address and DNS name. Clients send requests to the Service rather than tracking Pod addresses. Service types determine whether the endpoint stays cluster-internal, uses node ports, or integrates with an external load balancer. Exact behavior depends on cluster networking and cloud integration.
Selectors must match intended Pod labels exactly. If they match nothing, the Service has no ready endpoints. If they match too broadly, traffic can reach the wrong workload. Inspect endpoint data during troubleshooting. Readiness normally controls whether a Pod appears as an eligible endpoint, which connects health design directly to traffic delivery.
Operate the trio as one system
Begin diagnosis from the user's path: Service DNS, port mapping, endpoints, Pod readiness, container status, logs, and application response. Compare the Service target port with the container's listening port. Check labels on actual Pods rather than only the manifest. Use read-only inspection before restarting anything, because restarts can erase useful evidence.
Apply manifests through reviewed automation and use namespaces, service accounts, network policy, and admission controls established by the platform team. Do not paste privileged examples into a shared cluster. Test changes in a non-production namespace, include resource limits and disruption behavior, and keep a route for reverting the image or manifest revision.
Deploy a small notes API
A team needs three replaceable API instances reachable at one internal name while updating without dropping all capacity.
- Create a Deployment with three replicas, a reviewed image digest, resource requests, and readiness plus liveness probes with different purposes.
- Label the Pod template app=notes-api and create a cluster-internal Service whose selector uses that exact label.
- Map the Service port to the application's listening port and verify ready endpoints before sending a test request from another Pod.
- Update the image in a test namespace, watch rollout status and endpoint counts, then verify rollback on a deliberately failing readiness check.
Kubernetes workload connection map
Review these fields together because a valid object can still be disconnected from the others.
- Namespace, Deployment name, replica target, Pod-template labels, image digest, and service account.
- Resource requests and limits, ports, readiness, liveness, startup behavior, and graceful termination.
- Service name, type, selector, service port, target port, DNS consumer, and expected endpoints.
- Rollout surge, unavailable capacity, disruption expectation, revision history, and rollback boundary.
- Inspection commands, test request, logs, events, endpoint evidence, and responsible owner.
Common mistakes
- Creating a long-running bare Pod and expecting Kubernetes to maintain replicas or revisions.
- Changing a label on the Pod template without updating the Service selector that depends on it.
- Treating a successful manifest submission as evidence that the rollout became ready.
Try one
A Deployment reports three available Pods, but requests to its Service time out and the Service has no endpoints. What should you inspect first?
A strong answer compares the Service selector with labels on the actual Pods, then checks readiness and port mapping. It inspects endpoints, events, and application listening behavior before changing resources. The likely issue is the contract between objects, so deleting healthy Pods is not a justified first action.
Sources
- Kubernetes Pods documentationOfficial Kubernetes reference for the smallest deployable workload unit and its shared resources.
- Kubernetes Deployments documentationOfficial Kubernetes guidance for declarative application rollout, scaling, and revision management.
- Kubernetes Services documentationOfficial Kubernetes explanation of stable network endpoints and Service discovery for Pods.