Ping ?
Any pointers to where this is documented would be useful to show to the 
team  or if it doesnt exist i can open an issue

-Mayank

On Friday, March 3, 2017 at 12:49:53 AM UTC-8, [email protected] wrote:
>
> 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]> 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].
>>> To post to this group, send email to [email protected].
>>> 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.
  • [kubernetes... krmayankk
    • [kuber... 'Filip Grzadkowski' via Kubernetes user discussion and Q&A
      • [k... krmayankk
        • ... krmayankk
          • ... 'Filip Grzadkowski' via Kubernetes user discussion and Q&A

Reply via email to