Is this something in the pipeline for etcd-operator? On Mon, Nov 13, 2017 at 1:15 PM Drew Wells <[email protected]> wrote:
> 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 >> >
