# Deploy application

**URL:** https://discuss.kubernetes.io/t/deploy-application/21709
**Category:** General Discussions
**Created:** [October 22, 2022, 1:08pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709 "2022-10-22T13:08:03Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![lelunicu](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/lelunicu/32/3086_2.png) [@lelunicu](https://discuss.kubernetes.io/u/lelunicu)
#### Post date: [October 22, 2022, 1:08pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/1 "2022-10-22T13:08:04Z")

</div>

if in deployment of pods i like to update only application,then how i perform it?  
if in pod yaml i change image name from vers1 to vers2,is this enough?

---

<div class="post-metadata">

### Author: ![xavi](https://avatars.discourse-cdn.com/v4/letter/x/8e8cbc/32.png) [@xavi](https://discuss.kubernetes.io/u/xavi)
#### Post date: [October 22, 2022, 5:18pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/2 "2022-10-22T17:18:05Z")

</div>

Hi lelunicu:

Assuming that:

- you have updated your application code, compile it if necessary and so on
- you have created a container image and tagged it with `vers2`
- you have uploaded the container image to a registry
- your cluster can access the container registry and retrieve the image tagged with `vers2`

> in pod yaml i change image name from vers1 to vers2

And then, execute `kubectl apply -f ${updated-deployment-with-ver2-tag-for-image}.yaml` (and `kubectl` is properly configured to access the cluster and the permissions to do so)…

Yes, that’s enough 😉

The official documentation explains [how to update a deployment and how Kubernetes acts (and on which changes on the pod specification)](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).

Best regards,

Xavi

---

<div class="post-metadata">

### Author: ![lelunicu](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/lelunicu/32/3086_2.png) [@lelunicu](https://discuss.kubernetes.io/u/lelunicu)
#### Post date: [October 23, 2022, 1:49pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/3 "2022-10-23T13:49:40Z")

</div>

in this way the pods run on the same workers(they are not destroyed) and only the application version is updated.

---

<div class="post-metadata">

### Author: ![xavi](https://avatars.discourse-cdn.com/v4/letter/x/8e8cbc/32.png) [@xavi](https://discuss.kubernetes.io/u/xavi)
#### Post date: [October 25, 2022, 6:03pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/4 "2022-10-25T18:03:39Z")

</div>

Hi lelunicu:

Pods (based on the `vers1`) of your image will be destroyed and new pods (based on the image tagged with `vers2`) will be created.

By default, this replacement will be performed using the _rolling update_ strategy; that means that if you have 2 pods running the `vers1`, a new pod with `vers2` will be created, running alonside your 2 `vers1` pods (totaling 3 pods). Once Kubernetes makes sure the `vers2` pod is running ok, it destroys one `vers1` pod (choosen randomly) (2 pods total, 1 `vers1` + 1 `vers2`). The process repeats, until all the `vers1` pods have been destroyed and the `replica` count specified in your deployment file is satisfied (with pods based on your new desired state, that it, based on your `vers2` image)…

Best regards,

Xavi

---

<div class="post-metadata">

### Author: ![lelunicu](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/lelunicu/32/3086_2.png) [@lelunicu](https://discuss.kubernetes.io/u/lelunicu)
#### Post date: [October 27, 2022, 7:42am UTC](https://discuss.kubernetes.io/t/deploy-application/21709/5 "2022-10-27T07:42:03Z")

</div>

hi,  
this mean that the new pod can be scheduled on same worker or different works as in vers 1.

---

<div class="post-metadata">

### Author: ![xavi](https://avatars.discourse-cdn.com/v4/letter/x/8e8cbc/32.png) [@xavi](https://discuss.kubernetes.io/u/xavi)
#### Post date: [October 28, 2022, 5:58pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/6 "2022-10-28T17:58:56Z")

</div>

New pods will be scheduled to the most suitable node (see [Kubernetes Scheduler | Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/)); that means that you cannot know on which node a pod will be scheduled (by default).

There are several mechanisms to _influence_ the Scheduler, like [taints, tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) and affinity. If you **really** need to [schedule your pods in a certain node](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/), you can tag the node and then, in your Deployment, specify **affinity** to the tag.

Best regards,

Xavi

---

<div class="post-metadata">

### Author: ![lelunicu](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/lelunicu/32/3086_2.png) [@lelunicu](https://discuss.kubernetes.io/u/lelunicu)
#### Post date: [November 1, 2022, 2:25pm UTC](https://discuss.kubernetes.io/t/deploy-application/21709/7 "2022-11-01T14:25:50Z")

</div>

is there any possibility when upgrade application- only application to up upgraded and pod are not recreated?i mean application run in the initial pod.

---

<div class="post-metadata">

### Author: ![xavi](https://avatars.discourse-cdn.com/v4/letter/x/8e8cbc/32.png) [@xavi](https://discuss.kubernetes.io/u/xavi)
#### Post date: [November 3, 2022, 6:51am UTC](https://discuss.kubernetes.io/t/deploy-application/21709/8 "2022-11-03T06:51:23Z")

</div>

HI Ielunicu:

Maybe, but I don’t think so.

A container is just a process (literally, you can see running containers using `ps`)

```bash
ps aux | grep docker
root 1839 0.1 0.4 1528480 78452 ? SNsl 07:34 0:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root 2954 0.0 0.0 1222052 2944 ? SNl 07:34 0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3000 -container-ip 172.17.0.2 -container-port 3000
root 2975 0.0 0.0 1222308 3204 ? SNl 07:34 0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 3000 -container-ip 172.17.0.2 -container-port 3000
root 2979 0.0 0.0 1222308 3116 ? SNl 07:34 0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 51413 -container-ip 172.20.0.2 -container-port 51413
root 3028 0.0 0.0 1296040 3204 ? SNl 07:34 0:00 /usr/bin/docker-proxy -proto udp -host-ip 0.0.0.0 -host-port 51413 -container-ip 172.20.0.2 -container-port 51413

```

Think of a container as an _ **universal flag** _ that you can add to any application; so, the application running in a container is just your regular application but with this imaginary `--isolated` flag added. That `--isolated` flag makes the application run without being aware of any other process running in the same host (that’s the isolation level provided by the container).

When you create the container image, you define the `entrypoint` as the process to run “inside” the container; **if this process stops, the container also stops**.

If your application can be upgraded without being restarted, then yes, it can be _updated in-place_, but most applications need to be restarted for changes to take effect…

Best regards,

Xavi
