Ah! I hadn't considered baremetal. Thanks for clarifying! :-) On Thu, Aug 31, 2017 at 7:52 AM Matthias Rampke <m...@soundcloud.com> wrote:
> > Assumes I used pre-baked images > > There's your answer. Also, doing this for ~ 300 nodes on bare metal where > we can't trivially get double the capacity is a very long and arduous > process. Draining each node takes a while alone, even if reprovisioning > were infinitely fast. And most upgrades actually don't need it. > > Sure, I would love to live in an immutable world where I just provision a > new datacenter and tear down the old one, but right now I don't. > > /MR > > On Thu, Aug 31, 2017 at 2:41 PM Mark Maglana <m...@maglana.com> wrote: > >> I don't have an answer but I'm curious why one would need to do this. I >> was thinking that if an upgrade is needed, I'd just drain the node, kill >> it, then bring up a totally new machine with the latest version of kubelet >> and kube-proxy I want to use. (Assumes I used pre-baked images). >> >> On Tue, Jul 25, 2017 at 8:11 AM Matthias Rampke <m...@soundcloud.com> >> wrote: >> >>> Hey, >>> >>> I could not find an easy answer for this, and I suppose it's a bit of a >>> niche question – what's the correct ordering to upgrading kubelet / >>> kube-proxy on live nodes? >>> >>> Usually (except for the upgrade onto 1.6) we just upgrade either of them >>> and restart, then the other, all the while the node is running production >>> pods. For 1.6, I'm actually draining the nodes for kubelet but not >>> kube-proxy. Because of reasons, it's difficult for me to upgrade both at >>> the same time. >>> >>> 1) is upgrading the two separately supported at all? >>> 2) is upgrading either of them without draining the node supported? >>> 3) if it is, which way should I do it? does a new kubelet support an >>> older kube-proxy, or the other way around? >>> >>> Thanks, >>> MR >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kubernetes user discussion and Q&A" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>> To post to this group, send email to kubernetes-users@googlegroups.com. >>> Visit this group at https://groups.google.com/group/kubernetes-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-users+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
