<p>The 'best approach' in a theory (coming from the perspective of k8s) would be GitOps: Cloud-native Continuous Deployment.
Your question lack some important information, how are you doing your deployments right now ? Do you have some limitations in terms of security and auditability ?</p>
<p>Sharing my personal 2 cents, using GitOps with ArgoCD outsource and guarantees the continious-running of all of your
workloads(pods as an example). Argo will take care for them, even if somebody deletes a pod, it will re-store the previous number of pods, essentially maintaining the desired vs real state. Another benefit is that you could really easily track your appps by version, commit, tag ... you could even roll-back(this works only under a specific circumstance). Going in an example,
by simply changing the image inside a pod spec in a directory that Argo keeps track of it is enough for the new version to be
roll out as safe as possibble.</p>
<p>In our case we have a separate service (it's just a repo with tags) that acts as a wrapper for all the services, once we have a new release we deploy under a pattern of a directory layout and Argo catches it, everything is re/deployed automatically. The UI is great and they even expose a REST API.</p>
<p>Now once you have Argo(or some other tool), you get additional efforts in tracking the releases of the tool, versions, backward-comptability, helm metadata support, security, access, password rotations, best way to drop Argo in the cluster ... but this is another story that comes
naturally, once you decide to go this path.</p>

CC BY-SA 4.0
2021-10-02T20:01:34.430Z
2021-10-02T20:01:34.430Z
Recoba20
<p>Still the most proper way is to update tags of your docker image and update <code>yourapp.yaml</code> script , there's no other way and then just <code>kubectl -f yourapp.yaml</code>. For this purpose GitOps is used. For me who has small cluster using something as ArgoCD is too much. I've went with Gitlab free service called AutoDevops which deploys read and tested docker container straight to your EKS.</p>

CC BY-SA 4.0
2021-10-03T01:14:06.970Z
2021-10-03T01:14:06.970Z
holms
<p>We are using <a href="https://github.com/stakater/Reloader" rel="nofollow noreferrer">https://github.com/stakater/Reloader</a> The work of the reloader is that when someone update the configmap/secrets then it will keep watch the deployment and it will automatically restart the deployments. This is the best way we have find out till now</p>

CC BY-SA 4.0
2021-10-01T18:06:16.350Z
2021-10-01T18:06:16.350Z
Chaitanya Saxena
<p>We are using CircleCI to automate the building of images when merges are detected on our release branch. Those images are then being pushed to ECR, but I am unsure of the best way to refresh some or all of the pods running the outdated images, and additionally how to do it in a way that does not disrupt service, ie: rolling restarts etc.</p>
<p>We are looking into using Flux for this, but I'm not sure if that is the best approach.</p>
<p>I was hoping to get some insight from people running this or similar pipelines in production.</p>

CC BY-SA 4.0
2021-10-01T06:43:40.727Z
[ Container team member here ] I am not posting this as an answer because I am not a "running this" but I observe mixed patterns among people: those that want to use a GitOps style use Flux/Flux2 (or Argo) to do this (e.g. they configure Flux to monitor for image tag changes". Those that use traditional CD use whatever tools/mechanism the CI/CD platform offers (e.g. [this](https://shadow-soft.com/jenkins-pipeline-containerized-applications-kubernetes/) is an example of many)
mreferre
CC BY-SA 4.0
2021-10-01T20:33:15.713Z
Our approach - store image metadata on Reliza Hub, then Reliza Hub serves as a database which has information about approved images per each environment. Then you are able to query it with whatever tooling you choose and pull right image to the right environment.
taleodor
<kubernetes><continuous-deployment><continuous-delivery><eks><aws-ecr>
What is the idiomatic way to reload EKS/Kube configs when a new image is pushed to ECR
errata
# What is the idiomatic way to reload EKS/Kube configs when a new image is pushed to ECR

(Asked by: username_0 on 2021-09-30)

We are using CircleCI to automate the building of images when merges are detected on our release branch. Those images are then being pushed to ECR, but I am unsure of the best way to refresh some or all of the pods running the outdated images, and additionally how to do it in a way that does not disrupt service, ie: rolling restarts etc.

We are looking into using Flux for this, but I'm not sure if that is the best approach.

I was hoping to get some insight from people running this or similar pipelines in production.

**Tags:** kubernetes, continuous-deployment, continuous-delivery, eks, aws-ecr

> **Comments:**
> **username_1**: [ Container team member here ] I am not posting this as an answer because I am not a "running this" but I observe mixed patterns among people: those that want to use a GitOps style use Flux/Flux2 (or Argo) to do this (e.g. they configure Flux to monitor for image tag changes". Those that use traditional CD use whatever tools/mechanism the CI/CD platform offers (e.g. [this](https://shadow-soft.com/jenkins-pipeline-containerized-applications-kubernetes/) is an example of many)  
> **username_2**: Our approach - store image metadata on Reliza Hub, then Reliza Hub serves as a database which has information about approved images per each environment. Then you are able to query it with whatever tooling you choose and pull right image to the right environment.  

---

## 3 answers

### Answer by username_3 on 2021-10-02. Score: 2

The 'best approach' in a theory (coming from the perspective of k8s) would be GitOps: Cloud-native Continuous Deployment.
Your question lack some important information, how are you doing your deployments right now ? Do you have some limitations in terms of security and auditability ?

Sharing my personal 2 cents, using GitOps with ArgoCD outsource and guarantees the continious-running of all of your
workloads(pods as an example). Argo will take care for them, even if somebody deletes a pod, it will re-store the previous number of pods, essentially maintaining the desired vs real state. Another benefit is that you could really easily track your appps by version, commit, tag ... you could even roll-back(this works only under a specific circumstance). Going in an example,
by simply changing the image inside a pod spec in a directory that Argo keeps track of it is enough for the new version to be
roll out as safe as possibble.

In our case we have a separate service (it's just a repo with tags) that acts as a wrapper for all the services, once we have a new release we deploy under a pattern of a directory layout and Argo catches it, everything is re/deployed automatically. The UI is great and they even expose a REST API.

Now once you have Argo(or some other tool), you get additional efforts in tracking the releases of the tool, versions, backward-comptability, helm metadata support, security, access, password rotations, best way to drop Argo in the cluster ... but this is another story that comes
naturally, once you decide to go this path.


---

### Answer by username_4 on 2021-10-03. Score: 0

Still the most proper way is to update tags of your docker image and update `yourapp.yaml` script , there's no other way and then just `kubectl -f yourapp.yaml`. For this purpose GitOps is used. For me who has small cluster using something as ArgoCD is too much. I've went with Gitlab free service called AutoDevops which deploys read and tested docker container straight to your EKS.


---

### Answer by username_5 on 2021-10-01. Score: 0

We are using <https://github.com/stakater/Reloader> The work of the reloader is that when someone update the configmap/secrets then it will keep watch the deployment and it will automatically restart the deployments. This is the best way we have find out till now


---

