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