假设运用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版本，则也需求执行屡次。你能够需求开发一些自动化工具。

每个运用顺序的集群

运用这种办法，可以为特定运用顺序的一实在例创立一个独自的集群。可以将其视为每个团队担任集群的范围，由于通常一个团队会开发一个或多个运用顺序。

(责任编辑：admin)