This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.3.3. クラスターの直前の状態への復元
クラスターを直前の状態に復元するには、スナップショットを作成して、事前に etcd データのバックアップを行っている必要があります。このスナップショットを使用して、クラスターの状態を復元します。
3.3.1. クラスターの直前の状態への復元 リンクのコピーリンクがクリップボードにコピーされました!
保存された etcd バックアップを使用して、クラスターの以前の状態に戻すことができます。etcd バックアップを使用して単一のマスターホストを復元します。次に、etcd クラスター Operator は残りのマスターホストへのスケーリングを処理します。
クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.4.2 クラスターは、4.4.2 から取得した etcd バックアップを使用する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてのクラスターへのアクセスがあること。 - マスターホストへの SSH アクセス。
-
etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、
snapshot_<datetimestamp>.db
およびstatic_kuberesources_<datetimestamp>.tar.gz
の形式にする必要があります。
手順
- リカバリーホストとして使用するマスターホストを選択します。これは、復元操作を実行するホストです。
リカバリーホストを含む、各マスターノードへの SSH 接続を確立します。
Kubernetes API サーバーは復元プロセスが開始するとアクセスできなくなるため、マスターノードにはアクセスできません。このため、別のターミナルで各マスターホストに SSH 接続を確立することが推奨されます。
重要この手順を完了しないと、復元手順を完了するためにマスターホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。
etcd バックアップディレクトリーをリカバリーマスターホストにコピーします。
この手順では、etcd スナップショットおよび静的 Pod のリソースを含む
backup
ディレクトリーを、リカバリーマスターホストの/home/core/
ディレクトリーにコピーしていることを前提としています。他のすべてのマスターノードで静的 Pod を停止します。
注記リカバリーホストで Pod を手動で停止する必要はありません。リカバリースクリプトは、リカバリーホストの Pod を停止します。
- リカバリーホストではないマスターホストにアクセスします。
既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
[core@ip-10-0-154-194 ~]$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd Pod が停止していることを確認します。
sudo crictl ps | grep etcd | grep -v operator
[core@ip-10-0-154-194 ~]$ sudo crictl ps | grep etcd | grep -v operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
既存の Kubernetes API サーバー Pod ファイルを kubelet マニフェストディレクトリーから移動します。
sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
[core@ip-10-0-154-194 ~]$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes API サーバー Pod が停止していることを確認します。
sudo crictl ps | grep kube-apiserver | grep -v operator
[core@ip-10-0-154-194 ~]$ sudo crictl ps | grep kube-apiserver | grep -v operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
etcd データディレクトリーを別の場所に移動します。
sudo mv /var/lib/etcd/ /tmp
[core@ip-10-0-154-194 ~]$ sudo mv /var/lib/etcd/ /tmp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - リカバリーホストではない他のマスターホストでこの手順を繰り返します。
- リカバリーマスターホストにアクセスします。
クラスター全体のプロキシーが有効になっている場合は、
NO_PROXY
、HTTP_PROXY
、およびHTTPS_PROXY
環境変数をエクスポートしていることを確認します。ヒントoc get proxy cluster -o yaml
の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy
、httpsProxy
、およびnoProxy
フィールドに値が設定されている場合に有効にされます。リカバリーマスターホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのマスターホストで kubelet サービスを再起動します。
リカバリーホストから以下のコマンドを実行します。
sudo systemctl restart kubelet.service
[core@ip-10-0-143-125 ~]$ sudo systemctl restart kubelet.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 他のすべてのマスターホストでこの手順を繰り返します。
単一メンバーのコントロールプレーンが正常に起動していることを確認します。
リカバリーホストから etcd コンテナーが実行中であることを確認します。
sudo crictl ps | grep etcd | grep -v operator
[core@ip-10-0-143-125 ~]$ sudo crictl ps | grep etcd | grep -v operator 3ad41b7908e32 36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009 About a minute ago Running etcd 0 7c05f8af362f0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リカバリーホストから、etcd Pod が実行されていることを確認します。
oc get pods -n openshift-etcd | grep etcd
[core@ip-10-0-143-125 ~]$ oc get pods -n openshift-etcd | grep etcd NAME READY STATUS RESTARTS AGE etcd-ip-10-0-143-125.ec2.internal 1/1 Running 1 2m47s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドを実行する前に
oc login
の実行を試行し、以下のエラーを受信すると、認証コントローラーが起動し、再試行するまでしばらく待機します。Unable to connect to the server: EOF
Unable to connect to the server: EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ステータスが
Pending
の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。
etcd の再デプロイメントを強制的に実行します。
クラスターにアクセスできるターミナルで、
cluster-admin
ユーザーとして以下のコマンドを実行します。oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
forceRedeploymentReason
値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。
すべてのノードが最新のリビジョンに更新されていることを確認します。
クラスターにアクセスできるターミナルで、
cluster-admin
ユーザーとして以下のコマンドを実行します。oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd の
NodeInstallerProgressing
状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevision
が表示されます。AllNodesAtLatestRevision 3 nodes are at revision 3
AllNodesAtLatestRevision 3 nodes are at revision 3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
2 nodes are at revision 3; 1 nodes are at revision 4
などのメッセージが表示される場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、Kubernetes API サーバーは他のノードに再インストールされます。
クラスターにアクセスできるターミナルで、
cluster-admin
ユーザーとして以下のコマンドを実行します。kubeapiserver
を更新します。oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのノードが最新のリビジョンに更新されていることを確認します。
oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeInstallerProgressing
状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevision
が表示されます。AllNodesAtLatestRevision 3 nodes are at revision 3
AllNodesAtLatestRevision 3 nodes are at revision 3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubecontrollermanager
を更新します。oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのノードが最新のリビジョンに更新されていることを確認します。
oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeInstallerProgressing
状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevision
が表示されます。AllNodesAtLatestRevision 3 nodes are at revision 3
AllNodesAtLatestRevision 3 nodes are at revision 3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubescheduler
を更新します。oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのノードが最新のリビジョンに更新されていることを確認します。
oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeInstallerProgressing
状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevision
が表示されます。AllNodesAtLatestRevision 3 nodes are at revision 3
AllNodesAtLatestRevision 3 nodes are at revision 3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのマスターホストが起動しており、クラスターに参加していることを確認します。
クラスターにアクセスできるターミナルで、
cluster-admin
ユーザーとして以下のコマンドを実行します。oc get pods -n openshift-etcd | grep etcd
$ oc get pods -n openshift-etcd | grep etcd etcd-ip-10-0-143-125.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-154-194.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-173-171.ec2.internal 2/2 Running 0 9h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順の完了後、すべてのサービスを復元するまでに数分かかる場合があります。たとえば、oc login
を使用した認証は、OAuth サーバー Pod が再起動するまですぐに機能しない可能性があります。