# Update pods without having to rescale? (warning: complete newb here) **URL:** \ **Category:** General Discussions\ **Created:** [August 14, 2020, 3:04pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391 "2020-08-14T15:04:46Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![seisethanight](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/seisethanight/32/5691_2.png) [@seisethanight](https://discuss.kubernetes.io/u/seisethanight)\ **Post date:** [August 14, 2020, 3:04pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/1 "2020-08-14T15:04:46Z")
Asking for help? Comment out what you need so we can get more information to help you! ### Cluster information: Google Cloud Kubernetes A devops person setup a workload in Google CLoud Platform and I’m pretty ignorant of how all this stuff works. Most I understand is there is a workload, a yaml file, and pods that have to exist to allow the application to run. It’s a web application and I know how to do IP safe-listing in the ngnix part of Google to access the application. Where I’m stumped here is the vendor is requesting just automatically update the pods anytime they do an update from Dockerhub repository. So in GCP Kubernetes I see it connects to Dockerhub using a credential. What I’m not sure on is besides running these two commands, how can I get them to just auto-update? kubectl scale deployment WebApp --replicas=0 -n WebApp kubectl scale deployment WebApp --replicas=2 -n WebApp The vendor said it’s fine to not worry about a bad build in the super rare even that might happen, given the nature and low severity of the application. ---
**Author:** ![thockin](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/thockin/32/2457_2.png) [@thockin](https://discuss.kubernetes.io/u/thockin)\ **Post date:** [August 14, 2020, 4:53pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/2 "2020-08-14T16:53:50Z")
You have 2 main choices. The better choice is to use immutable labels on your images (i.e. not “latest”). Then you update your Deployment to use the new label. It will do a rolling update of the pods. The less ideal choice is to use the same label and either scale-to-zero and back (as you did) or change a label or something in the Deployment to trigger an update (make sure you set PullPolicy to “Always”). ---
**Author:** ![seisethanight](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/seisethanight/32/5691_2.png) [@seisethanight](https://discuss.kubernetes.io/u/seisethanight)\ **Post date:** [August 14, 2020, 7:18pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/3 "2020-08-14T19:18:01Z")
@thockin Thank you for taking time to reply. So for the new label name approach, that means anytime on Docker Hub they update the image, I still need to go manually trigger an update on the Kubernetes side? Or you mean I configure the workload to use :latest and tell the vendor to simply give new images a new name and it will automatically update on the Kubernetes side? What if I created some type of scheduled task that ran the commands like each night instead? ---
**Author:** ![thockin](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/thockin/32/2457_2.png) [@thockin](https://discuss.kubernetes.io/u/thockin)\ **Post date:** [August 14, 2020, 7:55pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/4 "2020-08-14T19:55:08Z")
Do you REALLY want your deployments updating without a human in the loop? If so (scary!) then yeah, you need something to tell k8s to start a redeployment, either a build-time trigger or periodic or something ---
**Author:** ![seisethanight](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/seisethanight/32/5691_2.png) [@seisethanight](https://discuss.kubernetes.io/u/seisethanight)\ **Post date:** [August 14, 2020, 9:46pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/5 "2020-08-14T21:46:45Z")
That’s the funny thing. I’m typical IT and keep thing simple so this is a new world for me. Can imagine my confusion when I’m told to do this by a Docker enthusiast, and then advised not to by my fellow advisors on the Kubernetes forums. So I’m not sure what I _want_ because I don’t know if this is normal or not. Not sure if an image build is something that typically happens every day, or every month or what – out there in DevOps/containerization land. ---
**Author:** ![thockin](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/thockin/32/2457_2.png) [@thockin](https://discuss.kubernetes.io/u/thockin)\ **Post date:** [August 14, 2020, 10:53pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/6 "2020-08-14T22:53:03Z")
Well, as someone concerned with reproducibility, mutable labels scare me. As someone who is also lazy, I occasionally use them myself, but a) I know exactly how it can go wrong (having had mysql eat itself) and b) I know my use-cases are not critical (mysql was down for 3 weeks before I noticed). There is no “normal”, there are only your own requirements. If you want unattended upgrades to :latest, you should be able to set `imagePullPolicy: Always` and do daily `kubectl rollout restart...`. But when it breaks, there’s no rollback 🙂 ---
**Author:** ![seisethanight](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/seisethanight/32/5691_2.png) [@seisethanight](https://discuss.kubernetes.io/u/seisethanight)\ **Post date:** [August 14, 2020, 11:17pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/7 "2020-08-14T23:17:51Z")
Thanks Yeah my understanding with this particular application is that rollback isn’t even really a thing/option, because the latest image – whatever they’re pushing out – contains essential necessary stuff and up to date information… or something like that. So I believe, if that is the case and it’s bad, they just simple have to update their image AGAIN to fix whatever broke, and we let Kubernetes just pick it up AGAIN – right? Or you’re saying it could potentially “break” Kubernetes, putting _me_ in a bad situation? ---
**Author:** ![thockin](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/thockin/32/2457_2.png) [@thockin](https://discuss.kubernetes.io/u/thockin)\ **Post date:** [August 14, 2020, 11:34pm UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/8 "2020-08-14T23:34:52Z")
Nah, you won’t break Kubernetes, just the app. ---
**Author:** ![seisethanight](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/seisethanight/32/5691_2.png) [@seisethanight](https://discuss.kubernetes.io/u/seisethanight)\ **Post date:** [August 15, 2020, 1:18am UTC](https://discuss.kubernetes.io/t/update-pods-without-having-to-rescale-warning-complete-newb-here/12391/9 "2020-08-15T01:18:14Z")
Thanks and this is the only Kubernetes thing in our environment. We have dozens of other things but they run in full VMs or are externally hosted SaaS Apps. I don’t want that to deter me from learning more about how this really Works though since I know it’s the future. Can you recommend like an idiots guide to all of this stuff? A “don’t ask a fish about water” type of take on learning this for a beginner who’s more Ops side not a developer?