設定災害復原
您可以使用本解決方案手冊隨附的程序和命令檔，在主要 Kubernetes 叢集中建立
etcd 快照，並在另一個 (次要) Kubernetes 叢集或來源叢集中加以回復。請務必先規劃組態並瞭解需求，再下載和使用命令檔來設定快照。
附註：
此解決方案假設兩個 Kubernetes 叢集 (包括控制層和工作節點) 都已存在。規劃組態
根據主要系統規劃次要系統上的資源和配置。
附註：
此解決方案假設兩個 Kubernetes 叢集 (包括控制層和工作節點) 都已存在。此手冊中提供的建議與公用程式不會檢查資源、控制層或工作節點容量與組態。回復 (如此處所述) 可套用至「鏡像」主要 (相同數目的控制層節點，相同數目的工作節點) 的叢集。此程序假設使用 kubeadm 建立的主要 Kubernetes 叢集存在。次要系統中的主機名稱會設定為模擬主要名稱，如下一段所述。接著，也會使用 kubeadm 建立次要叢集 (僅在進行必要主機名稱解析之後才會執行)。
規劃組態時，請完成下列 Restore 需求：
- 確認主要工作節點和資源在次要工作中可以使用。 這包括將回復之命名空間中使用的 Pod 和系統所使用的共用儲存掛載、負載平衡器以及資料庫。
- 設定主機名稱解析，讓控制與工作平面使用的主機名稱在次要有效。
例如，如果主要網站解析叢集的方式與下列類似：
[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 - 在
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 伺服器解析主機名稱)。
「主機名稱別名」技術已用於中介軟體系統災害保護多年。您可以在 Oracle 的文件中找到詳細資訊和範例，包括 Oracle Fusion Middleware Disaster Recovery Guide 和與 Oracle Cloud Disaster Protection 相關的其他文件，例如 Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery 和 Oracle Cloud Infrastructure Marketplace Disaster Recovery 上的 SOA Suite 。
-
- 使用與主要負載平衡器相同的前端
kube-api負載平衡器主機名稱建立次要叢集。在您的主機名稱解析就緒之後執行此步驟。請參閱 Kuberneteskubeadm工具文件。使用與主要版本相同的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)，則同樣適用。 - 新增其他控制層或工作節點時，請確定您在主要和次要節點中使用相同的節點名稱。
kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca --control-plane --certificate-key $cp_ca - 設定次要叢集之後，從 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的適當位置進行回復。 - 同時在主要和次要位置安裝
etcdctl(執行備份和回復命令檔的節點)。備份和回復的命令檔將使用etcdctl從叢集取得資訊，以及建立和套用etcd快照。若要安裝etcdctl，請參閱 https://github.com/etcd-io/etcd/releases 文件。 - 請確定有適當的防火牆和安全規則，以便為此類型的存取啟用執行備份和回復作業的節點。命令檔也需要使用
kubectl來存取叢集，並透過 SSH 和 HTTP (針對 Shell 命令和etcdctl作業) 來連線不同的節點。
設定
設定災害復原。
回復的步驟如下：
- 在主要位置進行
etcd備份。 - 將備份運送至次要位置。
- 回復次要叢集中的
etcd備份。
請執行以下步驟：
- 在主要 Kubernetes 叢集中建立
etcd備份。- 從本文件的「下載程式碼」區段下載
etcd快照 DR 的所有命令檔。附註：
所有指令檔都必須位於相同的路徑，因為主要指令檔使用其他輔助指令檔。 - 從控制層節點
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這些連接埠是預設連接埠，由所有控制層的
etcdPod 使用。在etcd自訂為在每個節點使用不同init和advertise連接埠的罕見情況中，您必須自訂命令檔來考量這些命令檔。如果使用其他網路 Plugin 或其他相關的 Pod 或部署必須在回復後重新啟動，您也可以自訂infra_pod_list的值。不過，一般而言，它可以預設為檔案中提供的值。 - 編輯
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" - 執行
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。
- 從本文件的「下載程式碼」區段下載
- 將整個目錄 (
/backup-volume/etcd_snapshot_date) 複製到次要叢集。- 使用
sftp工具或使用目錄建立 tar，然後將它傳送到次要位置。 - 將檔案解壓縮或解壓縮，使其在次要系統中可用，因為它位於主要系統中。
- 記下備份中的日期標籤 (如上面的範例所示為 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 - 使用
- 在次要位置提供備份之後，請依照下列步驟進行回復：
- 將
etcd快照 DR 的所有指令碼從「下載代碼」區段下載至將執行回復的次要區域節點。請記住，此節點也必須安裝etcdctl，以及次要叢集的kubectl存取權。附註：
因為主要指令檔使用其他輔助指令檔，所以當執行不同的步驟時，所有指令檔都必須位於相同路徑中。 - 編輯
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" - 使用
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 在執行時沒有發生錯誤。
- 檢查次要 Pod 的狀態，直到所需的 Pod 與主要狀態相符為止。 Pod 和部署預設會在次要區域中啟動。回復結束時，會顯示次要叢集的狀態。部分 Pod 可能需要更多時間才能達到 RUNNING 狀態。
- 請查看次要的
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建立另一個日誌。 - (選擇性) 回復。
除了回復日誌之外，還會為
/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。您可以使用這些來回復至執行回復之前存在的叢集組態。