kubernetes调度程序是否支持反关联性？

Question

我正在考虑在CoreOS集群之上部署Kubernetes,但我认为我遇到了各种各样的交易破坏者.

如果我只使用CoreOS和fleet,我可以在单元文件中指定我希望某些服务不能在与其他服务相同的物理机器上运行(反亲和力).这对于高可用性至关重要.但它看起来并不像kubernetes有这个功能.

在我的特定用例中,我将需要运行一些需要始终可用的弹性搜索机器集群.如果出于任何原因,kubernetes决定在一台机器上安排给定ES集群的所有弹性搜索节点容器(或者甚至是一台机器上的大多数),并且该机器死机,那么我的elasticsearch集群将随之死亡.这是不允许发生的.

似乎可能有解决方法.我可以设置资源需求和机器规格,这样每台机器上只能安装一个弹性搜索实例.或者我可能以某种方式使用标签来指定某些弹性搜索容器应该在某些机器上运行.我还可以提供比必要更多的机器,以及比必要的更多ES节点,并假设kubernetes将它们分散到足以合理确定高可用性.

但所有这一切似乎都很尴尬.从资源管理的角度来看,只需指定所需的硬件和反关联性,就可以让调度程序从那里进行优化.

那么Kubernetes是否以某种我无法找到的方式支持反亲和力？或者有人知道它是否会很快？

或者我应该考虑另一种方式？我是否必须编写自己的调度程序？

Answer 1

看起来kubernetes有几种方法决定如何传播容器,这些方法正在积极开发中.

首先,当然必须在任何机器上有必要的资源,以便调度程序考虑在那里调出一个pod.

之后,kubernetes通过复制控制器传播pod,尝试将给定复制控制器创建的不同实例保留在不同节点上.

似乎最近实现了一种考虑服务和各种其他参数的调度方法.https://github.com/GoogleCloudPlatform/kubernetes/pull/2906虽然我并不完全清楚如何使用它.也许与此调度程序配置协调？https://github.com/GoogleCloudPlatform/kubernetes/pull/4674

对我来说,最有趣的问题可能是在缩小规模期间没有考虑这些调度优先级,只能扩大规模.https://github.com/GoogleCloudPlatform/kubernetes/issues/4301这有点大不了,似乎随着时间的推移,你可能会发现奇怪的pod分布,因为它们会保留原来的位置.

总的来说,我认为目前我的问题的答案是,这是一个不断变化的kubernetes领域(正如v1之前预期的那样).但是,看起来我需要的很多内容将通过足够的节点自动完成,并正确使用复制控制器和服务.