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

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

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

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

此外,还必须保护 Kubernetes 集群控制层。使用相应的 etcd 快照可避免损坏、故障以及为工作群集提供闪回。尽管“Oracle 高可用性”提供了有关控制层防范灾难的最佳实践,但本文档中没有介绍该领域所需技术的内容。

开始之前

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

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

体系结构

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

主数据库中的所有运行时、配置和元数据信息都从区域 1 复制到区域 2 和 Oracle Autonomous Data Guard 。所需的 Kubernetes (K8s) 集群配置通过 ETCD 快照进行复制以保护控制层,并使用 YAML 快照进行应用程序配置保护。您可以使用构件快照,也可以使用 etcd 副本或构件快照来提供特定于应用程序的配置保护,从而提供特定于应用程序的配置保护。有关详细信息,请参阅 基于 etcd 快照恢复 Kubernetes 集群。容器使用的映像托管在每个集群的本地注册表中或外部系统信息库中(图像本身不被视为 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 数据库在不中断的情况下保持可用。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 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 链接。
  • 入站控制器

    入站控制器是在 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 配置那样频繁更改,您可能需要使用每个 Kubernetes 集群复制来更新映像。主系统使用的映像必须与辅助系统中使用的映像相同,否则可能会出现不一致和故障。但是,图像复制超出此工作簿的范围。您可以使用多种策略在两个位置之间保持图像的一致使用,包括:
    • 在主节点中保存图像并加载到辅助节点。此方法非常易于实施,但产生管理开销。使用容器注册表具有可观的优势,在本地保存映像,因此更难管理版本和更新。
    • 映像可以位于不同区域或数据中心的完全外部容器注册表中,与主数据库和备用数据库使用的一样。外部产品和库由第三方维护,其可用性通常隐含在它们的发行版中。
    • 映像可以驻留在位于主数据库和备用数据库的容器注册表中。释放映像的新版本后,每个区域将并行更新。这样可以更好地控制使用的软件,但管理开销更高。需要复制映像和管理身份证明才能访问两个不同的注册表。CI/CD 工具通常用于此方法。

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

关于所需产品和角色

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

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

    此手册基于使用 OCI 区域以及主要和辅助区域的资源。但是,此解决方案还适用于不在 OCI 中的 Kubernetes 集群。

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

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

运行以下脚本:

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

运行以下脚本:

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

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

更改日志

此日志列出了重大更改: