Thanks Filip for answering those. Its great information. -- Is this documented somewhere ? -- Is there a testing results published somewhere for each release ?
There might be some other considerations like, some flags in 1.3.6 which might have become default in 1.5.2 which would cause the upgrade to not go as expected. Is this documented somewhere so that when we do the upgrade, we must enable those flags in 1.5.2 for everything to work seamlessly. What about protobuf, has the default behavior of that changed ? Sorry about the too many questions :-) Thanks for your help Mayank On Friday, March 3, 2017 at 12:24:47 AM UTC-8, Filip Grzadkowski wrote: > > On Thu, Mar 2, 2017 at 10:34 PM, <[email protected] <javascript:>> wrote: > >> Hi Kubernetes Users and Dev >> >> >> I have a HA cluster with 1.3.6 running. I have three masters, each >> running apiserver, kube-scheduler and controller-manager and etcd running. >> I want to upgrade to 1.5.2 without bringing the cluster down. >> >> I was thinking a couple of ways:- >> >> Method 1: >> >> 1. Bring one master down and upgrade, while maintaining the quorom >> for etcd >> 2. The new master comes up as 1.5.2 while the remaining continue to >> run as 1.3.6 >> 3. In this scenario >> 1. If kubelets running as 1.3.6 try to talk to new master 1.5.2, >> will that work ? >> >> Yes, we support up to 2 minor versions skew (e.g. 1.5 master can work > with 1.3+ kubelets or 1.6 master can work with 1.4+ kubelets) > >> >> 1. Is that supported scenario ? >> >> Yes > >> >> 1. What about kube-proxy ? >> >> It will work. > >> >> 1. Will the api-server running as 1.5.2 be able to talk to kubelets >> >> Yes, though the communication is always initiated by the kubelet. > > >> Method 3: >> >> The other way would be to partition the cluster , and move some minions >> and a single master to new 1.5.2. That is not preferable imo. >> >> Are there other ways people can think of making this work ? >> >> -Mayank >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes developer/contributor discussion" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/kubernetes-dev/6e55f2a7-34d4-40b1-8963-ef8b19eb0b31%40googlegroups.com >> >> <https://groups.google.com/d/msgid/kubernetes-dev/6e55f2a7-34d4-40b1-8963-ef8b19eb0b31%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
