- Kubernetesクラスタは、etcdスナップショットに基づいてリストアされます
- 障害時リカバリの構成
障害時リカバリの構成
このソリューション・プレイブックに付属しているプロシージャおよびスクリプトを使用して、プライマリ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のドキュメント(Oracle Fusion Middleware障害リカバリ・ガイド、およびOracle WebLogic Server for Oracle Cloud Infrastructureの障害リカバリやOracle Cloud Infrastructure MarketplaceのSOA Suiteの障害リカバリなど、Oracle Cloudの障害保護に関するその他のドキュメントなど)にあります。
-
- プライマリと同じホスト名をフロント・エンド
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ポッドで使用されます。etcdが各ノードで異なるinitおよびadvertiseポートを使用するようにカスタマイズされているまれな状況では、これらのポートを考慮するようにスクリプトをカスタマイズする必要があります。特定のケースのリストア後に他のネットワーク・プラグインが使用されている場合、または他の関連するポッドまたはデプロイメントを再起動する必要がある場合は、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用に特別に別のログが作成されます。 - (オプション)元に戻します。
リストア・ログに加えて、
/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にコピーされます。これらを使用して、リストアが実行される前に存在していたクラスタ構成に戻すことができます。