Yeah I believe that would work. I was not sure if the operator created pods supported this. On Mon, Nov 13, 2017 at 12:55 PM Brandon Philips <[email protected]> wrote:
> Hello Drew- > > If you could specify an anti-affinity node selector > <https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity> > would that work? > > Brandon > > On Mon, Nov 13, 2017 at 7:51 PM Drew Wells <[email protected]> wrote: > >> We want to spread etcd deployed by etcd-operator across different AZs. In >> theory, our etcd cluster could then survive a node going down since no more >> than 1 etcd pod would be running on it. >> >> >> As an example, if we have kubernetes nodes in 3 different AZs: AZ1, AZ2, >> AZ3. >> >> Now I create a deployment with size: 3 for etcd. The desired behavior is >> this pods are created: etcd-0001 on AZ1, etcd-0002 on AZ2, and etcd-003 on >> AZ3. Basically, we desire per pod taints that decrease the change an etcd >> pod will be scheduled with a peer on the same node. I've searched through >> the database for a hack to make this happen. It doesn't appear possible to >> do per pod behavior like this. >> >> Are there recommendations for getting better reliability of an etcd >> cluster when a AZ becomes unavailable outside of what's been described in >> this example? >> >> Best, >> Drew >> >> >> >> >> -- > CTO, CoreOS, Inc > Tectonic is enterprise Kubernetes > https://coreos.com/tectonic >
