What is the difference between a pod and a deployment?

Question

I have been creating pods with type:deployment but I see that some documentation uses type:pod, more specifically the documentation for multi-container pods:

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

But to create pods I can just use a deployment type:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

I noticed the pod documentation says:

The create command can be used to create a pod directly, or it can create a pod or pods through a Deployment. It is highly recommended that you use a Deployment to create your pods. It watches for failed pods and will start up new pods as required to maintain the specified number. If you don’t want a Deployment to monitor your pod (e.g. your pod is writing non-persistent data which won’t survive a restart, or your pod is intended to be very short-lived), you can create a pod directly with the create command.

Note: We recommend using a Deployment to create pods. You should use the instructions below only if you don’t want to create a Deployment.

But this raises the question of what kind:pod is good for? Can you somehow reference pods in a deployment? I didn't see a way. It looks like what you get with pods is some extra metadata but none of the deployment options such as replica or a restart policy. What good is a pod that doesn't persist data, survives a restart? I think I'd be able to create a multi-container pod with a deployment as well.

score 346 · Answer 1 · edited Mar 29 '18 at 18:51

346

Radek's answer is very good, but I would like to pitch in from my experience, you will almost never use an object with the kind pod, because that doesn't make any sense in practice.

Because you need a deployment object - or other Kubernetes API objects like a replication controller or replicaset - that needs to keep the replicas (pods) alive (that's kind of the point of using kubernetes).

What you will use in practice for a typical application are:

Deployment object (where you will specify your apps container/containers) that will host your app's container with some other specifications.
Service object (that is like a grouping object and gives it a so-called virtual IP (cluster IP) for the pods that have a certain label - and those pods are basically the app containers that you deployed with the former deployment object).

You need to have the service object because the pods from the deployment object can be killed, scaled up and down, and you can't rely on their IP addresses because they will not be persistent.

So you need an object like a service, that gives those pods a stable IP.

Just wanted to give you some context around pods, so you know how things work together.

Hope that clears a few things for you, not long ago I was in your shoes :)

edited Mar 29 '18 at 18:51

Castro Roy

7,623
13
63
97

answered Dec 09 '17 at 14:18

Tomislav Mikulin

5,306
4
23
36

1

Nice answer, do we need a replicaSet or a ReplicationController because I tought the Deployment object wraps these objects controlling the replicas? – user_mda Jan 04 '18 at 17:22
3

yes, the Deployment object handles the replicaset, but you could also use an object with the kind: ReplicationController or kind: ReplicaSet on it's own if you really wanted to, but I haven't seen much of that in practice... – Tomislav Mikulin Jan 04 '18 at 18:48
6

Why is it that multiple kubernetes documents give `kind: Pod` as the example? E.g., How to consume Secrets as env vars: https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets – rm.rf.etc Jul 24 '18 at 03:43
1

I'm not quite sure, maybe because its easier to explain concepts in k8..without giving the weight of controllers, deployments etc... – Tomislav Mikulin Jul 24 '18 at 11:33
2

There are some cases when you wants to create pod, for example if you are running a test sidecar (example `helm test`) where you don't need to run application forever, and we don't need multiple replicas, in that case pod is suitable. – Balkrishna Mar 11 '19 at 22:20

score 292 · Accepted Answer · edited Jul 01 '17 at 08:54

292

Both Pod and Deployment are full-fledged objects in the Kubernetes API. Deployment manages creating Pods by means of ReplicaSets. What it boils down to is that Deployment will create Pods with spec taken from the template. It is rather unlikely that you will ever need to create Pods directly for a production use-case.

edited Jul 01 '17 at 08:54

Noah Solomon

1,251
15
23

answered Dec 25 '16 at 23:32

Radek 'Goblin' Pieczonka

21,554
7
52
48

13

Thank you, but when would you ever create pods directly? – Bjorn Dec 26 '16 at 01:20
12

Having a custom controller is one case where you probably want to create and manage pods directly, instead of using one of the higher level abstractions. – Anirudh Ramanathan Dec 26 '16 at 23:34
38

@BjornTipling I create pods without deployment when I don't need kubernetes to re create pods when deleted. One use case is to test things out by creating a pod first. – user2526795 Jun 24 '17 at 08:51
4

More precisely, a Deployment creates a ReplicaSet which then creates a set of identical, steteless, pods, w.r.t. the pod template specified inside the Deployment's yaml file, and the value of the replica field (which defines the size of the pod set). The Deployment can manage multiple ReplicaSets in order to perfom rolling update of the managed pods, so that version of the application is upgraded without interrupting the service – Fabrice Jammes Oct 21 '20 at 14:43

score 132 · Answer 3 · edited May 27 '19 at 19:56

Kubernetes has three Object Types you should know about:

Pods - runs one or more closely related containers
Services - sets up networking in a Kubernetes cluster
Deployment - Maintains a set of identical pods, ensuring that they have the correct config and that the right number of them exist.

Pods:

Runs a single set of containers
Good for one-off dev purposes
Rarely used directly in production

Deployment:

Runs a set of identical pods
Monitors the state of each pod, updating as necessary
Good for dev
Good for production

And I would agree with other answers, forget about Pods and just use Deployment. Why? Look at the second bullet point, it monitors the state of each pod, updating as necessary.

So, instead of struggling with error messages such as this one:

Forbidden: pod updates may not change fields other than spec.containers[*].image

So just refactor or completely recreate your Pod into a Deployment that creates a pod to do what you need done. With Deployment you can change any piece of configuration you want to and you need not worry about seeing that error message.

serkan · Answer 4 · 2019-03-14T11:20:19.083

32

Pod is container instance.

That is the output of replicas: 3

Think of one deployment can have many running instances(replica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

edited Mar 14 '19 at 11:20

answered Mar 14 '19 at 10:40

serkan

6,885
4
41
49

5

The best answer so far. The other answers focus on showing how Deployments are more important concept and that you rarely use Pods on production, but lacks a clear information on how they relate to each other. – Diego Queiroz May 13 '20 at 03:13
So can we name the pod to be one from the deployment's replicas? – kioria May 28 '20 at 18:32
1

@kioria, what do you mean by "deployment's replicas"? – serkan May 28 '20 at 20:05
@serkan i mean this replicas: 3 from the deployment spec. – kioria May 28 '20 at 21:06
1

@kioria, ```replicas: 3``` references to the top part of the image, It means "hey, when you run on this process, create 3 virtual/real computers - instances.". its like "deployments" is a home and the "pods" are persons. One home and three persons inside of it who does the work. What are you trying to do specific to this? – serkan May 29 '20 at 21:33
Can't you create multiple container instances in a pod though? – Dr. Chocolate Oct 13 '20 at 13:33
1

@mutant_city: you very well can, but that defeats the very purpose of a pod. I haven't come across any use case where multiple containers inside one pod were required. – susenj Jul 13 '21 at 16:02
1

it is actually not that uncommon pattern to run multiple containers in a pod. They share namespace and they can also share PID space. They can work much closer together, which is often how the somewhat imprecise "sidecar pattern" is used. Look to service- and event mesh implementations these often use a sidecar to decouple the service and integration details. – user3504575 May 01 '22 at 14:24

fgul · Answer 5 · 2020-04-11T04:16:17.550

I want to add some informations from Kubernetes In Action book, so you can see all picture and connect relation between Kubernetes resources like Pod, Deployment and ReplicationController(ReplicaSet)

Pods

are the basic deployable unit in Kubernetes. But in real-world use cases, you want your deployments to stay up and running automatically and remain healthy without any manual intervention. For this the recommended approach is to use a Deployment, which under the hood create a ReplicaSet.

A ReplicaSet, as the name implies, is a set of replicas (Pods) maintained with their Revision history.

(ReplicaSet extends an older object called ReplicationController -- which is exactly the same but without the Revision history.)

A ReplicaSet constantly monitors the list of running pods and makes sure the running number of pods matching a certain specification always matches the desired number.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

A Deployment

is a higher-level resource meant for deploying applications and updating them declaratively.

When you create a Deployment, a ReplicaSet resource is created underneath (eventually more of them). ReplicaSets replicate and manage pods, as well. When using a Deployment, the actual pods are created and managed by the Deployment’s ReplicaSets, not by the Deployment directly

Let’s think about what has happened. By changing the pod template in your Deployment resource, you’ve updated your app to a newer version—by changing a single field!

Finally, Roll back a Deployment either to the previous revision or to any earlier revision so easy with Deployment resource.

These images are from Kubernetes In Action book, too.

properly explained. By the way are there any practical scenarios to use kind:pod over kind:deployment. Because always it's safe to use deployment since if one goes down one come online. Is there any advantage of using kind:pod ? — Chamith Malinda, Oct 02 '21 at 06:14
In my case, I want to quickly test kind of pulling image or something like that @ChamithMalinda. — Nguyễn Văn Phong, Jul 22 '22 at 08:07

score 12 · Answer 6 · edited Nov 02 '19 at 08:25

Pod is a collection of containers and basic object of Kuberntes. All containers of pod lie in same node.

Not suitable for production
No rolling updates

Deployment is a kind of controller in Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Deployment creates a ReplicaSet which in turn make sure that, CurrentReplicas is always same as desiredReplicas .

Advantages :

You can rollout and rollback your changes using deployment
Monitors the state of each pod
Best suitable for production
Supports rolling updates

score 8 · Answer 7 · answered Jan 31 '22 at 07:32

In Kubernetes we can deploy our workloads using different type of API objects like Pods, Deployment, ReplicaSet, ReplicationController and StatefulSets.

Out of those Pods are the smallest deployable unit in Kubernetes. Any workload/application that runs in Kubernetes, has to run inside a container part of a Pod. A Pod could run multiple containers (meaning multiple applications) within it. A Pod is a wrapper on top of one/many running containers. Using a Pod, kubernetes could control, monitor, operate the containers.

Now using stand alone Pods we can't do lot of things. We can't change configurations, volumes inside Pods. We can't restart the Pod if one is down. So there is another API Object called Deployment comes into picture which maintains the desired state (how many instances, how much compute resource application uses) of the application. The Deployment maintaines multiple instances of same application by running multiple Pods. Deployments unlike Pods are mutable. Deployments uses another API Object called ReplicaSet to maintain the desired state. Deployments through ReplicaSet spawns another Pod if one is down.

So Pod runs applications in containers. Deployments run Pods and maintains desired state of the application.

This is the by far best answer. I don't know why other's answer got a lot of upvotes. — Rashedul Alam, Oct 18 '22 at 12:42

score 4 · Answer 8 · edited Jan 29 '19 at 16:20

4

Try to avoid Pods and implement Deployments instead for managing containers as objects of kind Pod will not be rescheduled (or self healed) in the event of a node failure or pod termination.

A Deployment is generally preferable because it defines a ReplicaSet to ensure that the desired number of Pods is always available and specifies a strategy to replace Pods, such as RollingUpdate.

edited Jan 29 '19 at 16:20

Raunak Jhawar

1,541
1
12
21

answered Jan 29 '19 at 14:14

maelga

848
9
15

score 4 · Answer 9 · answered Dec 27 '20 at 12:45

May be this example will be helpful for beginners !!

1) Listing PODs

controlplane $ kubectl -n my-namespace get pods
NAME                            READY   STATUS    RESTARTS   AGE
mysql                           1/1     Running   0          92s
webapp-mysql-75dfdf859f-9c54j   1/1     Running   0          92s

2) Deleting web-app pode - which is created using deployment

controlplane $ kubectl -n my-namespace delete pod webapp-mysql-75dfdf859f-9c54j
pod "webapp-mysql-75dfdf859f-9c54j" deleted

3) Listing PODs ( You can see, it is recreated automatically)

controlplane $ kubectl -n my-namespace get pods
NAME                            READY   STATUS    RESTARTS   AGE
mysql                           1/1     Running   0          2m42s
webapp-mysql-75dfdf859f-mqrcx   1/1     Running   0          45s

4) Deleting mysql POD whcih is created directly ( with out deployment)

controlplane $ kubectl -n my-namespace delete pod mysql
pod "mysql" deleted

5) Listing PODs ( You can see mysql POD is lost for ever )

controlplane $ kubectl -n my-namespace get pods
NAME                            READY   STATUS    RESTARTS   AGE
webapp-mysql-75dfdf859f-mqrcx   1/1     Running   0          76s

score 1 · Answer 10 · answered Mar 11 '19 at 22:40

In kubernetes Pods are the smallest deployable units. Every time when we create a kubernetes object like Deployments, replica-sets, statefulsets, daemonsets it creates pod.

As mentioned above deployments create pods based on desired state mentioned in your deployment object. So for example you want 5 replicas of a application, you mentioned replicas: 5 in your deployment manifest. Now deployment controller is responsible to create 5 identical replicas (no less, no more) of given application with all metadata like RBAC policy, networks policy, labels, annotations, health check, resource quotas, taint/tolerations and others and associate with each pods it creates.

There are some cases when you wants to create pod, for example if you are running a test sidecar where you don't need to run application forever, you don't need multiple replicas, and you run application when you wants to execute in that case pod is suitable. For example helm test, which is a pod definition that specifies a container with a given command to run.

score -2 · Answer 11 · answered Jul 27 '21 at 12:41

I am also a beginner in k8s so correct me if I am wrong.

We know that a pod is created when we create a deployment. What I observed is that if you see the YAML file of the deployment, you can see its kind:deployment. But if you see the YAML file of the pod, you see its kind:pod.

What is the difference between a pod and a deployment?

11 Answers11

Linked

Related