I don't think there's a reason not to arrange things like you say. Our scripts do what they do on account of simplicity. As far as possible post-hoc rationalizations go, added network latency may be an issue, but you'd have to measure.
(The old etcd client we were using had limitations but I think we've switched over some time ago now.) On Mon, May 30, 2016 at 12:20 AM, Matthias Rampke <[email protected]> wrote: > > 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. > -- 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.
