了解基于 etcd 快照的 Kubernetes 集群还原
尽管 Kubernetes 采用对 IT 系统的体系结构意味着巨大变化，但 Kubernetes 系统提供的灾难恢复 (Disaster Recovery，DR) 模式与传统应用程序（例如 Oracle Java SE、Oracle Java EE 或 JavaScript）类似。在主区域发生灾难导致停机时，主系统必须在辅助位置维护一个一致且“尽可能最新”的主系统副本，该副本可以恢复工作负荷。
此解决方案手册提供了 Oracle MAA 建议和实用程序，这些建议和实用程序将创建辅助 Kubernetes 系统并允许您在影响位置的灾难情况下进行恢复，并强制将工作负载重定向到副本站点。
尽管此解决方案手册侧重于在其他区域中恢复 Kubernetes 集群，但您可以使用相同的脚本和过程将集群还原到以前的时间点。此操作在灾难恢复以外的情况中可能非常有用，例如：
- 控制层配置错误时。
- 当 etcd 数据库丢失、损坏或何时没有正确启动时。
- 如果错误的部署或用户错误影响多个应用程序或微服务，并且必须将群集恢复为以前的版本或原型。ETCD 快照恢复将所有构件还原到创建快照（备份）的时间点。
本文档重点介绍将 Kubernetes 等数据复制到辅助位置。Kubernetes 集群的所有信息都存储在 etcd 中，etcd 是用作集群数据的 Kubernetes 后备存储的键值存储。此解决方案手册提供了根据 etcd 恢复复制使用 Kubernetes kubeadm 工具创建的 Kubernetes 集群的建议（请参见 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ ）。提供的设置过程和脚本可能需要针对其他类型的集群（未使用 kubeadm 创建的集群）进行定制，但通常只要可以访问 Kubernetes 控制层使用的 etcd 端点即可。此复制解决方案需要为辅助集群设置特定的设置，并使用 etcd（也称为 etcd 快照）的副本来生成与主集群中完全相同的构件。
您可以使用构件快照或第三方 Kubernetes 备份工具在 Kubernetes 系统中复制特定名称空间和应用程序。但是，它们不会保护集群免受控制层元数据中的文件损坏和错误配置的影响。除了使用它们进行灾难保护之外，您还可以使用 etcd 快照进行本地恢复，并将 Kubernetes 集群还原到以前的工作点。如果您的 etcd 存储等集群系统不健康，则应用程序可能会继续运行，但 pod 重定位、配置更改、密钥访问以及任何其他需要控制层可用性的操作都无法正常工作。正因为如此，etcd 保留必须是任何 Kubernetes 集群生命周期过程的关键部分。
除了 Kubernetes 配置数据之外，在 Kubernetes 上运行的应用和微服务还可以在运行时生成数据。运行时数据灾难保护不属于本文档的范围，应与在应用服务器上运行的传统应用程序完全相同：
- 避免多语言持久性（对运行时数据使用不同类型的持久性存储“几乎”无法根据 BAC 定理解决问题）
- 为所有不同的数据类型、微服务和具有相关性的应用使用单一存储
- 有关运行时灾难保护，请参阅 Oracle MAA Best Practices for Oracle Database
开始之前
有关详细信息，请查看以下内容：
体系结构
此体系结构显示 Kubernetes 集群的灾难恢复 (Disaster Recovery，DR) 系统拓扑。
主数据库中的所有运行时、配置和元数据信息都从区域 1 复制到区域 2 和 Oracle Autonomous Data Guard 。所需的 Kubernetes 集群配置通过 etcd 快照进行复制，以实现控制层保护。您可以使用 etcd 副本或构件快照进行应用程序特定的配置保护。有关详细信息，请参阅使用构件快照来保护 Kubernetes 集群免受灾难。容器使用的映像托管在每个集群的本地注册表中或外部系统信息库中（图像本身不被视为 Kubernetes 集群配置）。
注：
为运行时数据库设置 Oracle Autonomous Data Guard 不属于此文档的范围。
插图 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 数据库在不中断的情况下保持可用。Oracle Data Guard 将这些备用数据库作为生产数据库的副本进行维护。然后，如果生产数据库因计划内或计划外停机而变得不可用，则 Oracle Data Guard 可以将任何备用数据库切换到生产角色，从而最大限度地减少与停机关联的停机时间。
- Oracle Real Application Clusters (Oracle RAC)
使用 Oracle RAC，可以在多个服务器上运行单个 Oracle Database，以尽可能提高可用性并实现水平可扩展性，同时访问共享存储。连接到 Oracle RAC 实例的用户会话可以在中断期间故障转移并安全地重放更改，而无需对最终用户应用程序进行任何更改。
- 容器注册表
Oracle Cloud Infrastructure Registry 是 Oracle 管理的注册表，可用于简化开发到生产工作流。通过注册表，您可以轻松存储、共享和管理开发构件和映像。Oracle Cloud Infrastructure 的高可用性和可扩展的体系结构可确保您可以可靠地部署和管理应用。
- 适用于 Kubernetes 的容器引擎
Oracle Cloud Infrastructure Container Engine for Kubernetes 是一项完全托管、可扩展的高可用性服务，可用于将容器化应用部署到云中。您可以指定应用所需的计算资源，而适用于 Kubernetes 的容器引擎将在现有租户的 Oracle Cloud Infrastructure 上预配这些资源。适用于 Kubernetes 的容器引擎使用 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 节点。
- 入站控制器
入站控制器是在 Kubernetes 集群中运行并管理入站资源的组件。它接收来自外部网络的流量，将其路由到正确的服务，并执行负载平衡和 SSL 终止。入站控制器通常作为群集中的单独 pod 运行，并且可以独立于其管理的服务进行缩放。
- KUBE 端点 API
KUBE-Endpoint API 是 Kubernetes 控制层的
kube-apiserver组件。它运行 Kubernetes API 服务器。 - ETCD 备份
ETCD 备份是 Kubernetes 控制层的
etcd组件的备份。etcd包含所有群集数据的分布式键 - 值存储。创建 ETCD 备份以恢复用于灾难恢复的 Kubernetes 集群非常重要。 - YAML 快照
YAML 快照是包含 Kubernetes 集群中构件定义的 (yaml) 文件的时间点副本。快照是一个 tar 文件，可用于恢复同一或不同 Kubernetes 集群中的这些构件。
Kubernetes 灾难保护注意事项
为 Kubernetes 实施灾难保护时，请考虑以下事项：
- 非对称灾难恢复 (DR) ：Oracle 建议在主和辅助中使用完全相同的资源容量和配置。两个区域中的 Kubernetes 集群应具有相似的资源，例如 worker 节点数（及其硬件容量）和其他基础设施（共享存储、负载平衡器、数据库等）。辅助区域中的 Kubernetes 集群所依赖的资源必须能够跟上与主区域相同的工作负载。此外，两个系统在功能上必须与恢复系统依赖的完全相同的服务保持一致，在两个位置都必须使用侧边汽车、配置图 (Configuration map，CM)。
- 主机名别名和虚拟化：规划辅助站点中的节点使用的主机名非常重要。在从主 Kubernetes 集群恢复
etcd快照之前，控制层和 worker 节点的主机名或别名主机名在辅助位置必须“活动”。节点名称存储在 Kubernetes 集群的不同构件中，用于标识 worker 节点、标记 pod 分配、描述集群本身的配置 (config) 映射以及多个配置文件和条目。您的辅助位置必须使用主 Kubernetes 集群中使用的相同主机名来标识 Worker、控制层和前端kube-api地址（全限定名称在域名中可能不同，但主机名必须相同。如果没有主机名别名，etcd快照恢复将无法正常工作，因为 kubelet、调度程序、控制器以及一般情况下，控制层服务将无法访问复制的配置使用的适当端点和主机。请勿使用 IP 来标识 kubernetes 中的节点，请始终改用主机名。 - 容器映像与二进制文件类似：映像可能不会像 Kubernetes 配置那样频繁更改，您可能不需要使用每个 Kubernetes 集群复制来更新映像。主系统使用的映像必须与辅助系统中使用的映像相同，否则可能会出现不一致和故障。但是，图像复制超出此工作簿的范围。您可以使用多种策略在两个位置之间保持图像的一致使用，包括：
- 在主节点中保存图像并加载到辅助节点。此方法非常易于实施，但产生管理开销。使用容器注册表具有可观的优势，在本地保存映像，因此更难管理版本和更新。
- 映像可以位于不同区域或数据中心的完全外部容器注册表中，与主数据库和备用数据库使用的一样。外部产品和库由第三方维护，其可用性通常隐含在它们的发行版中。
- 映像可以驻留在位于主数据库和备用数据库的容器注册表中。释放映像的新版本后，每个区域将并行更新。这样可以更好地控制使用的软件，但管理开销更高。需要复制映像和管理身份证明才能访问两个不同的注册表。CI/CD 工具通常用于此方法。
此解决方案手册提供了使用 kubeadm 工具创建的 Kubernetes 集群的示例。这些建议适用于内部部署系统中安装的定制 Kubernetes 集群，但大多数脚本可能需要对未使用 kubeadm 工具创建的集群进行修改。必须使用在运行相同 etcd 和 Kubernetes 版本的 Kubernetes 集群之间提供的步骤和脚本。在不同的 kubernetes 版本中恢复 etcd 快照可能导致不一致和不稳定的 etcd 集群。
关于所需产品和角色
此解决方案需要以下产品和角色：
- Kubernetes 集群
- 堡垒能够管理 Kubernetes 系统访问集群的 etcd 端点并使用 ssh 访问不同的控制层节点
- （可选）Oracle Cloud Infrastructure (OCI)
此手册基于使用 OCI 区域以及主要和辅助区域的资源。但是，此解决方案还适用于位于内部部署的 Kubernetes 集群。
这些是每个服务所需的角色。
| 服务名称：角色 | 需要 ... |
|---|---|
Kubernetes 集群（主要）：administrator |
运行所有脚本。 |
| Kubernetes（主）节点：对根具有 sudo 权限的用户 |
运行以下脚本：
|
Kubernetes 集群（辅助）：administrator |
运行所有脚本。 |
| Kubernetes（辅助）节点：具有超级用户 root 权限的用户 | 运行以下脚本：
|
要获得所需资源，请参阅 Oracle 产品、解决方案和服务。