我正在考虑在CoreOS集群之上部署Kubernetes，但我认为我遇到了各种各样的交易破坏者。
如果我只使用CoreOS和fleet，我可以在单元文件中指定我希望某些服务不在与其他服务相同的物理机器上运行（反亲和力）。这对于高可用性至关重要。但它看起来并不像kubernetes有这个功能。
在我的具体用例中，我需要运行一些需要始终可用的弹性搜索机器集群。如果出于任何原因，kubernetes决定在一台机器上安排给定ES集群的所有弹性搜索节点容器（或者甚至是一台机器上的大多数），并且该机器死机，那么我的elasticsearch集群将随之死亡。这是不允许发生的。
似乎可能有解决方法。我可以设置资源需求和机器规格，这样每台机器上只能安装一个弹性搜索实例。或者我可能以某种方式使用标签来指定某些弹性搜索容器应该在某些机器上运行。我还可以提供比必要更多的机器，以及比必要的更多ES节点，并假设kubernetes将它们分散到足以合理确定高可用性。
但所有这一切似乎都很尴尬。从资源管理的角度来看，只需指定所需的硬件和反关联性就可以了，并让调度程序从那里进行优化。
Kubernetes也支持以某种我无法找到的方式反对亲和力吗？或者有人知道它是否会很快？
或者我应该以另一种方式思考这个问题？我是否必须编写自己的调度程序？
答案 0 :(得分：6)
看起来kubernetes决定如何传播容器有几种方法，这些方法正在积极开发中。
首先，当然必须在任何机器上有必要的资源，以便调度程序考虑在那里调出一个吊舱。
之后，kubernetes通过复制控制器传播pod，尝试将给定复制控制器创建的不同实例保留在不同的节点上。
似乎最近实施了一种考虑服务和各种其他参数的调度方法。 https://github.com/GoogleCloudPlatform/kubernetes/pull/2906虽然我并不完全清楚如何使用它。也许与此调度程序配置协调？ https://github.com/GoogleCloudPlatform/kubernetes/pull/4674
对我来说，最有趣的问题可能是在缩小规模期间没有考虑这些调度优先级，只能扩大规模。 https://github.com/GoogleCloudPlatform/kubernetes/issues/4301这有点大不了，似乎随着时间的推移你可能会发现奇怪的豆荚分布，因为它们最初放置的时候都会存在。
总的来说，我认为目前我的问题的答案是，这是一个不断变化的kubernetes领域（正如v1之前预期的那样）。但是，看起来我需要的很多内容将通过足够的节点自动完成，并正确使用复制控制器和服务。
答案 1 :(得分：0)
“反关联性”是指您不希望某些Pod在某些节点上运行。对于目前的情况，我认为可以进行“色差和容忍”。您可以用污点标记节点，然后，只有那些明确具有该污点容忍度的Pod才允许在该特定节点上运行。
下面我将描述如何实现反亲和力概念：
着色任意节点。
kubectl污染节点gke-cluster1-default-pool-4db7fabf-726z env = dev：NoSchedule
在这里，env = dev是key：value对，或者是该节点的标签， NoSchedule是一种效果，它描述了除非具有特定的容忍度，否则不要在此节点上调度任何Pod。
创建部署
kubectl运行newdep1 --image = nginx
向该部署的节点添加与该标签相同的标签，以便此部署的所有Pod都托管在该节点上，并且该节点将不托管没有匹配标签的任何其他Pod。
kubectl标签部署/ newdep1 env = dev
kubectl规模部署/ newdep1 --replicas = 5
kubectl获得豆荚-o宽
运行此命令，您将看到newdep1的所有Pod将在受污染的节点上运行。