Kubernetes集群合并以最小化集群

Question

这应该是我的学士论文的主题。目前，我正在寻找文献或一般信息，但我找不到。您是否有关于此主题的更多信息？我想找出在集群上运行开发阶段和测试阶段而不是自己运行每个阶段是否有意义。

如果这是一个好主意，我还想知道如何合并集群。

Answer 1

这是一个很好的问题。实际上，这是一个非常大的话题，总之Yes和No您可以为所有环境设置一个集群。

但是通常，每个人都需要在将所有环境合并到一个集群中之前考虑各种事情。其中一些功能包括，在k8上运行的服务数量，作为Ops拥有的可无故障管理和维护现有集群的工程师数量，使用该集群的不同团队的位置（如果考虑延迟） ）。

将所有内容合并为一个有很多优点和缺点。

1. 优点包括易于管理和维护的小型集群，您可以使用标签分散节点，并在dev节点上部署具有dev标签的应用程序，依此类推。但是，如果您不让k8通过限制Pod的部署来做出决定，那么这也会浪费资源。如果我们进行辩论，人们可以在这个话题上争论几个小时。

2. 资源精简，假设您在prod上有一个由3个节点和3个主节点组成的群集，类似地，在dev上有2个节点和3个主节点的群集，在测试中有2个节点和3个主节点的群集。当您分配9个主服务器时，成本很高，如果将合并的开发人员和测试合并为1个，您将节省3个VM的成本。

对于许多组织中的许多DevOps工程师来说，

3. K8都是非常新的东西，我们中的许多人都需要一个区域进行试验并弄清楚使用最新版本的软件可以在Prod上实现的功能。这是最大的事情，因为停机时间非常昂贵，而且无论如何，许多人负担不起停机时间。如果所有内容都在单个群集中，则很难调试问题。一个示例是将Helm 2.0升级到3.0，因为这涉及丢失Helm数据。需要研究和锻炼。

4. 正如我所说，团队位置是另一回事。想象一下，如果您将开发人员和测试合并到一个集群中，那么您将拥有一个离岸测试团队。由于我们所有人都有最后期限，因此测试团队使用产品可能会有网络延迟。这可能是有争议的，但仍然需要考虑网络延迟。

简而言之Yes和No，这是一个值得商bat的问题，我们可以一直在列表中永久添加优点和缺点，但是建议在每个环境中都有不同的群集，直到您成为一个集群为止。一种kubernetes专家了解集群中的每个数据包。

Answer 2

使用命名空间已经可以实现

  

https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

使用命名空间，我们将能够隔离。

合并不同的名称空间将实现您的想法。