4

我正在考虑在 CoreOS 集群上部署 Kubernetes，但我认为我遇到了某种交易破坏者。

如果我只使用 CoreOS 和fleet，我可以在单元文件中指定我希望某些服务不与其他服务在同一物理机器上运行（反关联）。这对于高可用性来说是必不可少的。但是看起来 kubernetes 还没有这个功能。

在我的特定用例中，我将需要运行一些需要始终可用的弹性搜索机器集群。如果出于任何原因，kubernetes 决定将给定 ES 集群的所有 elasticsearch 节点容器安排在单台机器上（或者甚至大部分在单台机器上），并且该机器挂掉了，那么我的 elasticsearch 集群将随之挂掉. 不能允许这样的事情发生。

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

但这一切似乎都很尴尬。从资源管理的角度来看，只需指定所需的硬件和反关联性，并让调度程序从那里进行优化，这要优雅得多。

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

或者我应该以另一种方式思考这个问题？我必须编写自己的调度程序吗？

4

2 回答 2

6

看起来 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 之前所预期的那样）。但是，看起来我需要的大部分工作将通过足够的节点自动完成，并正确使用复制控制器和服务。

于 2015-03-07T19:59:18.150 回答
0

Anti-Affinity 是指您不希望某些 pod 在某些节点上运行。对于目前的情况，我认为 TAINTS AND TOLERATIONS 可以派上用场。您可以用污点标记节点，然后，只有那些明确容忍该污点的 pod 才会被允许在该特定节点上运行。

下面我将描述如何实现反亲和概念：

  1. 污染任何你想要的节点。

    kubectl 污点节点 gke-cluster1-default-pool-4db7fabf-726z env=dev:NoSchedule

在这里， env=dev 是键：值对，或者更确切地说是该节点的标签，NoSchedule 是描述不在该节点上调度任何 pod 的效果，除非具有特定的容忍度。

  1. 创建部署

    kubectl 运行 newdep1 --image=nginx

  2. 将与该节点的标签相同的标签添加到此部署中，以便此部署的所有 pod 都托管在此节点上，并且此节点将不会托管任何其他没有匹配标签的 pod。

    kubectl 标签部署/newdep1 env=dev

    kubectl 规模部署/newdep1 --replicas=5

    kubectl 获取 pods -o 宽

运行这个，你会看到 newdep1 的所有 pod 都将在你的受污染节点上运行。

于 2019-02-07T13:40:53.267 回答