設定災害復原
注意:
此解決方案假設 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 伺服器解析主機名稱)。
「主機名稱別名」技術已用於中介軟體系統的災害保護多年。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.
-
- 使用與主要資料庫相同的前端
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
這些連接埠是預設連接埠,由所有控制層
etcd
Pod 使用。在極少數情況下,自訂etcd
以在每個節點中使用不同的init
和advertise
連接埠,您必須自訂命令檔來考量這些命令檔。如果使用其他網路外掛程式,或者在特定情況下進行還原後必須重新啟動其他相關的 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 可能需要更多時間才能達到「執行中」狀態。
- 檢查次要中的
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
。您可以使用這些來回復執行回復之前存在的叢集組態。