Deployments
The object you will use every day.
If you remember one Kubernetes object, make it the deployment. It is how most applications are run in real life. It does everything a replica set does, and it adds safe updates, and rollbacks. In this lesson, you will meet it, and understand the layers inside.

- The standard way to run apps
- Adds updates and rollbacks
- Builds on replica sets
Deployment, ReplicaSet, Pods
A deployment is made of layers. At the top is the deployment, which you create. It owns a replica set, which it creates for you. And the replica set owns the pods. You describe the deployment, and Kubernetes builds the layers below it. Why the extra layer? Because when you update the app, the deployment creates a brand new replica set, for the new version, and moves pods across gently. The old replica set stays, ready for a rollback.
- Deploymentmanages versions and updates
- ReplicaSetkeeps N pods alive
- Podsthe running containers
A Deployment in YAML
Here is a deployment, and it should look very familiar. It is almost identical to the replica set. The kind is deployment, and the A P I version is apps slash v one. We ask for three replicas. The selector and the template work the same way. The template says, run the engine X container, version one point twenty seven. Save it as a file, and one apply command is all it takes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27
ports:
- containerPort: 80The three layers
Let's apply it. Now we list the deployment, the replica set, and the pods, all with one command. You can see the deployment, with three of three ready. Below it, the replica set that the deployment created, with a name that starts with the deployment's name. And below that, three pods, whose names start with the replica set's name. The names show who owns whom. This chain is what makes rolling updates possible, as we will see next.
kubectl apply -f deployment.yaml deployment.apps/web created kubectl get deploy,rs,pods NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/web 3/3 3 3 14s NAME DESIRED CURRENT READY AGE replicaset.apps/web-f4dd7dd4f 3 3 3 14s NAME READY STATUS RESTARTS AGE pod/web-f4dd7dd4f-5988g 1/1 Running 0 14s pod/web-f4dd7dd4f-kmpfg 1/1 Running 0 14s pod/web-f4dd7dd4f-q8cn5 1/1 Running 0 14s
File used: deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27
ports:
- containerPort: 80Summary
Wonderful. A deployment owns a replica set, which owns the pods. You describe the deployment, and Kubernetes builds the rest. In the next clip, we use that chain, to update apps without downtime, to roll back mistakes, and to scale.
Key takeaways- Deployment > ReplicaSet > Pods
- Created from one YAML file
- The default way to run apps