Running a container is not enough if an application needs several copies, must survive a failed node, and needs updates without replacing every copy at once. A Kubernetes Deployment is an API object for a continuously running workload. It contains a Pod template—the definition of the application containers—and a desired replica count. Kubernetes works to keep that many Pods running. section 1.2.1 section 5.1
A Pod is the unit Kubernetes schedules onto a node; a Deployment manages a group of those Pods. A Service has a different job: it provides a network endpoint for Pods. Together, a Deployment and Service let an application run in multiple instances and receive traffic without treating a particular Pod as permanent. section 3.1.2 section 3.5
Listing 3.1 Chapter03/3.2_DeployingToKubernetes/deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: timeserver
spec:
replicas: 3 #1
selector:
matchLabels:
pod: timeserver-pod
template:
metadata:
labels:
pod: timeserver-pod
spec:
containers:
- name: timeserver-container
image: docker.io/wdenniss/timeserver:1 #2
This minimal apps/v1 Deployment manifest names the workload, requests three replicas, and defines a Pod template with a container image. Its selector matches the template’s Pod label. section 3.2.3
A basic deploy-and-update workflow is:
- Upload a container image to a repository, then set its image path in the Deployment YAML. section 3.2.3 section 3.5
- Submit the manifest with `kubectl create -f deploy.yaml`; use `kubectl apply -f deploy.yaml` when applying changes. section 3.2.3
- Check `kubectl get deploy` for READY, UP-TO-DATE, and AVAILABLE counts, and `kubectl get pods` for the individual instances. section 3.2.3 section 3.2.7
- Change the image tag in the manifest and apply it again. Kubernetes replaces old-version Pods with new-version Pods; by default, it rolls them out rather than replacing all of them at once. section 3.2.7
The replica count is a desired state, not just a one-time creation instruction. If a node fails, Kubernetes attempts to place a replacement Pod on a healthy node. Placement still depends on available resources: a Pod that cannot fit can remain Pending. Health checks also matter during rollouts; configure them to avoid serving traffic from an instance that is not ready. section 5.1 section 3.2.7
Deployments also suit continuously running background task queues. They differ from Jobs, which suit work with an end state, such as one-off or periodic batch tasks. Blue/green rollout is another distinction: it can use two Deployments and switch a Service between them, but Kubernetes Deployments do not provide blue/green rollout directly. section 10.0 section 4.2.3
