- etcdスナップショットに基づくKubernetesクラスタのリストア
- 障害時リカバリの構成
障害時リカバリの構成
このソリューション・プレイブックで提供される手順およびスクリプトを使用して、プライマリKubernetesクラスタにetcdスナップショットを作成し、別の(セカンダリ)Kubernetesクラスタまたはソース・クラスタ自体にリストアできます。構成を計画し、をダウンロードしてスクリプトを使用してスナップショットを構成する前に要件を理解することが重要です。
ノート:
このソリューションは、コントロール・プレーンおよびワーカー・ノードを含む両方のKubernetesクラスタがすでに存在することを前提としています。構成の計画
プライマリ・システムに基づいて、セカンダリ・システムのリソースと構成を計画します。
ノート:
このソリューションは、コントロール・プレーンおよびワーカー・ノードを含む両方のKubernetesクラスタがすでに存在することを前提としています。このプレイブックで提供される推奨事項およびユーティリティでは、リソース、コントロール・プレーンまたはワーカー・ノードの容量および構成はチェックされません。リストアは、ここで説明するように、プライマリをミラー化するクラスタ(同じ数のコントロール・プレーン・ノード、同じ数のワーカー・ノード)に適用できます。この手順では、kubeadmで作成されたプライマリKubernetesクラスタが存在することを想定しています。次の段落で説明するように、セカンダリ・システムのホスト名はプライマリと同等に構成されます。次に、セカンダリ・クラスタも kubeadmを使用して作成されます(必要なホスト名の解決後のみ)。
構成を計画する場合は、Restoreの次の要件を完了します。
- プライマリ内の必要なワーカー・ノードおよびリソースがセカンダリで使用可能であることを確認します。 これには、リストアされるネームスペースで使用されるポッドおよびシステムで使用される共有ストレージ・マウント、ロード・バランサおよびデータベースが含まれます。
- コントロールおよびワーカー・プレーンで使用されるホスト名がセカンダリで有効になるように、ホスト名解決を構成します。
たとえば、プライマリ・サイトがクラスタを解決する場合、次のようになります。
[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を使用しないでください。このフロントエンドをセカンダリ・システムで別名設定できるように、ホスト名を使用する必要があります。既存のプライマリkube-apiシステムにホスト名別名を追加する方法の例は、maak8s-kube-api-alias.shスクリプトを参照してください。たとえば、プライマリの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パラメータの値を検索します。-
ホストでローカルにホスト名を解決する場合は、ファイル・エントリを
hostsパラメータの最初のエントリにします。filesが hostsパラメータの最初のエントリである場合、ホストの/etc/hostsファイル内のエントリがホスト名の解決で最初に使用されます。/etc/nsswitch.confファイルでのローカル・ホスト名解決の使用の指定:hosts: files dns nis -
ホストでDNSを使用してホスト名を解決する場合は、
DNSエントリをhostsパラメータの最初のエントリにします。DNSがhostsパラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名を解決するために最初に使用されます。DNSホスト名解決
/etc/nsswitch.confファイルの使用の指定:hosts: dns files nis
わかりやすくして一貫性を保つために、Oracleでは、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名解決方法(ローカルでのホスト名の解決または個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。
ミドルウェア・システムの災害保護には、長年使用されてきました。詳細および例は、Oracle Fusion Middlewareディザスタ・リカバリ・ガイドなどのOracle Cloudディザスタ・プロテクションに関するその他のドキュメント(Oracle WebLogic Server for Oracle Cloud Infrastructureディザスタ・リカバリ、Oracle Cloud Infrastructure Marketplace上のSOA Suiteディザスタ・リカバリなど)に記載されたOracleのドキュメントにあります。
-
- フロント・エンドの
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、OSイメージ、カーネル・バージョンおよびコンテナ・ランタイムを確認します:出力例を次に示します。[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、OSイメージ、カーネル・バージョンおよびコンテナ・ランタイムを確認します:[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-infokubeadmクラスタ作成のデフォルト設定では、etcdはプライマリとセカンダリで同じポートを使用します。セカンダリ内のクラスタで異なるポートを使用する必要がある場合は、それを処理するようにスクリプトを変更する必要があります。etcdsデータベースには、プライマリとセカンダリで異なる記憶域の場所を使用できます。スクリプトは、セカンダリ・クラスタがetcdに使用している適切な場所でリストアを処理します。 - プライマリとセカンダリの両方の場所(バックアップおよびリストア・スクリプトを実行するノード)に
etcdctlをインストールします。バックアップおよびリストアのスクリプトでは、etcdctlを使用してクラスタから情報を取得し、etcdスナップショットを作成して適用します。etcdctlをインストールするには、https://github.com/etcd-io/etcd/releasesのドキュメントを参照してください。 - バックアップおよびリストア操作を実行するノードがこのタイプのアクセスに対して有効になるように、適切なファイアウォールおよびセキュリティ・ルールが適用されていることを確認します。スクリプトは、kubectlを使用してクラスタにアクセスし、SSHおよびHTTP (シェル・コマンドおよび
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}' 2379init_portについても同様です。[opc@olk8-m1 ~]$ sudo grep initial-advertise-peer-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}' 2380これらのポートはデフォルトのポートで、コントロール・プレーンのすべての
etcdポッドで使用されます。まれに、各ノードで異なるinitおよびadvertiseポートを使用するようにetcdがカスタマイズされている状況では、これらを考慮するようにスクリプトをカスタマイズする必要があります。また、他のネットワーク・プラグインが使用されている場合、または特定のケースでリストア後に他の関連ポッドまたはデプロイメントを再起動する必要がある場合、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スナップショットを作成します- クラスタの署名キーを含め、各コントロール・プレーン・ノードの現在の構成(各コントロール・プレーン・ノードのマニフェストおよび証明書)のコピーを作成します
- ノード、ポッド、サービスおよびクラスタ構成のリストを記録します
- 上記のすべての情報を日付のラベルが付いたディレクトリに格納します。コマンドライン引数で指定されたディレクトリが
/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スナップショットをリストアします - すべてのコントロール・プレーン・ノードのクラスタ署名キーを置き換えます
- コントロール・プレーンを起動します。
- すべてのインフラストラクチャ・ポッド(プロキシ、スケジューラ、コントローラ)およびクラスタ内のデプロイメント(一貫した状態になるように)をリサイクルします
リストアの終了時に、レポートにはポッドおよび
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スクリプトを実行した後、プライマリ・クラスタに存在していたすべてのアーティファクトがセカンダリ・クラスタにレプリケートされていることを確認します。セカンダリ・クラスタを確認し、セカンダリ・サイトのポッドがエラーなしで実行されていることを確認します。
- 必要なポッドがプライマリの状態と一致するまで、セカンダリのステータスを確認します。 デフォルトでは、ポッドおよびデプロイメントはセカンダリ・リージョンで開始されます。復元の最後に、セカンダリクラスタのステータスが表示されます。一部のポッドは、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専用に作成されます。 - (オプション)元に戻します。
リストア・ログに加えて、前の
/etc/kubernetes構成のバックアップが、/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetesディレクトリにあるコントロール・プレーン・ノードごとに作成されます。同様に、リストア前に各ノードのetcdデータベースが/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_nameにコピーされます。これらを使用して、リストアが実行される前に存在していたクラスタ構成に戻すことができます。