使用构件快照保护 OCI Kubernetes 引擎集群免受灾难影响

为了在发生灾难时确保业务连续性,您需要为在 Kubernetes 集群上运行的应用实施灾难恢复 (DR) 策略,以提供数据保护,并允许您快速切换到备用系统,同时尽可能减少数据和生产力损失。 尽管 Kubernetes 采用对 IT 系统架构意味着巨大的变化,但 Kubernetes 系统将类似的 DR 范式呈现为传统应用(Oracle Java SE、Oracle Java EE 等)。您必须在辅助位置维护主系统的一致副本和尽可能新的副本,以便在主区域的灾难导致停机时恢复工作负载。

Oracle Maximum Availability Architecture (Oracle MAA ) 提供建议和实用程序,可用于在影响位置的灾难情况下进行恢复,并强制将工作负载重定向到副本站点。此内容的重点是应用程序的 Kubernetes 配置复制。在 Kubernetes 集群上运行的应用需要运行许多不同的组件,包括控制层节点、工作节点、负载平衡器和存储。同时,在 Kubernetes 上运行的应用程序生成的运行时数据也面临着与传统应用程序相同的挑战,在运行时应用程序可能会生成、读取和更新持久性数据。此解决方案手册提供了复制在 Kubernetes 上运行的应用程序的配置的建议。运行时数据的灾难保护不在本文档的范围内,应以与在应用服务器上运行的传统应用程序完全相同的方式进行处理,包括以下内容:

  • 避免多语言持久性。根据备份可用性一致性 (Backup Availability Consistency,BAC) 定理,将不同类型的持久性存储用于运行时数据几乎无法解决问题。
  • 尽可能为所有不同数据类型、微服务和具有相关性的应用使用单个存储。
  • 有关运行时数据的灾难保护,请参阅 Oracle MAA Oracle Database 优秀实践

此外,还必须保护 Kubernetes 集群控制层。使用相应的 etcd 快照可以避免损坏、故障以及向工作群集提供闪回。尽管 Oracle MAA 提供了防范灾难的控制层保护优秀实践,但它不在本文档的范围内来描述该领域所需的技术。

使用须知

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

有关详细信息,请查看以下内容:

体系结构

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

主数据库中的所有运行时、配置和元数据信息都通过 Oracle Autonomous Data Guard 从区域 1 复制到区域 2。所需的 Kubernetes (K8s) 集群配置通过 ETCD 快照进行复制,用于控制平面保护,并使用 YAML 快照进行应用程序配置保护。您可以使用构件快照,也可以使用 etcd 副本或构件快照来保护特定于应用程序的配置,从而实现特定于应用程序的配置保护。有关详细信息,请参见Kubernetes clusters restore based on etcd snapshots。容器使用的映像托管在注册表中,可以是每个集群的本地映像,也可以是外部资料档案库中的映像(映像本身不被视为 Kubernetes 集群配置)。

注意:

为运行时数据库设置 Oracle Autonomous Data Guard 不属于本文档的范围。
下面是 kubernetes-multiregion-dr.png 的说明
插图 kubernetes-multiregion-dr.png 的说明

kubernetes-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 EngineOCI Kubernetes EngineOKE )是一项完全托管、可扩展的高可用性服务,可用于将容器化应用部署到云中。您可以指定应用所需的计算资源,Kubernetes Engine 在现有租户的 Oracle Cloud Infrastructure 上预配这些资源。OKE 使用 Kubernetes 跨主机集群自动部署、扩展和管理容器化应用。

  • Kubernetes 集群

    Kubernetes 集群是一组运行容器化应用的计算机。Kubernetes 提供了一个可移植、可扩展的开源平台来管理这些节点中的容器化工作负载和服务。Kubernetes 集群由 worker 节点和控制层节点组成。

  • Kubernetes worker 节点

    Kubernetes worker 节点是运行 Kubernetes 集群中容器化应用的 worker 机器。每个集群至少有一个 Worker 节点。

  • Kubernetes 控制层

    Kubernetes 控制层管理 Kubernetes 集群中 worker 节点和 pod 的资源。控制层组件检测和响应事件、执行调度和移动群集资源。

    以下是控制平面组件:
    • kube-apiserver:运行 Kubernetes API 服务器。
    • etcd:所有集群数据的分布式键值存储。
    • kube-scheduler:确定将在哪个节点上运行新的未分配 pod。
    • kube-controller-manager:运行控制器进程。
    • cloud-controller-manager:将集群与特定于云的 API 链接起来。
  • 入站控制器

    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 名称空间应具有类似的可用资源,例如 worker 节点数(及其硬件容量)和其他基础结构(共享存储、负载平衡器、数据库等)。辅助区域中的 Kubernetes 集群所依赖的资源必须能够与主区域保持相同的工作负载。此外,这两个系统在功能上必须与恢复的系统所依赖的完全相同的服务一致,侧车,配置图 (CM) 必须在两个位置使用。
  • 映像与二进制文件存在类似的范例:映像不像 Kubernetes 配置那样频繁更改,您可能不需要每次 Kubernetes 集群复制更新映像。主系统使用的映像必须与辅助系统中使用的映像相同,否则可能会发生不一致和故障。但是,映像复制超出了此手册的范围。您可以使用多种策略在两个位置之间保持一致地使用图像,包括:
    • 将图像保存到主节点并加载到辅助节点。这种方法很容易实施,但会产生管理开销。使用容器注册表具有相当大的优势,并在本地保存映像,因此管理版本和更新变得更加困难。
    • 映像可以驻留在与主数据库和备用数据库使用的不同区域或数据中心的完全外部容器注册表中。外部产品和库由第三方维护,其可用性通常在其发行版中隐含。
    • 映像可以驻留在主数据库和备用数据库中的容器注册表中。发布新版本的映像时,每个区域都会并行更新。这样可以更好地控制所使用的软件,但会产生更高的管理开销。它需要复制图像和管理凭证才能访问两个不同的注册表。CI/CD 工具通常用于此方法。

尽管本手册提供了使用 Oracle Cloud Infrastructure 的示例,但这些建议对于内部部署系统中安装的定制 Kubernetes 集群是通用的。您可以使用在 OCI Kubernetes Engine (OKE) 中运行的主 Kubernetes 集群与在本地或定制 Kubernetes 集群中运行的辅助集群之间提供的步骤和脚本。还可以使用在 OKE 中运行的主 Kubernetes 集群与也在 OKE 中运行的辅助集群之间的步骤和脚本,或者在两个内部部署或定制 Kubernetes 集群之间。

关于必需的产品和角色

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

  • Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes 引擎或 OKE)集群
  • 能够管理 kubernetes 系统的堡垒节点
  • Oracle Cloud Infrastructure (OCI)

此手册基于将 OCI 区域和资源用于主区域和辅助区域。但是,此解决方案也适用于不在 OCI 上的 Kubernetes 集群。

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

服务名:职责 需要 ...
Oracle Cloud Infrastructure :admin 如果您使用一个或多个 OCI 区域,请预配和设置资源和服务。
Kubernetes 引擎集群(主):administrator 运行所有脚本。
Kubernetes 引擎(主)节点:对辅助节点具有执行权限和 ssh 权限的操作系统用户

运行以下脚本:

  • maak8-get-all-artifacts.sh
  • maak8DR-apply.sh
Kubernetes 引擎集群(辅助):administrator 运行所有脚本。
Kubernetes 引擎(辅助)节点:具有执行权限的操作系统用户

运行以下脚本:

  • removeyamlblock.sh
  • apply-artifacts.sh
  • maak8-push-all-artifacts.sh

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