如果使用Kubernetes，会遇到一些有关使用集群方式的基本问题，比如应该有几个集群?它们应该多大?应该包含什么?
集群分析
在不同的应用开发环境中，你通常会开发和运行多个应用程序。此外，通常在不同的环境中运行这些应用程序的多个实例，比如你可能用开发环境，测试环境和生产环境。
于是，这将导致应用程序和环境组成不同的交集。在下面的示例中，有3个应用程序和3个环境，产生了9个应用程序的实例。每个应用程序实例都是一个可独立运行的独立部署单元。
请注意，一个应用程序实例可能由多个组件组成，如前端，后端，数据库等。在微服务应用程序中，一个应用程序实例将由所有微服务组件构成。
作为Kubernetes的用户，一些问题会引发你的思考。是否应该在单个群集上运行所有应用程序实例?还是应该为每个应用程序实例都有一个单独的集群?还是应该结合使用呢?
下面是一些你可以选择选项：
- 一个大型共享集群
- 许多小型一次性集群
- 每个应用程序的集群
- 每个环境的集群
前两种方法是从几个大型集群到多个小型集群的规模极限，如下图所示：
通常，如果集群包含更大的节点和Pod之和，则可以将其定义为“更大”。例如，具有10个节点和100个Pods的集群大于包含1个节点和10个Pods的集群。
一个大型共享集群
第一种选择是在同一集群中运行所有工作负载。通过这种方法，可以像通用基础架构平台一样使用这个集群。无论需要运行什么，都可以将其部署到现有的Kubernetes集群中。
Kubernetes提供了命名空间，以在逻辑上将集群的各个部分彼此分开，在上述情况下，可以为每个应用程序实例使用单独的命名空间。
优点：有效利用资源
如果只有一个Kubernetes集群，则只需拥有运行和管理Kubernetes集群所需的所有资源的一个副本。
例如，这包括主节点，一个Kubernetes集群通常有3个主节点，如果只有一个集群，则总共只需要3个主节点(如果有10个Kubernetes集群，则只有30个主节点)。
但这还包括其他集群范围的服务，例如负载均衡，入口控制器，身份验证，日志记录和监控。
如果只有一个集群，则可以为所有工作负载重用这些服务，并且不必为多个集群拥有多个服务副本。
优点：低成本
较少的集群通常成本更低，因为集群数量多，资源开销越多。对于主节点而言尤其如此，这可能会花费大量的费用，无论是在本地还是在云中。
一些托管的Kubernetes服务免费提供了Kubernetes控制平台，如谷歌GKE或Azure的AKS，所以在这种情况下，成本效益不是问题。
但是，还有托管的Kubernetes服务，它们为运行Kubernetes集群收取固定的费用，例如AWS的EKS。
优点：高效管理
管理单个集群比管理多个集群容易。这可能包括以下任务：升级Kubernetes版本，设置CI/CD管道，安装CNI插件，设置用户认证系统，安装准入控制器。
如果只有一个集群，则只需完成一次。如果有许多集群，那么需要多次应用所有内容，这可能需要开发一些自动化的流程和工具，才能始终如一地做到这一点。
缺点：单点故障
如果只有一个集群并且集群发生故障，那么所有工作负载都将出问题。还有许多操作可能会导致故障，比如Kubernetes升级，集群范围内的组件(例如CNI插件)无法正常工作，对集群组件进行了错误的配置，基础架构发生故障。所以，如果只有一个共享集群，则可能会对所有工作负载造成影响。
缺点：没有硬安全隔离
如果多个应用程序在同一个Kubernetes集群中运行，所以这些应用程序在集群的节点上共享硬件，网络和操作系统。具体而言，在同一节点上运行的两个不同应用程序的两个容器在技术上是在相同硬件和操作系统内核上运行的两个进程。
Linux容器提供某种形式的隔离，但是这种隔离不如虚拟机提供的隔离强。在后台，容器中的进程仍然只是在主机操作系统上运行的进程。从安全角度来看，这可能是一个问题。从理论上讲，它允许无关的应用程序产生意外的交互。
此外，所有在Kubernetes集群共享某些集群范围的服务，如工作负载DNS，这使得应用可发现集群中的其他应用程序的服务。
所以，这些问题可能是否会出现问题，具体取决于应用程序的安全要求。
Kubernetes提供了各种防止安全漏洞的方法，例如PodSecurityPolicies和NetworkPolicies，但是，它需要经验来以完全正确的方式来调整这些工具，并且它们也不能防止所有的安全漏洞。
而且，Kubernetes是为共享而设计的，而不是为了隔离和安全而设计的。
缺点：多租户资源侵占
Kubernetes集群中有许多共享资源，不同的应用程序可以通过多种方式侵占资源。比如，一个应用程序可能会占据某个共享资源(例如CPU或内存)，从而使同一节点上运行的其他应用程序无法运行。
Kubernetes提供了多种方法来控制这种行为，例如资源请求和限制，ResourceQuotas和LimitRanges。但是，以完全正确的方式调整这些工具并不是一件容易的事，它们也无法防止所有不必要的副作用。
缺点：用户权限复杂
如果只有一个集群，则企业中的许多人必须有权访问集群。用户使用系统的机会越多，破坏的风险就越高。在集群中，你可以控制哪些人可以使用基于角色的访问控制(RBAC)进行操作。但是，这仍然不能防止用户破坏其授权范围内的某些行为。
缺点：集群不能无限大
如果将单个群集用于所有工作负载，则集群可能会很大(就节点和Pods而言)。但是，Kubernetes集群不能无限增长。
对于集群的大小，存在一些理论上限，Kubernetes大约在5000个节点，150000个Pods和300000个容器的定义。但是，实际上，使用较小的集群大小(例如500个节点)可能已经出现了挑战。
原因是较大的集群对Kubernetes控制平面施加了更高的压力，这需要仔细计划来保持集群的功能和效率。
许多小型一次性集群
使用这种方法，可以为每个部署单元使用单独的Kubernetes集群(本文中，部署单元是一个应用程序实例，例如单个应用程序的开发版本)，通过这种策略，Kubernetes专用于各个应用程序实例。
优点：故障半径减小
如果集群发生故障，则损害仅限于这个集群上运行的工作负载，而其他所有工作负载均不受影响。
优点：隔离
在各个集群中运行的工作负载不会共享任何资源，例如CPU，内存，操作系统，网络或其他服务。
这样可以在不相关的应用程序之间提供强大的隔离，这对于这些应用程序的安全性是一大优势。
优点：很少的用户
如果每个集群仅运行一组工作负载，则需要访问该集群的人数将减少。访问集群的人越少，发生故障的风险越低。
缺点：资源利用效率低
如前所述，每个Kubernetes集群都需要一组管理资源，例如主节点，控制平面组件，监控和日志记录解决方案。如果有许多小型集群，则必须为这些管理功能牺牲更高的总资源。
缺点：成本高
资源使用效率低下会自动导致更高的成本。如果必须运行30个主节点而不是3个主节点才能获得相同的计算能力，那么成本高是必然的。
缺点：综合管理
管理许多Kubernetes集群比管理单个Kubernetes集群更为复杂。比如需要为每个集群设置身份验证和授权，如果要升级Kubernetes版本，则也需要执行多次。你可能需要开发一些自动化工具。
每个应用程序的集群
使用这种方法，可以为特定应用程序的所有实例创建一个单独的集群。可以将其视为每个团队负责集群的范围，因为通常一个团队会开发一个或多个应用程序。
优点：可以为应用程序定制集群
如果应用程序有特定要求，则可以将这些要求安装在集群中，而不会影响任何其他集群。这样的要求可能包括工作节点，某个CNI插件，服务网格或任何其他服务。每个群集都可以完全配备相应应用程序所需的配置。
缺点：同一集群中的不同环境
这种方法的缺点是来自不同环境的应用程序实例在同一群集中运行。例如，应用程序的生产版本与开发版本在同一集群中运行，这也意味着开发人员在与应用程序的生产版本相同的集群中工作。所以，如果一个开发人员或开发版本创建集群中的一些损坏，生产版本可能也受到影响。
每个环境的集群
使用这种方法，可以为每个环境创建一个单独的集群。例如，可以拥有一个开发，测试和生产集群，在其中运行特定环境的所有应用程序实例。
优点：产品环境的隔离
通常，这种将所有环境相互隔离，但是实际上，这对于产品环境尤其重要。现在，应用的生产版本不受任何其他集群和应用环境中发生的任何事情的影响。
因此，如果某些配置错误在开发集群中造成破坏，则应用程序的生产版本将继续运行。
优点：可以针对环境定制集群
可以针对每个集群的环境进行优化，比如，在开发集群中安装开发和调试工具;在测试集群中安装测试框架和工具;对产品集群使用更强大的硬件和网络连接;可以提高应用程序的开发和运行效率。
优点：锁定对生产集群的访问
没有人需要在生产集群上进行开发工作，因此可以限制对其的访问。甚至可以根本不向任何人授予对生产集群的访问权限，可以通过自动CI/CD工具对该集群进行部署。这将极大地减少生产集群中人为错误的风险。
缺点：应用之间缺乏隔离
主要缺点是应用之间缺少硬件和资源隔离。不相关的应用程序共享集群资源，例如操作系统内核，CPU，内存和其他一些服务。这可能有潜在的安全问题。
缺点：应用要求未本地化
如果应用程序有特殊要求，则所有集群中都必须满足这些要求。如一个应用程序需要一个GPU，则每个集群必须至少有一个GPU工作节点，即使它仅由一个应用程序使用。这可能会导致成本增加和资源使用效率低。
