什么是操作大量 Kubernetes 集群的良好控制平面？

普拉纳夫·达瓦德卡

2020 年 1 月 24 日发布

这个特定的博客描述了 Volterra 如何帮助用户像舰队一样运营他们的applications和基础设施。我们将解释基于控制平面的方法如何简化大量应用程序集群的操作，并将其与其他多集群管理平面方法（如 Google Anthos、Azure Arc、Rancher 等）进行比较。

现在，您可能想知道我们是否只是在进行营销并将我们的多集群管理称为车队运营！多集群管理和车队运营方法针对不同的用例，并且在架构上有根本的不同。多集群方法旨在解决集群相对较少且用户希望使用一致的操作模型来管理这些基础设施集群的情况。而舰队方法旨在解决存在大规模集群（例如机器人、汽车、工业网关、数十个公共云区域等中的 K8s 集群）并且用户希望在这些大规模集群上部署相同的application和网络/安全性的情况。接下来的两节将更详细地描述和比较多集群和舰队运营方法。

多集群方法

多集群管理方法旨在解决单个团队运营下集群相对较少的用例。此类场景的示例包括跨几个可用区域的数十个集群，以减少爆炸半径。类似地，用户可能选择在几个地区建立多个集群来满足监管需求。

以下两个示例重点介绍了多集群解决方案的工作原理（高层次）：

配置

让我们以使用 Rancher 的多集群方法进行application部署为例，如图 1 所示。在多集群方法中，客户逐个选择application部署的目标站点。当您拥有多个集群时，这种逐个选择目标站点的方法是有效的。然而，这种方法并不适用于一千个集群。

可观察性

图 2 以 Rancher 为例，展示了可观察性在多集群方法中的工作方式。在多集群方法中，客户必须逐个双击每个集群才能查看部署的 pod 的状态、CPU 和内存资源利用率。这种逐个观察目标站点的方法适用于少量集群，但不适用于管理大量集群。

集群 1：

集群 2：

解决第一个例子中描述的问题的一个明显的方法是编写某种形式的自动化程序，为每个集群重复任务。例如，每当添加新集群时，脚本可以执行以下操作来部署新application（例如 checkoutservice）

导出 KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f 结帐服务.yaml

但是，必须为每个操作构建自动化——部署、升级、策略、资源预留等。这种自动化不仅必须跨多个集群执行单独的操作，还需要处理故障情况。此外，当出现复杂场景时（例如，在集群子集上进行 Beta 测试、在所有集群中进行滚动升级），自动化将变得越来越复杂。我们在流程早期就意识到了这一点，并构建了一个可提供所有这些功能的分布式控制平面——使用接下来描述的车队运营方法。

Volterra 的车队运营方法

车队运营意味着客户对车队声明性地定义一次他/她的意图，系统接管确保受影响的站点与定义的意图保持一致的责任。意图的例子包括application软件版本、基础设施软件版本（例如操作系统版本）、网络策略、安全策略和资源预留。

一旦意图生效，系统将允许用户查看车队的状态和健康状况。这意味着用户可以通过单一窗口查看所有站点的基础设施和applications的运行状况，从而降低客户运营团队的运营复杂性。用户不必逐个点击每个站点或集群来确定运行状况并编写自动化工具来汇总信息。

Volterra 的车队运营方法包括三个主要部分——分段、配置和可观察性，我们将在以下部分中讨论。

船队细分

用户通常在站点群中拥有多种站点，例如开发、测试、生产计算站点。由于组织政策的原因，需要将不同的工作负载部署到站点的特定部分（例如开发工作负载只能在开发站点上运行）。我们允许用户灵活地用由两部分（键和值）组成的标签来标记网站。示例包括：

标签键=区域。标签值 = 美国西部、日本北部、日本南部
车型年份=（2015、2016、2017、2018）
功能=（喷涂，焊接）

一旦标记了站点，用户就可以使用标签键值条件定义“虚拟站点”。在多云场景中，用户可以将其站点标记为 dev、pre-prod、prod。下图 3 显示了使用前面描述的标签键值的机器人用例示例。

这是 Volterra 上的配置片段，用户可以使用 blend/go-sdk 语法来创建虚拟站点。在这个特定的例子中，各个站点被标记为标签键 = ves.io/country 和标签值为 ves-io-jpn

用户习惯于先定义其车队的各个部分，然后在配置时标记其站点以包含在车队中的运营模式；虚拟站点与用户现有的运营模式完美结合。当新站点配置了适当的标签后，它将自动包含在先前定义的虚拟站点中，而无需额外的手动步骤。此外，Volterra 发现预先配置的信息，例如硬件制造商或公共云类型，以预先填充系统标签。用户可以选择使用这些自动发现的标签来定义他们的虚拟站点。

舰队配置

机队配置能力可以通过以下三个示例来最好地描述：

网络/安全策略的配置——让我们以客户推出新服务为例，该服务需要每个集群能够与特定的 URL 进行通信，例如github.com 。通常用户采用白名单，这意味着集群只允许到达特定目的地。因此，推出这项新服务需要用户前往每个集群并修改网络策略以将github.com添加到白名单中。此外，客户希望在将其推广到所有站点之前，先在几个测试站点上进行测试。为了在 Volterra 上实现这一意图，客户首先在 Volterra SaaS 控制台上定义一个选择车队一部分的“测试”虚拟站点。然后，用户定义网络策略（例如 URL 白名单列表（此示例中为github.com ））并将其应用于“测试”虚拟站点。 Volterra 的分布式控制平面将网络策略发送到虚拟站点（如上所述）选择的每个站点上的本地控制平面。每个站点上的本地控制平面应用网络策略并收集每个站点命中规则的统计数据。一旦客户对服务按预期运行感到满意，客户就可以将网络策略应用于选择机组中剩余站点的“prod”虚拟站点。这是使用 Json 并使用 Volterra 系统上的 UI 的配置片段。

基础设施软件升级——车队配置能力使用户能够升级基础设施软件，例如整个车队（或车队的一部分）的操作系统版本。首先，用户定义将操作系统从版本1升级到版本2的意图。接下来，用户定义整个集群的部署策略，例如滚动更新、蓝绿等等。滚动更新意味着机群（或机群的一部分）中每个站点的操作系统都会按顺序升级。蓝/绿部署策略意味着用户希望在一组“蓝色”站点（例如，开发站点）上测试升级，并将其运行状况与未升级的“绿色”站点（例如，生产站点）进行比较。无论哪种情况，Volterra 的分布式控制平面都会将版本 2 软件发送到虚拟站点选择的每个站点上的本地控制平面，并按照部署策略进行定义。每个站点上的本地控制平面以 A/B 方式升级操作系统，这意味着它会创建一个新的分区，在新的分区中部署版本 2，并使客户能够测量健康状况。如果版本 2 安装不成功，系统会自动回滚到原分区的版本 1。以下是用户如何使用 Volterra SaaS 门户执行基础设施软件升级的一些屏幕截图。用户可以看到当前基础设施软件版本和所有站点可用的最新软件版本，如下图所示。用户可以根据操作模型轻松升级特定站点或所有站点。

applications的全舰队部署——Volterra 提供了一个名为虚拟 Kubernetes (vK8s) 的对象，使用户能够使用 Kubernetes API 管理整个舰队的applications。用户使用标准 Kubernetes 方法（即 Kubeconfig 文件和 Kubernetes API）和部署清单文件部署其applications，并指示需要部署application的站点部分（或整个集群）。然后，Volterra 的虚拟 Kubernetes (vK8s) 接管将application部署到集群中每个站点（或每个部分）的责任。如果application部署期间出现任何故障，例如连接或基础设施故障，Volterra Virtual Kubernetes 将按照 Kubernetes 最终一致模型的范例继续重试部署。下一个屏幕截图展示了用户在名为“jpn-all-sites”的虚拟站点上部署名为“kuard”的application的示例（参见Kubernetes-up-and-running-demo-app ），该站点正在选择机群中的 140 个站点。要添加新的部署，用户只需单击“添加部署”并根据虚拟站点指定部署位置即可添加新的部署。

如果使用适当的标签将新站点添加到机群，则新站点将自动添加到虚拟站点（此示例中为 jpn-all-sites），并且机群配置（即此示例中的 Kuard 部署）将自动应用于新添加的站点，从而减轻运营团队的负担并消除人为错误。

舰队可观测性

虚拟站点和虚拟 Kubernetes (vK8s) 不仅用于配置，还用于聚合集群中分布式站点的运行状况。与其他解决方案相比，这是一个非常强大的工具，其他解决方案中用户必须编写工具来逐个从每个站点获取状态并汇总信息。该系统会自动将所有站点的健康状况汇总到单一窗口，从而降低客户运营团队的操作复杂性。收集的健康状态包括许多方面，例如application部署状态、站点健康状态、application健康状态等。

用户可以在地图上快速了解所有站点的运行状况，如下面的屏幕截图所示。颜色表示健康评分是否大于 75（绿色），是否在 40-75 之间（橙色），是否小于 40 则为红色。健康评分是由连接性、可靠性、安全性和性能（即资源消耗）组成的综合评分。

用户还可以看到所有站点的连接情况以及站点运行状况的汇总视图。图 10 还直观地显示了连接站点和 Volterra 主干网的每个链路的连接健康状况。用户可以根据健康状态点击性能不佳的链接，以显示有关请求和错误的详细统计数据，并解决任何连接问题，如图 11 所示。

接下来，用户可以通过站点间的 CPU 和内存负载分布查看所有站点的汇总信息。此信息对于 IT 或站点管理员很有用，可帮助他们确定哪些站点利用率过高且面临资源耗尽的危险。站点管理员可以设置警报，当资源消耗超过阈值时收到通知。在此屏幕截图中，用户可以看到一半的网站消耗了超过 75％的可用内存。他们不必点击单个网站，也不必编写额外的工具来获取这些信息。