笔记。 翻译。：该材料来自一个教育项目 这是设计基于 Kubernetes 的基础设施时一个常见问题的答案。 我们希望对每个选项的优缺点的详细描述将帮助您为您的项目做出最佳选择。
TL博士：同一组工作负载可以在多个大型集群（每个集群将有大量工作负载）或许多小型集群（每个集群中具有少量负载）上运行。
下表评估了每种方法的优缺点：
当使用 Kubernetes 作为运行应用程序的平台时，经常会出现一些关于设置集群的复杂性的基本问题：
- 我应该使用多少个集群？
- 我应该把它们做成多大？
- 每个集群应该包括什么？
在本文中，我将尝试通过分析每种方法的优缺点来回答所有这些问题。
问题陈述
作为软件开发人员，您可能会同时开发和操作许多应用程序。
此外，这些应用程序的许多实例可能在不同的环境中运行 - 例如，这些可能是 开发, 实验 и 刺.
结果是一个完整的应用程序和环境矩阵：
应用和环境
上面的示例代表 3 个应用程序和 3 个环境，总共有 9 个可能的选项。
每个应用程序实例都是一个独立的部署单元，可以独立于其他应用程序实例使用。
请注意， 应用实例 可能由许多组成 组件，比如前端、后端、数据库等。 对于微服务应用程序，实例将包括所有微服务。
因此，Kubernetes 用户有几个疑问：
- 是否应该将所有应用程序实例放置在一个集群中？
- 是否值得为每个应用程序实例拥有一个单独的集群？
- 或者也许应该使用上述方法的组合？
所有这些选项都非常可行，因为 Kubernetes 是一个灵活的系统，不会限制用户的能力。
以下是一些可能的方法：
- 一个大的共同簇；
- 许多小型的高度专业化的集群；
- 每个应用程序一个集群；
- 每个环境一个集群。
如下所示，前两种方法处于选项范围的两端：
从几个大簇（左）到许多小簇（右）
一般来说，如果一个集群的节点和 Pod 总数较多，则该集群被认为比另一个集群“更大”。 例如，具有 10 个节点和 100 个 Pod 的集群比具有 1 个节点和 10 个 Pod 的集群要大。
好吧，让我们开始吧！
1. 一个大的公共集群
第一个选项是将所有工作负载放置在一个集群中：
一大群
在这种方法中，集群被用作通用的 基础设施平台 — 您只需在现有 Kubernetes 集群中部署所需的一切即可。
Kubernetes 允许集群的各个部分在逻辑上彼此分离，以便每个应用程序实例都可以拥有自己的命名空间。
让我们看看这种方法的优点和缺点。
+ 资源的有效利用
对于单个集群，您只需要运行和管理 Kubernetes 集群所需的所有资源的一份副本。
例如，对于主节点来说就是如此。 通常，每个 Kubernetes 集群有 3 个主节点，因此对于一个集群，其数量将保持不变（作为比较，10 个集群将需要 30 个主节点）。
上述微妙之处也适用于跨整个集群运行的其他服务，例如负载均衡器、入口控制器、身份验证、日志记录和监控系统。
在单个集群中，所有这些服务可以同时用于所有工作负载（无需像多个集群那样创建它们的副本）。
+ 便宜
由于上述原因，较少的集群通常会更便宜，因为没有管理成本。
对于主节点来说尤其如此，无论它们如何托管（本地或云中），主节点都可能花费大量资金。
一些托管 Kubernetes 服务，例如 или ，免费提供控制层。 在这种情况下，成本问题就不那么严重了。
还有一些托管服务对每个 Kubernetes 集群的运行收取固定费用（例如， ).
+ 高效的管理
管理一个集群比管理多个集群更容易。
管理可能包括以下任务：
- Kubernetes版本更新；
- 建立 CI/CD 管道；
- 安装 CNI 插件；
- 建立用户认证系统；
- 安装门禁控制器；
还有很多其他...
对于一个集群，您只需执行所有这些操作一次。
对于许多集群来说，操作必须重复多次，这可能需要一些流程和工具的自动化来确保流程的一致性和一致性。
现在谈谈缺点。
− 单点故障
如果拒绝 唯一的 集群将立即停止工作 所有 工作量！
出错的原因有很多：
- 更新 Kubernetes 会导致意想不到的副作用；
- 集群范围内的组件（例如 CNI 插件）开始无法按预期工作；
- 集群组件之一配置不正确；
- 底层基础设施出现故障。
此类事件可能会对共享集群中托管的所有工作负载造成严重损害。
− 无刚性绝缘
在共享集群中运行意味着应用程序共享集群节点上的硬件、网络功能和操作系统。
从某种意义上说，在同一节点上运行两个不同应用程序的两个容器就像在运行相同操作系统内核的同一台机器上运行的两个进程。
集装箱 Linux 它们提供了一定程度的隔离，但远不及虚拟机等设备提供的隔离强度。本质上，容器中的进程与宿主机操作系统上运行的进程是相同的。
这可能是一个安全问题：这种安排理论上允许不相关的应用程序相互通信（有意或无意）。
此外，Kubernetes 集群中的所有工作负载共享一些集群范围的服务，例如 - 这允许应用程序找到集群中其他应用程序的服务。
根据应用程序的安全要求，上述所有要点可能具有不同的含义。
Kubernetes 提供了各种工具来防止安全问题，例如 и 。 然而，正确设置它们需要一些经验；此外，它们无法完全堵住所有安全漏洞。
重要的是要永远记住 Kubernetes 最初是为 分享， 不是为了 隔离和安全.
− 缺乏严格的多租户
鉴于 Kubernetes 集群中共享资源丰富，不同的应用程序可以通过多种方式互相干扰。
例如，应用程序可能会独占共享资源（例如 CPU 或内存）并拒绝同一节点上运行的其他应用程序访问该资源。
Kubernetes 提供了各种机制来控制这种行为，例如 （另请参阅文章““ - 大约。 译）, и 。 然而，与安全性一样，它们的配置非常重要，并且它们无法绝对防止所有不可预见的副作用。
− 用户数量大
对于单个集群，您必须向许多人开放对其的访问。 它们的数量越多，它们“破坏”某些东西的风险就越高。
在集群内，您可以使用以下命令控制谁可以做什么 （参见文章““ - 大约。 译）。 但是，它不会阻止用户“破坏”其职责范围内的某些东西。
− 簇不能无限增长
用于所有工作负载的集群可能会非常大（就节点和 Pod 的数量而言）。
但这里又出现了另一个问题：Kubernetes 中的集群无法无限增长。
簇大小存在理论上的限制。 在 Kubernetes 中大约是 .
然而，在现实生活中，问题可能会更早开始——例如， .
事实上，大型集群给 Kubernetes 控制层带来了很高的负载。 换句话说，保持集群高效运行需要仔细调整。
原始博客上的一篇相关文章探讨了这个问题，名为““。
但让我们考虑相反的方法：许多小集群。
2. 许多小型专业集群
通过这种方法，您可以为部署的每个元素使用单独的集群：
许多小簇
就本文而言，根据 可展开元件 指应用程序的实例 - 例如，单独应用程序的开发版本。
该策略使用 Kubernetes 作为专门的 运行 对于单个应用程序实例。
让我们看看这种方法的优点和缺点。
+ 有限的“爆炸半径”
当集群发生故障时，负面后果仅限于该集群中部署的那些工作负载。 所有其他工作负载保持不变。
+ 绝缘
各个集群中托管的工作负载不共享处理器、内存、操作系统、网络或其他服务等资源。
结果是不相关的应用程序之间紧密隔离，这有利于它们的安全。
+ 用户数量少
由于每个集群仅包含有限的工作负载，因此可以访问该集群的用户数量会减少。
访问集群的人越少，出现“故障”的风险就越低。
让我们看看缺点。
− 资源利用效率低下
如前所述，每个 Kubernetes 集群都需要一组特定的管理资源：主节点、控制层组件、监控和日志记录解决方案。
在小集群数量较多的情况下，必须分配更大份额的资源来管理。
− 昂贵
资源利用效率低下自然会带来高昂的成本。
例如，维护30个主节点而不是XNUMX个具有相同计算能力的主节点必然会影响成本。
− 管理困难
管理多个 Kubernetes 集群比管理一个集群要困难得多。
例如，您必须为每个集群配置身份验证和授权。 Kubernetes版本也将要更新多次。
您可能需要使用自动化来提高所有这些任务的效率。
现在让我们看看不太极端的情况。
3. 每个应用一个集群
在这种方法中，您可以为特定应用程序的所有实例创建一个单独的集群：
每个应用程序的集群
这条路径可以被认为是“原则”的概括每个团队单独的集群”，因为通常一组工程师正在开发一个或多个应用程序。
让我们看看这种方法的优点和缺点。
+ 集群可根据应用进行调整
如果应用程序有特殊需求，可以在集群中实现，而不影响其他集群。
此类需求可能包括 GPU 工作线程、某些 CNI 插件、服务网格或其他一些服务。
每个集群都可以根据其中运行的应用程序进行定制，以便它仅包含所需的内容。
− 一个集群中的不同环境
这种方法的缺点是来自不同环境的应用程序实例共存于同一个集群中。
例如，应用程序的 prod 版本与 dev 版本在同一集群中运行。 这也意味着开发人员在运行应用程序生产版本的同一个集群中进行操作。
如果由于开发人员的行为或开发版本中的故障而导致集群发生故障，那么生产版本也可能会受到影响——这是这种方法的一个巨大缺点。
最后，我们列表中的最后一个场景。
4. 每个环境一个集群
此场景涉及为每个环境分配一个单独的集群：
每个环境一个集群
例如，您可能有集群 开发, 实验 и 刺，您将在其中运行专用于特定环境的应用程序的所有实例。
以下是这种方法的优点和缺点。
+ 产品环境的隔离
在这种方法中，所有环境都是相互隔离的。 然而，实际上这在产品环境中尤其重要。
应用程序的生产版本现在独立于其他集群和环境中发生的情况。
这样，如果开发集群中突然出现问题，应用程序的生产版本将继续工作，就像什么都没发生一样。
+ 集群可根据环境进行调整
每个集群都可以根据其环境进行调整。 例如，您可以：
- 在开发集群中安装开发和调试工具；
- 在集群中安装测试框架和工具 实验;
- 在集群中使用更强大的硬件和网络通道 刺.
这使您可以提高应用程序开发和运营的效率。
+ 限制对生产集群的访问
直接使用产品集群的需求很少出现，因此您可以显着限制有权访问它的人员范围。
您可以更进一步，完全拒绝人们访问此集群，并使用自动化 CI/CD 工具执行所有部署。 这种方法将在最相关的地方最大限度地减少人为错误的风险。
现在谈谈缺点。
− 应用程序之间没有隔离
该方法的主要缺点是应用程序之间缺乏硬件和资源隔离。
不相关的应用程序共享集群资源：系统核心、处理器、内存和一些其他服务。
如前所述，这可能存在潜在危险。
− 无法本地化应用程序依赖项
如果应用程序有特殊要求，则所有集群都必须满足这些要求。
例如，如果应用程序需要 GPU，则每个集群必须至少包含一个具有 GPU 的工作线程（即使它仅由该应用程序使用）。
因此，我们面临成本上升和资源利用效率低下的风险。
结论
如果您有一组特定的应用程序，则可以将它们放置在多个大型集群或许多小型集群中。
本文讨论了各种方法的优缺点，从一个全球集群到几个小型且高度专业化的集群：
- 一个大的一般集群；
- 许多小型的高度专业化的集群；
- 每个应用程序一个集群；
- 每个环境一个集群。
那么您应该采取哪种方法呢？
与往常一样，答案取决于用例：您需要权衡不同方法的优缺点并选择最佳选项。
但是，选择并不限于上面的示例 - 您可以使用它们的任意组合！
例如，您可以为每个团队组织几个集群：一个开发集群（其中将有环境 开发 и 实验) 并聚类为 最佳的 （生产环境所在的位置）。
根据本文的信息，您可以针对特定场景进行相应的优缺点优化。 祝你好运！
PS
另请阅读我们的博客：
- «“;
- «“;
- «“;
- «“。
来源： habr.com
