17、多集群管理：挑战、策略与工具-优快云博客

本文链接：https://blog.youkuaiyun.com/arduino9maker/article/details/152509170

多集群管理：挑战、策略与工具

1. 多集群的应用场景与需求

在当今的云计算和容器化环境中，多集群架构变得越来越重要。软多租户（good soft multitenancy）在一定程度上能满足部分需求，但不足以抵御集群内的恶意工作负载。对于很多用户来说，硬多租户并非必要，因为他们信任集群内运行的工作负载。然而，如果你是云服务提供商，托管基于软件即服务（SaaS）的软件或不受信任用户控制的工作负载，硬多租户通常是必需的。

当运行需要处理来自区域内端点流量的工作负载时，设计中会包含基于每个区域的多个集群。对于全球分布式应用程序，运行多个集群就成为必要条件。而对于需要区域分布的工作负载，多集群的集群联合（cluster federation）是一个很好的用例。

此外，像高性能计算（HPC）、机器学习（ML）和网格计算等专业工作负载，也需要在多集群架构中得到解决。虽然多个 Kubernetes 节点池可以帮助解决专业硬件和性能配置文件的问题，但对于非常大的 HPC 或机器学习工作负载，应考虑为这些工作负载专门分配集群。

2. 多集群设计的挑战

选择多集群设计时会遇到一些挑战，这些挑战可能会使架构变得复杂，以下是一些常见的挑战：
|挑战类型|描述|
| ---- | ---- |
|数据复制|数据复制和一致性一直是跨地理区域和多个集群部署工作负载的关键。需要决定工作负载的运行位置并制定复制策略，大多数数据库有内置工具进行复制，但应用程序需要能够处理该策略。对于 NoSQL 类型的数据库服务，处理跨多个实例的扩展可能更容易，但仍需确保应用程序能够处理地理区域之间的最终一致性或至少处理区域之间的延迟。一些云服务，如 Google Cloud Spanner 和 Microsoft Azure CosmosDB，提供了内置的数据库服务来帮助处理跨多个地理区域的数据。|
|服务发现|每个 Kubernetes 集群都部署自己的服务发现注册表，并且注册表在多个集群之间不同步，这使得应用程序难以轻松识别和发现彼此。像 HashiCorp 的 Consul 可以透明地同步多个集群的服务，甚至是 Kubernetes 外部的服务。还有 Istio、Linkerd 和 Cillium 等工具正在构建多集群架构以扩展集群之间的服务发现。|
|网络路由|Kubernetes 使集群内的网络变得非常容易，因为它是一个扁平网络，避免使用网络地址转换（NAT）。但如果需要将流量路由进出集群，情况会变得更复杂。集群的入口（Ingress）实现为入口与集群的 1:1 映射，因为它不支持使用 Ingress 资源的多集群拓扑。还需要考虑集群之间的出口流量以及如何路由该流量。对于具有紧密耦合依赖关系的应用程序，应考虑将这些服务运行在同一集群中以消除延迟和额外的复杂性。|
|运营管理|管理多集群的最大开销之一是运营管理。需要管理和维护多个集群的一致性，而不是一两个集群。确保有良好的自动化实践非常重要，因为这将有助于减轻运营负担。在自动化集群时，需要考虑基础设施部署和管理集群的附加功能。使用像 HashiCorp 的 Terraform 这样的工具可以帮助部署和管理集群舰队的一致状态。|
|持续部署|使用多个集群和持续交付（CD）时，需要处理多个 Kubernetes API 端点，而不是单个 API 端点，这会在应用程序分发方面带来挑战。虽然可以轻松管理多个管道，但如果有大量管道需要管理，应用程序分发会变得非常困难。|

3. 多集群部署的管理

3.1 部署工具选择

管理多集群部署的第一步是使用像 Terraform 这样的基础设施即代码（IoC）工具来设置部署。其他部署工具，如 kubespray、kops 或其他云提供商特定的工具也是有效的选择，但最重要的是使用一个允许对集群部署进行源代码控制的工具，以实现可重复性。

3.2 自动化的重要性

自动化是成功管理环境中多个集群的关键。虽然可能无法在第一天就实现所有自动化，但应将自动化集群部署和操作的各个方面作为优先事项。

3.3 Kubernetes Cluster API

Kubernetes Cluster API 是一个正在开发的有趣项目，它是一个 Kubernetes 项目，旨在为集群创建、配置和管理带来声明式的 Kubernetes 风格的 API。它在核心 Kubernetes 之上提供可选的附加功能，通过通用 API 声明集群级配置，使你能够轻松自动化和围绕集群自动化构建工具。目前该项目仍在开发中，需要持续关注其发展。

4. 部署和管理模式

4.1 Kubernetes 操作符

Kubernetes 操作符是基础设施即软件概念的实现，使用它们可以抽象 Kubernetes 集群中应用程序和服务的部署。例如，若要使用 Prometheus 监控 Kubernetes 集群，需要为每个集群和团队创建和管理各种对象（部署、服务、入口等），并维护 Prometheus 的基本配置，如版本、持久性、保留策略和副本。这在大量集群和团队中维护起来可能很困难。

而安装 prometheus - operator 可以扩展 Kubernetes API，暴露多个新的对象类型，如 Prometheus、ServiceMonitor、PrometheusRule 和 AlertManager，允许使用几个对象指定 Prometheus 部署的所有细节。可以使用 kubectl 工具管理这些对象，就像管理任何其他 Kubernetes API 对象一样。

4.2 操作符模式的原理

操作符模式基于两个概念构建：
- 自定义资源定义（Custom resource definitions，CRDs）：允许基于自己定义的 API 扩展 Kubernetes API。
- 自定义控制器（Custom controllers）：基于 Kubernetes 的资源和控制器核心概念构建，允许通过监视 Kubernetes API 对象（如命名空间、部署、Pod 或自己的 CRD）的事件来构建自己的逻辑。可以以声明式的方式构建 CRDs，就像 Kubernetes 部署控制器在协调循环中维护部署对象的状态一样，为 CRDs 带来相同的优势。

4.3 以 Elasticsearch 操作符为例

Elasticsearch 操作符可以执行以下操作：
- 主节点、客户端节点和数据节点的副本
- 高可用部署的区域
- 主节点和数据节点的卷大小
- 集群的调整大小
- Elasticsearch 集群的备份快照

通过熟悉的 Kubernetes 对象来管理这些操作，大大简化了 Elasticsearch 的管理。

5. GitOps 方法管理集群

5.1 GitOps 概念

GitOps 由 Weaveworks 推广，其理念和基础基于他们在生产环境中运行 Kubernetes 的经验。GitOps 将软件开发生命周期的概念应用于运营。在 GitOps 中，Git 存储库成为事实来源，集群与配置的 Git 存储库同步。例如，更新 Kubernetes 部署清单时，这些配置更改会自动反映在集群状态中。

使用该方法可以更轻松地维护一致的多集群，避免集群之间的配置漂移。GitOps 允许为多个环境声明式地描述集群，并努力维护集群的状态。GitOps 实践可应用于应用程序交付和运营，这里主要关注使用它来管理集群和运营工具。

5.2 使用 Flux 实现 GitOps

Weaveworks Flux 是最早支持 GitOps 方法的工具之一。以下是在集群中设置 Flux 并将存储库与集群同步的步骤：
1. 克隆 Flux 存储库：

git clone https://github.com/weaveworks/flux
cd flux

修改部署清单以配置为你的分叉存储库：

vim deploy/flux - deployment.yaml

修改以下行以匹配你的 GitHub 存储库：

--git - url=git@github.com:weaveworks/flux - get - started  (ex. --git - url=git@github.com:your_repo/kbp )

部署 Flux 到集群：

kubectl apply -f deploy

获取 Flux 的 SSH 密钥：
- 安装 fluxctl：
  - 对于 MacOS：

brew install fluxctl

    - 对于 Linux Snap 包：

snap install fluxctl

    - 对于其他包，可以在相应位置找到最新二进制文件。
- 获取 SSH 密钥：

fluxctl identity

配置 GitHub 存储库的部署密钥：
- 打开 GitHub，导航到你的分叉存储库，进入设置 > “部署密钥”，点击 “添加部署密钥”。
- 给密钥一个标题，选择 “允许写入访问” 复选框，粘贴 Flux 公钥，然后点击 “添加密钥”。
查看 Flux 日志以确认与 GitHub 存储库同步：

kubectl -n default logs deployment/flux -f

查看 Pod 创建情况：

kubectl get pods -w

通过这个示例可以看到，使用 GitOps 方法可以轻松地将 GitHub 存储库状态与 Kubernetes 集群同步，使管理集群中的多个运营工具变得更加容易。

6. 多集群管理工具

当处理多个集群时，使用 Kubectl 可能会让人感到困惑，因为需要设置不同的上下文来管理不同的集群。以下是一些可以立即安装使用的工具，以及一些全面的多集群管理工具：

6.1 便捷切换工具

kubectx 和 kubens ：允许轻松在多个上下文和命名空间之间切换。

6.2 全面管理工具

工具名称	特点	适用场景
Rancher	集中管理多个 Kubernetes 集群，通过集中管理的用户界面（UI）进行操作。可监控、管理、备份和恢复跨本地、云以及托管 Kubernetes 设置的集群。还具备控制跨多个集群部署的应用程序的工具，并提供运营工具。	适用于需要集中管理多个集群，对集群监控、备份恢复等有需求的场景。
KQueen	是一个开源项目，由 Mirantis 开发。提供多租户的 Kubernetes 集群供应自助服务门户，专注于多个 Kubernetes 集群的审计、可见性和安全性。	适用于对集群安全性、审计和可见性有较高要求的多租户环境。
Gardener	采用不同的多集群管理方法，利用 Kubernetes 原语为最终用户提供 Kubernetes 即服务。支持所有主要的云供应商。	适用于构建 Kubernetes 即服务的用户。

7. Kubernetes 联邦

7.1 联邦版本发展

Kubernetes 最初在 1.3 版本引入了 Federation v1，但后来被 Federation v2 取代。Federation v1 旨在帮助将应用程序分发到多个集群，但它利用 Kubernetes API 构建，严重依赖 Kubernetes 注解，导致设计上存在一些问题，且与核心 Kubernetes API 紧密耦合，具有整体性。随着 Kubernetes CRDs 的引入，Federation 的设计有了新的思路。

Federation v2（现在称为 KubeFed）要求 Kubernetes 版本为 1.11+，目前处于 alpha 阶段。它围绕 CRDs 和自定义控制器的概念构建，允许使用新的 API 扩展 Kubernetes，不再局限于以前的 v1 部署对象。

7.2 KubeFed 的作用

KubeFed 主要不是用于多集群管理，而是用于在多个集群之间提供高可用性（HA）部署。它允许将多个集群组合成一个单一的管理端点，用于在 Kubernetes 上交付应用程序。例如，如果有多个位于不同公共云环境的集群，可以将它们组合成一个单一的控制平面，以管理对所有集群的部署，从而提高应用程序的弹性。

7.3 支持的联邦资源

截至目前，KubeFed 支持以下联邦资源：
- 命名空间
- 配置映射
- 密钥
- 入口
- 服务
- 部署
- 副本集
- 水平 Pod 自动缩放器
- 守护进程集
- 作业

7.4 工作原理及示例

KubeFed 的工作方式并非将所有内容复制到所有集群。例如，对于部署和副本集，需要定义副本数量，然后将其分布在各个集群中，这是部署的默认行为，但可以更改配置。而创建命名空间时，该命名空间是集群范围的，会在每个集群中创建。密钥、配置映射和守护进程集的工作方式相同，会复制到每个集群。入口资源则不同，它创建一个全局的多集群资源，具有单个服务入口点。

以下是一个联邦部署的示例：

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 5
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            name: nginx
  placement:
    clusters:
    - name: azure
    - name: google

这个示例创建了一个具有五个副本的 NGINX Pod 的联邦部署，这些副本将分布在 Azure 和 Google 的集群中。

7.5 注意事项

设置联邦 Kubernetes 集群超出了本文的范围，可以参考 KubeFed 用户指南了解更多信息。由于 KubeFed 仍处于 alpha 阶段，需要持续关注其发展，同时应充分利用现有的工具来实现 Kubernetes 的高可用性和多集群部署。

8. 管理多个集群的最佳实践

在管理多个 Kubernetes 集群时，可参考以下最佳实践：
1. 限制集群的影响范围 ：确保级联故障不会对应用程序产生更大的影响。
2. 考虑监管要求 ：如果有 PCI、HIPPA 或 HiTrust 等监管问题，可考虑使用多集群来简化将这些工作负载与一般工作负载混合的复杂性。
3. 满足硬多租户需求 ：如果硬多租户是业务需求，应将工作负载部署到专用集群。
4. 使用全局负载均衡器 ：如果应用程序需要多个区域，可利用全局负载均衡器管理集群之间的流量。
5. 分离专业工作负载 ：将高性能计算（HPC）等专业工作负载分离到单独的集群中，以确保满足工作负载的特殊需求。
6. 制定数据复制策略 ：在跨多个区域数据中心部署工作负载时，首先要确保有数据复制策略。跨区域的多个集群部署相对容易，但跨区域复制数据需要谨慎处理。

通过遵循这些最佳实践，可以更高效、稳定地管理多个 Kubernetes 集群，提高应用程序的性能和可靠性。