1. 以 etcd 快照為基礎的 Kubernetes 叢集回復
  2. 瞭解以 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 快照回復會將所有使用者自建物件回復成建立快照 (備份) 的時間點。

本文件著重於將 Kubernetes 的 etcd 資料複製到次要位置。Kubernetes 叢集的所有資訊都儲存在 etcd 中，這是作為叢集資料之 Kubernetes 備份存放區的金鑰值存放區。此解決方案手冊提供複製以 etcd restore 為基礎之 Kubernetes kubeadm 工具建立的 Kubernetes 叢集的建議 (請參閱 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)。提供的設定程序和程序檔可能需要自訂其他類型的叢集 (不是使用 kubeadm 建立的叢集)，但一般而言，只要有 Kubernetes 控制層使用的 etcd 端點存取權即可有效。此複製解決方案需要特定的次要叢集設定，並且會使用 etcd (也稱為 etcd snapshots) 的複本來啟動與主要叢集相同的使用者自建物件。

您可以使用使用者自建物件快照或第三方 Kubernetes 備份工具，跨 Kubernetes 系統複製特定命名空間和應用程式。不過，它們無法保護叢集免於控制層中繼資料中的檔案損毀和組態錯誤。除了使用它們進行災害保護之外，您也可以使用 etcd snapshots 進行本機回復，並將 Kubernetes 叢集回復成先前的工作點。如果您的 etcd store 和 etcd cluster 系統狀況不佳，則應用程式可能會繼續執行，但 Pod 重新定位、組態變更、加密密碼存取，以及需要控制層可用性的任何其他作業將無法正常運作。因此，保留 etcd 必須是任何 Kubernetes 叢集生命週期程序的重要部分。

除了 Kubernetes 組態資料外，在 Kubernetes 上執行的應用程式和微服務也可能在程式實際執行時產生資料。程式實際執行資料災害保護超出本文件的範圍，應與在應用程式伺服器上執行的傳統應用程式完全相同：

  • 避免多語言持續性 (針對程式實際執行資料使用不同類型的永久存放區是「幾乎」無法解決每個 BAC 定理的問題)
  • 盡可能針對所有不同資料類型、微服務和具有相依性的應用程式使用單一存放區
  • 請參閱 Oracle MAA Best Practices for Oracle Database 以瞭解程式實際執行時的災害保護

Before You Begin - 開始之前

有幾項 Oracle Maximum Availability Architecture (MAA) 技術摘要，說明如何為傳統中介軟體系統設定災難復原 (DR) 系統。 這些文件詳細說明了 Kubernetes 應用程式使用的外部基礎架構元件 (例如儲存、負載平衡器和資料庫) 的災害保護需求。

請複查下列項目以瞭解詳細資訊：

請參閱使用使用者自建物件快照保護您的 OCI Kubernetes 引擎叢集免於災難，瞭解有關將使用者自建物件快照用於應用程式特定組態保護的詳細資訊。

架構

此架構顯示 Kubernetes 叢集的災害復原 (DR) 系統拓樸。

所有位於主要資料庫中的執行階段、組態和中繼資料資訊都會透過 Oracle Autonomous Data Guard 從 Region 1 複製到 Region 2。系統會透過 etcd 快照複製必要的 Kubernetes 叢集組態，以保護控制層。您可以使用 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、內部部署網路或其他雲端提供者中的網路) 之間的專用網路流量路徑。

  • 資料保全

    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 引擎或 OKE) 是完全託管、可擴展且高可用性的服務，可用來將容器化應用程式部署到雲端。您可以指定應用程式所需的運算資源，而 Kubernetes 引擎則會在現有租用戶的 Oracle Cloud Infrastructure 上佈建這些資源。OKE 使用 Kubernetes 將跨主機叢集的容器化應用程式部署、調整規模及管理自動化。

  • Kubernetes 叢集

    Kubernetes 叢集是一組執行容器化應用程式的機器。Kubernetes 提供可攜式、可擴充的開源平台，用於管理這些節點中的容器化工作負載和服務。Kubernetes 叢集是由工作節點與控制平面節點組成。

  • Kubernetes 控制層
    Kubernetes 控制平面可管理 Kubernetes 叢集內工作節點與 Pod 的資源。控制層元件可偵測及回應事件、執行排程及移動叢集資源。以下是控制平面元件：
    • kube-apiserver：執行 Kubernetes API 伺服器。
    • etcd：所有叢集資料的分散式索引鍵 - 值存放區。
    • kube- scheduler：決定要在哪個節點上執行新的未指派 Pod。
    • kube-controller-manager：執行控制器處理作業。
    • cloud-controller-manager：使用雲端特定 API 連結叢集。
  • Kubernetes 工作節點

    Kubernetes 工作節點是工作機器，可在 Kubernetes 叢集中執行容器化應用程式。每個叢集至少都有一個工作節點。

  • 傳入控制器

    傳入控制器是在 Kubernetes 叢集中執行並管理傳入資源的元件。它會接收來自外部網路的流量，將其路由到正確的服務，並執行負載平衡和 SSL 終止。傳入控制器通常在叢集中以個別的 Pod 執行，而且可以獨立於其管理的服務進行調整。

  • KUBE 端點 API

    KUBE 端點 API 是 Kubernetes 控制平面的 kube-apiserver 元件。它會執行 Kubernetes API 伺服器。

  • ETCD 備份

    ETCD 備份是 Kubernetes 控制層之 etcd 元件的備份。etcd 包含所有叢集資料的分散式索引鍵值存放區。建立 ETCD 備份以復原 Kubernetes 叢集以進行災害復原是很重要的。

  • YAML 快照

    YAML 快照是包含 Kubernetes 叢集中使用者自建物件定義之 (YAML) 檔案的時間點複本。快照是 tar 檔案，可用來回復相同或不同 Kubernetes 叢集中這些使用者自建物件。

Kubernetes 災害保護的考量

導入 Kubernetes 災害保護時，請考慮下列事項：

  • 對稱式災害復原 (DR) ：Oracle 建議在主要和次要使用完全相同的資源容量和組態。兩個區域中的 Kubernetes 叢集應該有類似的可用資源，例如工作節點數目 (及其硬體容量) 和其他基礎架構 (共用儲存、負載平衡器、資料庫等等)。次要區域中 Kubernetes 叢集相依的資源必須能夠跟上與主要區域相同的工作負載。此外，這兩個系統在功能上必須與還原系統所依據的完全相同服務一致，並必須同時在這兩個位置使用側車、配置圖 (CM)。
  • 主機名稱別名和虛擬化：規劃次要網站中節點使用的主機名稱是很重要的。控制層和工作節點的主機名稱或別名主機名稱在次要位置必須是「作用中」，才能從主要 Kubernetes 叢集回復 etcd 快照。節點名稱會儲存在 Kubernetes 叢集的不同使用者自建物件中，以識別工作節點、標示 Pod 配置、在描述叢集本身的組態 (組態) 對應中，以及在多個組態檔和項目中。您的次要位置必須使用主要 Kubernetes 叢集中使用的相同主機名稱識別工作者、控制層和前端 kube-api 位址 (網域名稱的完整名稱可能不同，但主機名稱必須相同)。如果沒有主機名稱別名，etcd 快照回復將無法正常運作，因為 kubelet、排程器、控制器，而且一般而言，控制層服務將無法連線複製組態所使用的適當端點和主機。請勿使用 IP 位址來識別 Kubernetes 中的節點，請一律改用主機名稱。
  • 映像檔與二進位檔呈現類似的典範：映像檔可能不會隨著 Kubernetes 組態的頻繁變更，而您可能不需要在每個 Kubernetes 叢集複寫更新映像檔。主要系統使用的映像檔必須與次要系統使用的映像檔相同，或者可能發生不一致和失敗的情形。不過，影像複製已超出此手冊的範圍。您可以使用多種策略在兩個位置之間維持一致的影像使用，包括下列各項：
    • 將影像儲存在主要節點並載入至次要的工作節點。此方法非常容易實作，但會造成管理負荷。使用容器登錄具有相當大的優點，並將影像儲存在本機，因此更難管理版本和更新。
    • 映像檔可以位於不同區域的外部容器登錄中，也可以位於主要和待命資料庫所使用的不同區域或資料中心。外部產品與程式庫是由第三方維護，其可用性通常在其版本中為隱含。
    • 影像可以位於主要和待命資料庫的容器登錄中。發行新版影像時，每個區域都會平行更新。這樣可以更有效地控制使用的軟體，但會造成更高的管理負荷。它需要複製影像並管理憑證，才能存取兩個不同的登錄。CI/CD 工具通常用於此方法。
  • 主要和次要叢集之間的差異：就使用的版本和組態而言，主要和次要叢集是相互複製的預期 (一般 DR 系統適用)。下列各方面特別相關：
    1. Kubernetes 版本
    2. 容器程式實際執行和容器程式實際執行版本
    3. 網路 Plugin 和網路 Plugin 版本
    4. podSubnet 和 servicesubnet
    5. etcd hostpath 目錄和 etcd 影像版本
    6. 網路外掛程式與 DN 影像版本 Comment
    7. 控制平面 Pod 的映像檔儲存區域

    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 (主要) 節點：具備 root 權限的使用者

執行下列命令檔：

  • maak8s-force-stop-cp.sh
  • maak8-etcd-backup.sh
  • maak8-etcd-restore.sh
Kubernetes 叢集 (次要)：administrator 執行所有的命令檔。
Kubernetes (次要) 節點：具備 root sudo 權限的使用者 執行下列命令檔：
  • maak8s-force-stop-cp.sh
  • maak8-etcd-backup.sh
  • maak8-etcd-restore.sh

請參閱 Oracle 產品、解決方案和服務，瞭解您需要的內容。