我看在CoreOS集群的顶部部署Kubernetes，但我觉得我碰到了各种各样的大忌。
如果我只用CoreOS和车队，我可以，我想某些服务不相同的物理机其他服务（反关联性）上运行单元文件中指定。这是高可用性的排序是必不可少的。但它看起来并不像kubernetes有这个功能呢。
在我的具体使用情况，我将需要运行需要始终可用elasticsearch机的几簇。如果由于某种原因，kubernetes决定安排我所有的elasticsearch节点容器对于给定的ES集群的一台机器上，（甚至大部分在一台计算机上），并且机模具，然后我elasticsearch集群将与它死。这不能被允许发生。
好像有可能的变通。我就可以建立的资源需求和机器的规格，使得只有一个elasticsearch实例可以适合每一台机器上。或者，我大概可以使用标签以某种方式来指定某些elasticsearch容器应该在某些机器上。我也可以只提供方式更多的机器不是必需的，多方式的节点ES超过必要，并承担kubernetes会蔓延出来足以成为合理确定的高可用性。
但所有这一切似乎很尴尬。这是更优雅的从资源管理的角度来看，只是指定所需的硬件和反关联性，并让调度从那里优化。
因此，没有Kubernetes支持在某种程度上我找不到反关联性？或有没有人知道这会不会很快任何时候？
或者，我应该考虑这个法子？我必须写我自己的调度？
看起来有一些kubernetes决定如何传播容器的一些方法，而这些都是积极的发展。
首先，当然也必须是任何机器上所必需的资源调度考虑造就了荚那里。
在此之后，通过kubernetes控制器的复制传播荚，试图保持不同节点上给定的复制控制器中创建不同的实例。
好像有最近被执行调度是考虑服务和其他各种参数的方法。 https://github.com/GoogleCloudPlatform/kubernetes/pull/2906虽然我并不完全清楚究竟上如何使用它。也许，在这个调度配置协调？ https://github.com/GoogleCloudPlatform/kubernetes/pull/4674
也许最有趣的问题对我来说是没有任何这些调度优先级被缩小，只有规模化过程中考虑。 https://github.com/GoogleCloudPlatform/kubernetes/issues/4301这是一个有点大不了的，好像随着时间的推移，你可以，因为他们留荚怪异的分布等。无论他们原本放置。
总体来说，我认为答案给我此刻的问题是，这是kubernetes的地区，是在不断变化（如与V1之前的预期）。然而，它看起来像很多我需要将有足够的节点，并正确使用复制控制器和服务的自动完成的。
反关联性是当你不希望某些荚某些节点上运行。对于目前的情况下我觉得玷污和TOLERATIONS可以来得心应手。你可以用一个污点标记节点，然后，只有明确有宽容对于那些污点荚将要允许特定节点上运行。
下面我描述如何反关联性的概念来实现：
这里，ENV = dev为关键：值对或者更确切地说，此节点的标签，NoSchedule是描述不安排此节点上的任何吊舱的影响，除非与特定容忍。
运行这个你会看到newdep1的所有吊舱将您的污点节点上运行。