1. 以 etcd 快照為基礎的 Kubernetes 叢集回復
  2. 設定災害復原

設定災害復原

您可以使用本解決方案手冊提供的程序與命令檔，在主要 Kubernetes 叢集建立 etcd 快照，並將其復原到另一個 (次要) Kubernetes 叢集或來源叢集本身。請務必先規劃組態並瞭解需求，再下載和使用命令檔來設定快照。

注意：

此解決方案假設 Kubernetes 叢集 (包括控制層和工作節點) 已經存在。

計畫組態

根據主要系統在次要系統上規劃資源與配置。

注意：

此解決方案假設 Kubernetes 叢集 (包括控制層和工作節點) 已經存在。此手冊提供的建議與公用程式不會檢查資源、控制層或工作節點容量與組態。

如此處所述，還原可套用至「鏡像」主要 (相同數目控制層節點，相同數目工作節點) 的叢集。此程序假設使用 kubeadm 建立的主要 Kubernetes 叢集已存在。次要系統中的主機名稱會設定為主要主機，如下一段所述。接著，次要叢集也會與 kubeadm 一起建立 (但只有在必須解析主機名稱之後才會加以維護)。

規劃組態時，請完成下列 Restore 需求：

  1. 確認主要職工節點與資源在次要節點中為可用。
    這包括將回復之命名空間中使用的共用儲存掛載、負載平衡器，以及 Pod 和系統使用的資料庫。
  2. 設定主機名稱解析，讓控制與工作平面使用的主機名稱在次要裝置中有效。

    例如，如果您的主要網站解析類似以下的叢集：

    [opc@olk8-m1 ~]$ kubectl get nodes -A
NAME      STATUS   ROLES           AGE      VERSION
olk8-m1   Ready    control-plane   552d     v1.25.12
olk8-m2   Ready    control-plane   552d     v1.25.12
olk8-m3   Ready    control-plane   2y213d   v1.25.12
olk8-w1   Ready    <none>          2y213d   v1.25.12
olk8-w2   Ready    <none>          2y213d   v1.25.12
olk8-w3   Ready    <none>          2y213d   v1.25.12
[opc@olk8-m1 ~]$ nslookup olk8-m1
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   olk8-m1.k8dbfrasubnet.k8dbvcn.oraclevcn.com
Address: 10.11.0.16
    然後，您的次要網站必須使用相同的節點名稱。在控制層的上一個範例節點中，區域 2 中的主機名稱將會與不同的 IP 對應。
    [opc@k8dramsnewbastion ~]$ nslookup olk8-m1
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   olk8-m1.sub01261629121.k8drvcnams.oraclevcn.com
Address: 10.5.176.144

[opc@k8dramsnewbastion ~]$
    次要產生的組態 (使用 kubeadm 建立叢集並新增工作節點之後) 將會使用完全相同的節點名稱，即使內部 IP 和其他值遞延也是一樣。
    [opc@k8dramsnewbastion ~]$ kubectl get nodes -A
NAME      STATUS   ROLES           AGE      VERSION
olk8-m1   Ready    control-plane   552d     v1.25.11
olk8-m2   Ready    control-plane   552d     v1.25.11
olk8-m3   Ready    control-plane   2y213d   v1.25.11
olk8-w1   Ready    <none>          2y213d   v1.25.11
olk8-w2   Ready    <none>          2y213d   v1.25.11
olk8-w3   Ready    <none>          2y213d   v1.25.11
  3. 在 kube-api 前端位址使用相似的「主機名稱別名」。

    注意：

    您的主要 kubernetes 叢集不應該在前端 kube-api 使用 IP。您必須使用主機名稱，讓此前端可在次要系統中加以別名。請參閱 maak8s-kube-api-alias.sh 程序檔，以取得如何將主機名稱別名新增至現有主要 kube-api 系統的範例。

    例如，如果主要 kube-api 位址解析如下： 
    [opc@olk8-m1 ~]$  grep server .kube/config
    server: https://k8lbr.paasmaaoracle.com:6443
[opc@olk8-m1 ~]$  grep k8lbr.paasmaaoracle.com /etc/hosts
132.145.247.187 k8lbr.paasmaaoracle.com k8lbr
    接著，次要的 kube-api 應使用相同的主機名稱 (您可以將它對應至不同的 IP)： 
    [opc@k8dramsnewbastion ~]$ grep server .kube/config
    server: https://k8lbr.paasmaaoracle.com:6443
[opc@k8dramsnewbastion ~]$ grep k8lbr.paasmaaoracle.com /etc/hosts
144.21.37.81 k8lbr.paasmaaoracle.com k8lbr
    只要使用虛擬主機、本機 /etc/hosts 解析度或每個位置不同的 DNS 伺服器，即可達到此目的。若要判斷特定主機使用的主機名稱解析方法，請在主機的 /etc/nsswitch.conf 檔案中搜尋主機參數的值。

    • 若要在主機上本機解析主機名稱，請將檔案項目設為 hosts 參數的第一個項目。當 files 是 hosts 參數的第一個項目時，會先使用主機 /etc/hosts 檔案中的項目來解析主機名稱。

      在 /etc/nsswitch.conf 檔案中指定本機主機名稱解析的使用： 

      hosts: files dns nis

    • 如果想要使用主機上的 DNS 來解析主機名稱，請將 dns 項目設為主機參數的第一個項目。當 dns 是 hosts 參數的第一個項目時，會先使用 DNS 伺服器項目來解析主機名稱。

      指定 DNS 主機名稱解析 /etc/nsswitch.conf 檔案的使用： 

      hosts: dns files nis

    為了簡化與一致性，Oracle 建議網站內的所有主機 (生產環境網站或待命網站) 使用相同的主機名稱解析方法 (解析本機主機名稱或使用個別的 DNS 伺服器或全域 DNS 伺服器解析主機名稱)。

    「主機名稱別名」技術已用於中介軟體系統的災害保護多年。You can find details and examples in Oracle’s documentation, including the Oracle Fusion Middleware Disaster Recovery Guide and other documents pertaining to Oracle Cloud Disaster Protection, such as Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery and SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. 使用與主要資料庫相同的前端 kube-api 負載平衡器主機名稱建立次要叢集。
    請在主機名稱解析就緒之後執行此步驟。請參閱 Kubernetes kubeadm 工具文件。請使用與主要版本相同的 kubeadm 和 Kubernetes 版本。容器程式實際執行可能會有所延遲，但您應在兩個區域中使用相同版本的 Kubernetes 基礎架構。
    例如，如果使用下列項目建立主要叢集：
    kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9

    然後，在次要值中使用與主要值完全相同的 $LBR_HN:$LBR_PORT 和 CIDR 值。同樣適用於使用其他叢集建立工具，例如 kOps 和 kubesparay。

  5. 新增其他控制層或工作節點時，請確定在主要和次要節點中使用相同的節點名稱。
    kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca  --control-plane --certificate-key $cp_ca
  6. 次要叢集設定後，從 kubernetes 擷取節點資訊時，應該會顯示相同的主機名稱。

    每個控制層和工作節點次要使用的 $host 變數必須與主要節點中使用的變數相同。

    主要叢集

    在主要節點上執行下列命令，以確認控制層和工作節點狀態、角色、時效、版本、內部 IP、外部 IP、作業系統映像檔、核心版本以及容器程式實際執行：
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
    範例輸出如下。
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
olk8-m1 Ready control-plane 578d v1.25.12 10.11.0.16 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-m2 Ready control-plane 578d v1.25.12 10.11.210.212 <none> Oracle Linux Server 7.9 5.4.17-2136.301.1.3.el7uek.x86_64 cri-o://1.26.1
olk8-m3 Ready control-plane 2y238d v1.25.12 10.11.0.18 <none> Oracle Linux Server 7.9 4.14.35-2047.527.2.el7uek.x86_64 cri-o://1.26.1
olk8-w1 Ready <none> 2y238d v1.25.12 10.11.0.20 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-w2 Ready <none> 2y238d v1.25.12 10.11.0.21 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-w3 Ready <none> 2y238d v1.25.12 10.11.0.22 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
[opc@olk8-m1 ~]$
    在主要位置執行下列命令，以識別 Kubernetes 控制層和核心 DNS 的執行位置。 
    [opc@olk8-m1 ~]$ kubectl cluster-info

    次要叢集

    在次要執行下列命令以確認控制層和工作節點狀態、角色、時效、版本、內部 IP、外部 IP、作業系統映像檔、核心版本以及容器程式實際執行：
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
    範例輸出如下。
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
NAME      STATUS   ROLES           AGE      VERSION    INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                  KERNEL-VERSION                     CONTAINER-RUNTIME
olk8-m1   Ready    control-plane   579d     v1.25.11   10.5.176.144   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-m2   Ready    control-plane   579d     v1.25.11   10.5.176.167   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-m3   Ready    control-plane   2y239d   v1.25.11   10.5.176.154   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-w1   Ready    <none>          2y239d   v1.25.11   10.5.176.205   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
olk8-w2   Ready    <none>          2y239d   v1.25.11   10.5.176.247   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
olk8-w3   Ready    <none>          2y239d   v1.25.11   10.5.176.132   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
[opc@k8dramsnewbastion ~]$ kubectl cluster-info
Kubernetes control plane is running at https://k8lbr.paasmaaoracle.com:6443
CoreDNS is running at https://k8lbr.paasmaaoracle.com:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
[opc@k8dramsnewbastion ~]$
    在次要執行以下命令，以識別 Kubernetes 控制層和核心 DNS 的執行位置。 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    建立 kubeadm 叢集時，etcd 會在主要和次要中使用相同的連接埠。如果次要叢集需要使用不同的連接埠，則必須修改程序檔來處理它。您可以為 etcds 資料庫使用主要和次要儲存位置。程序檔將負責還原次要叢集用於 etcd 的適當位置。

  7. 在主要和次要位置安裝 etcdctl (執行備份和回復命令檔的節點)。
    備份和還原的命令檔將使用 etcdctl 從叢集取得資訊，以及建立和套用 etcd 快照。若要安裝 etcdctl，請參閱 https://github.com/etcd-io/etcd/releases 文件。
  8. 確定已制定適當的防火牆和安全規則，讓執行備份和回復作業的節點能夠進行此類型的存取。
    程序檔也需要使用 kubectl 存取叢集，並透過 SSH 和 HTTP (適用於 Shell 命令和 etcdctl 作業) 找出不同的節點。

設定

設定用於災害復原。

回復的步驟涉及下列步驟：

  1. 在主要位置進行 etcd 備份。
  2. 將備份運送到次要位置。
  3. 回復次要叢集中的 etcd 備份。

執行下列步驟：

  1. 在主要 Kubernetes 叢集中建立 etcd 備份。
    1. 從本文件的「下載程式碼」段落，下載 etcd 快照 DR 的所有命令檔。

      注意：

      所有指令碼都必須位於相同路徑，因為主要指令碼使用其他輔助指令碼。
    2. 從控制層節點 etcd 組態取得 advert_port 。
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
      而且與 init_port 相同： 
      [opc@olk8-m1 ~]$  sudo grep initial-advertise-peer-urls  /etc/kubernetes/manifests/etcd.yaml  | awk -F ":" '{print $NF}'

2380

      這些連接埠是預設連接埠，由所有控制層 etcd Pod 使用。在極少數情況下，自訂 etcd 以在每個節點中使用不同的 init 和 advertise 連接埠，您必須自訂命令檔來考量這些命令檔。如果使用其他網路外掛程式，或者在特定情況下進行還原後必須重新啟動其他相關的 Pod 或部署，您也可以自訂 infra_pod_list 的值。不過，通常可以預設為檔案中所提供的值。

    3. 編輯 maak8s.env 指令碼，並根據您的環境更新變數。
      以下是一個 maak8s.env 檔案的範例：
      [opc@olk8-m1 ~]$ cat maak8s.env
#sudo ready user to ssh into the control plane nodes
export user=opc
#ssh key for the ssh
export ssh_key=/home/opc/KeyMAA.ppk
#etcdctl executable's location
export etcdctlhome=/scratch/etcdctl/
#etcd advertise port
export advert_port=2379
#etcd init cluster port
export init_port=2380
#infrastructure pods that will be restarted  on restore
export infra_pod_list="flannel proxy controller scheduler"
    4. 執行 maak8-etcd-backup.sh 程序檔，並以此順序提供下列欄位的引數：
      • 儲存備份的目錄
      • 描述備份的 "LABEL/TEXT"
      • 執行 kubectl 作業的叢集組態位置
      例如：
      [opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config

    此命令檔會執行下列作業：

    • 從 etcd 主節點建立 etcd 快照
    • 建立每個控制層節點目前組態的複本 (每個控制層節點的清單和憑證)，包括叢集的簽署金鑰
    • 記錄節點、Pod、服務和叢集組態的清單
    • 將上述所有資訊儲存在以日期標示的目錄中。如果命令行引數中指定的目錄是 /backup-volume，則備份會儲存在備份的 /backup-volume/etcd_snapshot_date 下。例如，/backup-volume/etcd_snapshot_2022-08-29_15-56-59。
  2. 將整個目錄 (/backup-volume/etcd_snapshot_date) 複製到次要叢集。
    1. 使用 sftp 工具或建立目錄的 tar，然後將它傳送到次要位置。
    2. 將檔案解壓縮或解壓縮，使其在次要系統中可用，因為它是主要檔案。
    3. 請記下備份中的日期標籤 (在上述範例中為 2022-08-29_15-56-59)。
    例如，
    [opc@olk8-m1 ~]$ scp -i KeyMAA.ppk -qr /backup-volume/etcd_snapshot_2022-08-29_15-56-59 154.21.39.171:/restore-volume
[opc@olk8-m1 ~]$ ssh -i KeyMAA.ppk 154.21.39.171 "ls -lart /restore-volume"
total 4
drwxrwxrwt. 6 root root  252 Aug 30 15:11 ..
drwxrwxr-x. 3 opc  opc    47 Aug 30 15:12 .
drwxrwxr-x. 5 opc  opc  4096 Aug 30 15:12 etcd_snapshot_2022-08-29_15-56-59
  3. 次要位置提供備份之後，請依照下列步驟將備份回復：
    1. 將 etcd 快照 DR 的所有命令檔從「下載程式碼」區段下載至將執行回復的次要區域節點。
      請記住，此節點也必須已安裝 etcdctl 和 kubectl 存取次要叢集。

      注意：

      因為主要程序檔使用其他輔助程序檔，所以在執行不同的步驟時，您必須在相同的路徑中包含所有程序檔。
    2. 編輯 maak8s.env 指令碼，並根據您的環境更新變數。
      您可以根據次要節點來更改使用者、ssh 金鑰和 etcdctl 位置，但是 advert 和 init 連接埠必須與主要節點所使用的連接埠相同。
      以下是一個 maak8s.env 檔案的範例：
      [opc@olk8-m1 ~]$ cat maak8s.env
#sudo ready user to ssh into the control plane nodes
export user=opc
#ssh key for the ssh
export ssh_key=/home/opc/KeyMAA.ppk
#etcdctl executable's location
export etcdctlhome=/scratch/etcdctl/
#etcd advertise port
export advert_port=2379
#etcd init cluster port
export init_port=2380
#infrastructure pods that will be restarted  on restore
export infra_pod_list="flannel proxy controller scheduler"
    3. 使用 maak8-etcd-restore.sh 命令檔執行回復。提供作為引數，將備份從主要複製到待命的根目錄、備份的時戳，以及叢集的 kubectl 組態位置。
      例如， 
      [opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config

      此程序檔會在 /restore-volume 目錄中尋找名為 etcd_snapshot_date 的子目錄。此範例將使用 /restore-volume/etcd_snapshot_2022-08-29_15-56-59。

      回復會執行以下作業：
      • 如果控制平面正在執行中，則強制停止次要控制平面
      • 回復所有控制層節點中的 etcd 快照
      • 取代所有控制層節點中的叢集簽署金鑰
      • 開始控制平面
      • 循環使用叢集中的所有基礎架構 Pod (代理主機、排程器、控制器) 和部署項目 (使其變成一致狀態)

      回復結束時，報告會顯示 Pod 和 etcd 子系統的狀態。例如， 

      NAMESPACE      NAME                                         READY   STATUS              RESTARTS       AGE
default        dnsutils                                     1/1     Running             0              27d
default        nginx-deployment-566ff9bd67-6rl7f            1/1     Running             0              19s
default        nginx-deployment-566ff9bd67-hnx69            1/1     Running             0              17s
default        nginx-deployment-566ff9bd67-hvrwq            1/1     Running             0              15s
default        test-pd                                      1/1     Running             0              26d
kube-flannel   kube-flannel-ds-4f2fz                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-cvqzh                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-dmbhp                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-skhz2                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-zgkkp                        1/1     Running             4 (22d ago)    35d
kube-flannel   kube-flannel-ds-zpbn7                        1/1     Running             3 (22d ago)    35d
kube-system    coredns-8f994fbf8-6ghs4                      0/1     ContainerCreating   0              15s
kube-system    coredns-8f994fbf8-d79h8                      1/1     Running             0              19s
kube-system    coredns-8f994fbf8-wcknd                      1/1     Running             0              12s
kube-system    coredns-8f994fbf8-zh8w4                      1/1     Running             0              19s
kube-system    etcd-olk8-m1                                 1/1     Running             22 (89s ago)   44s
kube-system    etcd-olk8-m2                                 1/1     Running             59 (88s ago)   44s
kube-system    etcd-olk8-m3                                 1/1     Running             18 (88s ago)   26s
kube-system    kube-apiserver-olk8-m1                       1/1     Running             26 (89s ago)   44s
kube-system    kube-apiserver-olk8-m2                       1/1     Running             60 (88s ago)   42s
kube-system    kube-apiserver-olk8-m3                       1/1     Running             18 (88s ago)   27s
kube-system    kube-controller-manager-olk8-m1              1/1     Running             19 (89s ago)   10s
kube-system    kube-controller-manager-olk8-m2              1/1     Running             18 (88s ago)   10s
kube-system    kube-controller-manager-olk8-m3              1/1     Running             18 (88s ago)   10s
kube-system    kube-flannel-ds-62dcq                        1/1     Running             0              19s
kube-system    kube-flannel-ds-bh5w7                        1/1     Running             0              19s
kube-system    kube-flannel-ds-cc2rk                        1/1     Running             0              19s
kube-system    kube-flannel-ds-p8kdk                        1/1     Running             0              19s
kube-system    kube-flannel-ds-vj8r8                        1/1     Running             0              18s
kube-system    kube-flannel-ds-wz2kv                        1/1     Running             0              18s
kube-system    kube-proxy-28d98                             1/1     Running             0              14s
kube-system    kube-proxy-2gb99                             1/1     Running             0              15s
kube-system    kube-proxy-4dfjd                             1/1     Running             0              14s
kube-system    kube-proxy-72l5q                             1/1     Running             0              14s
kube-system    kube-proxy-s8zbs                             1/1     Running             0              14s
kube-system    kube-proxy-tmqnm                             1/1     Running             0              14s
kube-system    kube-scheduler-olk8-m1                       0/1     Pending             0              5s
kube-system    kube-scheduler-olk8-m2                       1/1     Running             18 (88s ago)   5s
kube-system    kube-scheduler-olk8-m3                       1/1     Running             18 (88s ago)   5s
newopns        weblogic-operator-5d74f56886-mtjp6           0/1     Terminating         0              26d
newopns        weblogic-operator-webhook-768d9f6f79-tdt8b   0/1     Terminating         0              26d
soans          soaedgdomain-adminserver                     0/1     Running             0              22d
soans          soaedgdomain-soa-server1                     0/1     Running             0              22d
soans          soaedgdomain-soa-server2                     0/1     Running             0              22d
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|   ENDPOINT   |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| olk8-m1:2379 | 63c63522f0be24a6 |   3.5.6 |  146 MB |      true |      false |         2 |       1195 |               1195 |        |
| olk8-m2:2379 | 697d3746d6f10842 |   3.5.6 |  146 MB |     false |      false |         2 |       1195 |               1195 |        |
| olk8-m3:2379 |  7a23c67093a3029 |   3.5.6 |  146 MB |     false |      false |         2 |       1195 |               1195 |        |
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
+------------------+---------+---------+----------------------+---------------------------+------------+
|        ID        | STATUS  |  NAME   |      PEER ADDRS      |       CLIENT ADDRS        | IS LEARNER |
+------------------+---------+---------+----------------------+---------------------------+------------+
|  7a23c67093a3029 | started | olk8-m3 | https://olk8-m3:2380 | https://10.5.176.154:2379 |      false |
| 63c63522f0be24a6 | started | olk8-m1 | https://olk8-m1:2380 | https://10.5.176.144:2379 |      false |
| 697d3746d6f10842 | started | olk8-m2 | https://olk8-m2:2380 | https://10.5.176.167:2379 |      false |
+------------------+---------+---------+----------------------+---------------------------+------------+
Restore completed at 2023-08-30_15-18-22
[opc@k8dramsnewbastion ~]$

驗證

執行 maak8DR-apply.sh 命令檔之後，請確認已將主要叢集中存在的所有使用者自建物件複製到次要叢集。查看次要叢集，並確認次要網站中的 Pod 執行時沒有錯誤。
  1. 檢查次要裝置的狀態，直到所需 Pod 符合主要節點的狀態為止。
    預設會在次要區域中啟動 Pod 和部署。回復結束時，會顯示次要叢集的狀態。有些 Pod 可能需要更多時間才能達到「執行中」狀態。
  2. 檢查次要中的 restore 日誌是否有可能的錯誤。
    日誌位置會在回復開始時報告。預設會將日誌建立在備份本身所在的目錄下，位於 /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log。另一個日誌是特別針對 etcd 快照回復作業 /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log 建立。
  3. (可選擇) 回復。

    除了回復日誌之外，還會為 /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes 目錄下的每個控制層節點建立上一個 /etc/kubernetes 組態的備份。同樣地，還原前每個節點中的 etcd 資料庫會複製到 /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name。您可以使用這些來回復執行回復之前存在的叢集組態。