了解基于 etcd 快照的 Kubernetes 集群还原

了解基于 `etcd` 快照的 Kubernetes 集群还原

为了在发生灾难时确保业务连续性，您需要为在 Kubernetes 集群上运行的应用实施灾难恢复策略。使用这些 Oracle Maximum Availability Architecture (Oracle MAA ) 建议来提供数据保护，让您能够快速切换到备用系统，同时尽可能减少数据和生产力损失。

尽管 Kubernetes 采用对 IT 系统架构意味着巨大的变化，但 Kubernetes 系统将类似的灾难恢复 (DR) 范例呈现为传统应用（例如 Oracle Java SE、Oracle Java EE 或 JavaScript）。它必须在辅助位置维护主系统的一致且“尽可能更新”的副本，以便在主区域的灾难导致停机时恢复工作负载。

此解决方案手册提供了 Oracle MAA 建议和实用程序，可创建辅助 Kubernetes 系统，使您能够在影响位置的灾难情况下进行恢复，并强制将工作负载重定向到副本站点。

尽管此解决方案手册侧重于在不同的区域中还原 Kubernetes 集群，但您可以使用相同的脚本和过程将集群原地还原到以前的时间点。在灾难恢复以外的情况下，此操作可能有用，例如：

控制平面配置错误时。
当 etcd 数据库丢失、损坏或 etcd 未正确启动时。
如果部署不正确或用户错误影响多个应用程序或微服务，并且必须将集群恢复到以前的版本或原型。ETCD 快照还原会将所有对象还原到创建快照（备份）的时间点。

This document focuses on replicating Kubernetes’ etcd data to a secondary location. All the information of a Kubernetes cluster is stored in etcd, which is a key value store used as Kubernetes' backing store for the cluster’s data. This solution playbook provides recommendations to replicate a Kubernetes cluster created with the Kubernetes kubeadm tool (see https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) based on etcd restore. The setup procedures and scripts provided may require customizations for other type of clusters (those not created with kubeadm), but in general, are valid as long as there is access to the etcd endpoints that the Kubernetes’ control plane uses. This replication solution requires a specific setup for the secondary cluster and will use a copy of etcd (also called etcd snapshots) to bring up the exact same artifacts that existed in primary.

您可以使用构件快照或第三方 Kubernetes 备份工具在 Kubernetes 系统中复制特定名称空间和应用。但是，它们不会保护集群免受控制层元数据中的文件损坏和错误配置的影响。除了将它们用于灾难保护之外，还可以使用 etcd snapshots 进行本地还原，并将 Kubernetes 集群还原到以前的工作点。如果您的 etcd store 和 etcd cluster 系统不健康，则应用程序可能会继续运行，但云池重定位、配置更改、密钥访问以及任何其他需要控制层可用性的操作将无法正常运行。因此，etcd 保留必须是任何 Kubernetes 集群生命周期过程的关键部分。

除了 Kubernetes 配置数据，在 Kubernetes 上运行的应用程序和微服务还可以在运行时生成数据。运行时数据灾难保护不在本文档的范围内，应以与在应用服务器上运行的传统应用程序完全相同的方式进行处理：

避免多语言持久性（对运行时数据使用不同类型的持久性存储是“几乎”不可能解决 BAC 定理的问题）
为所有具有依赖关系的数据类型、微服务和应用尽可能使用单个存储
有关运行时灾难保护的信息，请参阅 Oracle MAA Best Practices for Oracle Database

使用须知

有几个 Oracle Maximum Availability Architecture (MAA) 技术简报介绍了如何为传统中间件系统设置灾难恢复 (Disaster Recovery，DR) 系统。这些文档详细介绍了 Kubernetes 应用使用的外部基础设施组件（例如存储、负载平衡器和数据库）的灾难保护要求。

有关详细信息，请查看以下内容：

有关使用对象快照进行特定于应用程序的配置保护的详细信息，请参见使用对象快照来保护 OCI Kubernetes 引擎集群免受灾难影响。

体系结构

此体系结构显示了 Kubernetes 集群的灾难恢复 (Disaster Recovery，DR) 系统拓扑。

主数据库中的所有运行时、配置和元数据信息都通过 Oracle Autonomous Data Guard 从区域 1 复制到区域 2。所需的 Kubernetes 集群配置通过 etcd 快照进行复制，以实现控制层保护。您可以使用 etcd 副本或对象快照来保护特定于应用程序的配置。容器使用的映像托管在每个集群的本地注册表中或外部资料档案库中（映像本身不被视为 Kubernetes 集群配置）。

注意：

为运行时数据库设置 Oracle Autonomous Data Guard 不属于本文档的范围。

下面是 kubernetes-etcd-multiregion-dr.png 的说明

插图 kubernetes-etcd-multiregion-dr.png 的说明

kubernetes-etcd-multiregion-dr-oracle.zip

此体系结构支持以下组件：

区域
Oracle Cloud Infrastructure 区域是包含一个或多个数据中心（称为可用性域）的本地化地理区域。地区独立于其他地区，远距离可以把它们分开（跨越国家甚至大陆）。
负载平衡器
Oracle Cloud Infrastructure Load Balancing 服务提供从单个入口点到后端多个服务器的自动流量分配。
动态路由网关 (DRG)
DRG 是虚拟路由器，用于为同一区域中的 VCN 之间、VCN 与区域外的网络（例如另一个 Oracle Cloud Infrastructure 区域中的 VCN、内部部署网络或另一个云提供商中的网络）之间的专用网络流量提供路径。
Data Guard
Oracle Data Guard 和 Oracle Active Data Guard 提供一组全面的服务，用于创建、维护、管理和监视一个或多个备用数据库，并使生产 Oracle 数据库在不中断的情况下保持可用。Oracle Data Guard 使用内存中复制将这些备用数据库作为生产数据库的副本进行维护。如果生产数据库由于计划内或计划外停机而变得不可用，则 Oracle Data Guard 可以将任何备用数据库切换到生产角色，从而最大限度地减少与停机关联的停机时间。Oracle Active Data Guard 提供了将以读为主的负载卸载到备用数据库的额外功能，并且还提供了高级数据保护功能。
Oracle Real Application Clusters (Oracle RAC)
通过 Oracle RAC，您可以跨多个服务器运行单个 Oracle Database，从而在访问共享存储时尽可能提高可用性和水平可扩展性。连接到 Oracle RAC 实例的用户会话可以在中断期间进行故障转移并安全地重放更改，而无需对最终用户应用程序进行任何更改。
注册表
Oracle Cloud Infrastructure Registry 是一个由 Oracle 管理的注册表，可帮助您简化开发到生产工作流。通过注册表，您可以轻松地存储、共享和管理开发对象，例如 Docker 映像。Oracle Cloud Infrastructure 的高可用性和可扩展性架构可确保您能够可靠地部署和管理应用。
Kubernetes 引擎
Oracle Cloud Infrastructure Kubernetes Engine （ OCI Kubernetes Engine 或 OKE ）是一项完全托管、可扩展的高可用性服务，可用于将容器化应用部署到云中。您可以指定应用所需的计算资源，Kubernetes Engine 在现有租户的 Oracle Cloud Infrastructure 上预配这些资源。OKE 使用 Kubernetes 跨主机集群自动部署、扩展和管理容器化应用。
Kubernetes 集群
Kubernetes 集群是一组运行容器化应用的计算机。Kubernetes 提供了一个可移植、可扩展的开源平台来管理这些节点中的容器化工作负载和服务。Kubernetes 集群由 worker 节点和控制层节点组成。
Kubernetes 控制层
Kubernetes 控制层管理 Kubernetes 集群中 worker 节点和 pod 的资源。控制层组件检测和响应事件、执行调度和移动群集资源。以下是控制平面组件：
- kube-apiserver：运行 Kubernetes API 服务器。
- etcd：所有集群数据的分布式键值存储。
- kube-scheduler：确定将在哪个节点上运行新的未分配 pod。
- kube-controller-manager：运行控制器进程。
- cloud-controller-manager：将集群与特定于云的 API 链接起来。
Kubernetes worker 节点
Kubernetes worker 节点是运行 Kubernetes 集群中容器化应用的 worker 机器。每个集群至少有一个 Worker 节点。
入站控制器
Ingress 控制器是在 Kubernetes 集群中运行并管理 Ingress 资源的组件。它接收来自外部网络的流量，将其路由到正确的服务，并执行负载平衡和 SSL 终止。Ingress 控制器通常作为群集中的独立 pod 运行，并且可以独立于其管理的服务进行扩展。
KUBE 端点 API
KUBE-Endpoint API 是 Kubernetes 控制层的 kube-apiserver 组件。它运行 Kubernetes API 服务器。
ETCD 备份
ETCD Backup 是 Kubernetes 控制层的 etcd 组件的备份。etcd 包含所有群集数据的分布式键值存储。创建 ETCD 备份以恢复用于灾难恢复的 Kubernetes 集群非常重要。
YAML 快照
YAML 快照是 (YAML) 文件的时间点副本，其中包含 Kubernetes 集群中构件的定义。快照是一个 tar 文件，可用于在相同或不同的 Kubernetes 集群中还原这些对象。

Kubernetes 灾难保护注意事项

为 Kubernetes 实施灾难保护时，请考虑以下事项：

对称灾难恢复 (Disaster Recovery，DR) ：Oracle 建议在主数据库和辅助数据库中使用完全相同的资源容量和配置。两个区域中的 Kubernetes 集群应具有类似的可用资源，例如工作节点数（及其硬件容量）和其他基础设施（共享存储、负载平衡器、数据库等）。辅助区域中的 Kubernetes 集群所依赖的资源必须能够与主区域保持相同的工作负载。此外，这两个系统在功能上必须与恢复的系统所依赖的完全相同的服务一致，侧车，配置图 (CM) 必须在两个位置使用。
主机名别名和虚拟化：规划辅助站点中的节点使用的主机名非常重要。在从主 Kubernetes 集群恢复 etcd 快照之前，控制层和 worker 节点的主机名或别名主机名必须在辅助位置中“活动”。节点名称存储在 Kubernetes 集群的不同构件中，用于标识 worker 节点、标记 pod 分配、描述集群本身的配置 (config) 映射以及多个配置文件和条目中。您的辅助位置必须使用主 Kubernetes 集群中使用的相同主机名来标识 worker、控制层和前端 kube-api 地址（域名中的全限定名称可能有所不同，但主机名必须相同）。如果没有主机名别名，etcd 快照恢复将无法正常工作，因为 kubelet、调度程序、控制器以及通常的控制层服务将无法访问复制配置使用的相应端点和主机。不要使用 IP 地址来标识 Kubernetes 中的节点，请始终改用主机名。
映像与二进制文件存在类似的范例：映像可能不会像 Kubernetes 配置那样频繁更改，您可能不需要使用每个 Kubernetes 集群复制来更新映像。主系统使用的映像必须与辅助系统中使用的映像相同，否则可能会发生不一致和故障。但是，映像复制超出了此手册的范围。您可以使用多种策略在两个位置之间保持一致地使用图像，包括：
- 将图像保存到主节点并加载到辅助节点。这种方法很容易实施，但会产生管理开销。使用容器注册表具有相当大的优势，并在本地保存映像，因此管理版本和更新变得更加困难。
- 映像可以驻留在与主数据库和备用数据库使用的不同区域或数据中心的完全外部容器注册表中。外部产品和库由第三方维护，其可用性通常在其发行版中隐含。
- 映像可以驻留在主数据库和备用数据库中的容器注册表中。发布新版本的映像时，每个区域都会并行更新。这样可以更好地控制所使用的软件，但会产生更高的管理开销。它需要复制图像和管理凭证才能访问两个不同的注册表。CI/CD 工具通常用于此方法。
主群集与辅助群集之间的差异：在使用的版本和配置方面，主群集与辅助群集是彼此的副本（通常适用于 DR 系统）。以下方面尤其相关：
1. Kubernetes 版本
2. 容器运行时和容器运行时版本
3. 网络插件和网络插件版本
4. podSubnet 和 servicesubnet
5. etcd hostpath 目录和 etcd 映像版本
6. 网络插件和 dns 映像版本
7. 控制层云池的映像资料档案库
Kubernetes 版本中站点之间存在微小差异的灾难保护配置可能起作用，但在从主数据库的 etcd 快照恢复后，它们可能会使集群处于不一致状态。有关容器运行时套接字、Kubernetes 版本等的信息存储在 Kubernetes 本身中。例如，cri-socket 信息根据所使用的容器运行时特定于每个节点，并且存储在内部配置映射中。kubeadm 用于升级的许多信息都基于 kube-system 名称空间中的配置映射。因此，主配置映射和辅助配置映射必须使用相同的信息。可以使用此命令将来自重要配置映射的所有相关信息存储在 yaml 文件中的主数据库和备用数据库。
```
[prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
```
同样，您可以使用以下命令在每个站点中创建节点配置的副本：
```
[prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
```

此解决方案手册提供了使用 kubeadm 工具创建的 Kubernetes 集群的示例。这些建议对于内部部署系统中安装的定制 Kubernetes 集群是通用的，但对于未使用 kubeadm 工具创建的集群，大多数脚本可能需要进行修改。必须使用在运行相同 etcd 和 Kubernetes 版本的 Kubernetes 集群之间提供的步骤和脚本。跨不同 Kubernetes 版本恢复 etcd 快照可能会导致不一致和不稳定的 etcd 集群。

关于必需的产品和角色

此解决方案需要以下产品和角色：

Kubernetes 集群
能够管理 Kubernetes 系统的堡垒可以访问集群的 etcd 端点并使用 ssh 访问不同的控制层节点
（可选）Oracle Cloud Infrastructure (OCI)
此手册基于将 OCI 区域和资源用于主区域和辅助区域。但是，此解决方案也适用于本地部署的 Kubernetes 集群。

这些是每个服务所需的角色。

服务名：职责	需要 ...
Kubernetes 集群（主）：`administrator`	运行所有脚本。
Kubernetes（主）节点：对根具有 sudo 权限的用户	运行以下脚本： `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Kubernetes 集群（辅助）：`administrator`	运行所有脚本。
Kubernetes（辅助）节点：对根具有 sudo 权限的用户	运行以下脚本： `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

要获取所需的资源，请参阅 Oracle 产品、解决方案和服务。