AI Hints
Home›Kubernetes Tutorial›Namespaces and Deployments
Kubernetes · Lesson 15 of 86

Deployments

The object you will use every day.

⏱ 2 min read▶ Video at 38:27🎓 Free
Watch this lesson in the Kubernetes courseWatch on YouTube ↗Full Kubernetes course

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.

Deployments
From the video: Deployments
  • 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.

  1. Deploymentmanages versions and updates
  2. ReplicaSetkeeps N pods alive
  3. 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.

deployment.yamlyaml
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: 80

The 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
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: 80

Summary

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
Next up: Updates, Rollbacks and Scaling — change apps without downtime