On May 30, 2016 7:22 AM, "Qian Zhang" <[email protected]> wrote: > > Thanks Matthias! > >> I settled on the latter mostly because it makes reinstalling the apiserver nodes (where configuration changes more frequently) easier by not having to deal with etcd cluster membership at the same time. > > > So you will have to reinstall the whole apiserver node frequently (i.e., all the daemons will be down)? But I think if you need to reconfigure apiserver, you can just restart apiserver daemon and leave etcd in the same node as it is, right?
Of course! I just like getting the nodes into a clean state from time to time, especially since we're still experimenting at times. > >> The main benefit of only using localhost is that you can forego authentication on the client port when not exposing it over the network, this saves you from teaching kube-apiserver about it. On the other hand, this has gotten easier in Kubernetes 1.2. > > > Can you please elaborate this benefit a bit more? How can I forgo authentication on the client port when not exposing it over the network if apiserver and etcd are running in the same node? What if apiserver and etcd are running separately? etcd allows separately enabling TLS authentication on the peer connections (these must go over the network, so you need to secure those either way) and the client connections. You can also choose which interface it binds to separately. So you could only bind the client port to localhost. This is really only a minor simplification in certificate handling, in the end you still need to do it for everything else. I think for your case I would configure etcd and kube-apiserver as if they were running on different nodes (every apiserver knows all etcd) but colocate them until you have a reason to. This way you avoid the shared fate and when the time comes to separate them it will be easy. /MR > > -- > You received this message because you are subscribed to the Google Groups "Containers at Google" 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/google-containers. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Containers at Google" 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/google-containers. For more options, visit https://groups.google.com/d/optout.
