6.12. etcd タスク

etcd のバックアップ、etcd 暗号化の有効化または無効化、または etcd データのデフラグを行います。

6.12.1. etcd 暗号化について
リンクのコピー

デフォルトで、etcd データは OpenShift Container Platform で暗号化されません。クラスターの etcd 暗号化を有効にして、データセキュリティーのレイヤーを追加で提供することができます。たとえば、etcd バックアップが正しくない公開先に公開される場合に機密データが失われないように保護することができます。

etcd の暗号化を有効にすると、以下の OpenShift API サーバーおよび Kubernetes API サーバーリソースが暗号化されます。

シークレット
config map
ルート
OAuth アクセストークン
OAuth 認証トークン

etcd 暗号を有効にすると、暗号化キーが作成されます。etcd バックアップから復元するには、これらのキーが必要です。

注記

etcd 暗号化は、キーではなく、値のみを暗号化します。リソースの種類、namespace、およびオブジェクト名は暗号化されません。

バックアップ中に etcd 暗号化が有効になっている場合は、static_kuberesources_<datetimestamp>.tar.gz ファイルに etcd スナップショットの暗号化キーが含まれています。セキュリティー上の理由から、このファイルは etcd スナップショットとは別に保存してください。ただし、このファイルは、それぞれの etcd スナップショットから etcd の以前の状態を復元するために必要です。

6.12.2. サポートされている暗号化の種類
リンクのコピー

以下の暗号化タイプは、OpenShift Container Platform で etcd データを暗号化するためにサポートされています。

AES-CBC: 暗号化を実行するために、PKCS#7 パディングと 32 バイトの鍵を含む AES-CBC を使用します。暗号化キーは毎週ローテーションされます。
AES-GCM: AES-GCM とランダムナンスおよび 32 バイトキーを使用して暗号化を実行します。暗号化キーは毎週ローテーションされます。

6.12.3. etcd 暗号化の有効化
リンクのコピー

etcd 暗号化を有効にして、クラスターで機密性の高いリソースを暗号化できます。

警告

初期暗号化プロセスが完了するまで、etcd リソースをバックアップしないでください。暗号化プロセスが完了しない場合、バックアップは一部のみ暗号化される可能性があります。

etcd 暗号化を有効にすると、いくつかの変更が発生する可能性があります。

etcd 暗号化は、いくつかのリソースのメモリー消費に影響を与える可能性があります。
リーダーがバックアップを提供する必要があるため、バックアップのパフォーマンスに一時的な影響が生じる場合があります。
ディスク I/O は、バックアップ状態を受け取るノードに影響を与える可能性があります。

etcd データベースは、AES-GCM または AES-CBC 暗号化で暗号化できます。

注記

etcd データベースをある暗号化タイプから別の暗号化タイプに移行するには、API サーバーの spec.encryption.type フィールドを変更します。etcd データの新しい暗号化タイプへの移行は自動的に行われます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

APIServer オブジェクトを変更します。
```
oc edit apiserver
```
```
$ oc edit apiserver
```
Copy to Clipboard Toggle word wrap
spec.encryption.type フィールドを aesgcm または aescbc に設定します。
```
spec:
  encryption:
    type: aesgcm 
```
```
spec:
  encryption:
    type: aesgcm 
```
1
Copy to Clipboard Toggle word wrap
1
AES-CBC 暗号化の場合は aescbc に、AES-GCM 暗号化の場合は aesgcm に設定します。
変更を適用するためにファイルを保存します。
暗号化プロセスが開始されます。etcd データベースのサイズによっては、このプロセスが完了するまでに 20 分以上かかる場合があります。
etcd 暗号化が正常に行われたことを確認します。
1. OpenShift API サーバーの Encrypted ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。
  $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。
  EncryptionCompleted All resources encrypted: routes.route.openshift.io
  Copy to Clipboard Toggle word wrap
  出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。
2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に暗号化されたことを確認します。
  $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。
  EncryptionCompleted All resources encrypted: secrets, configmaps
  Copy to Clipboard Toggle word wrap
  出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。
3. OpenShift OAuth API サーバーの Encrypted ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。
  $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。
  EncryptionCompleted All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
  Copy to Clipboard Toggle word wrap
  出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

6.12.4. etcd 暗号化の無効化
リンクのコピー

クラスターで etcd データの暗号化を無効にできます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

APIServer オブジェクトを変更します。
```
oc edit apiserver
```
```
$ oc edit apiserver
```
Copy to Clipboard Toggle word wrap
encryption フィールドタイプを identity に設定します。
```
spec:
  encryption:
    type: identity 
```
```
spec:
  encryption:
    type: identity 
```
1
Copy to Clipboard Toggle word wrap
1
identity タイプはデフォルト値であり、暗号化は実行されないことを意味します。
変更を適用するためにファイルを保存します。
復号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。
etcd の復号化が正常に行われたことを確認します。
1. OpenShift API サーバーの Encrypted ステータス条件を確認し、そのリソースが正常に暗号化されたことを確認します。
  $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。
  DecryptionCompleted Encryption mode set to identity and everything is decrypted
  Copy to Clipboard Toggle word wrap
  出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。
2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に復号化されたことを確認します。
  $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。
  DecryptionCompleted Encryption mode set to identity and everything is decrypted
  Copy to Clipboard Toggle word wrap
  出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。
3. OpenShift API サーバーの Encrypted ステータス条件を確認し、そのリソースが正常に復号化されたことを確認します。
  $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。
  DecryptionCompleted Encryption mode set to identity and everything is decrypted
  Copy to Clipboard Toggle word wrap
  出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

6.12.5. etcd データのバックアップ
リンクのコピー

以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。

重要

単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
クラスター全体のプロキシーが有効になっているかどうかを確認している。
ヒント
oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

手順

コントロールプレーンノードの root としてデバッグセッションを開始します。
```
oc debug --as-root node/<node_name>
```
```
$ oc debug --as-root node/<node_name>
```
Copy to Clipboard Toggle word wrap
デバッグシェルで root ディレクトリーを /host に変更します。
```
chroot /host
```
```
sh-4.4# chroot /host
```
Copy to Clipboard Toggle word wrap
クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートします。
```
export HTTP_PROXY=http://<your_proxy.example.com>:8080
```
```
$ export HTTP_PROXY=http://<your_proxy.example.com>:8080
```
Copy to Clipboard Toggle word wrap
```
export HTTPS_PROXY=https://<your_proxy.example.com>:8080
```
```
$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
```
Copy to Clipboard Toggle word wrap
```
export NO_PROXY=<example.com>
```
```
$ export NO_PROXY=<example.com>
```
Copy to Clipboard Toggle word wrap

デバッグシェルで cluster-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。

ヒント

cluster-backup.sh スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save コマンドに関連するラッパーです。

/usr/local/bin/cluster-backup.sh /home/core/assets/backup

sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

Copy to Clipboard

Toggle word wrap

スクリプトの出力例

found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup

found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup

Copy to Clipboard

Toggle word wrap

この例では、コントロールプレーンホストの /home/core/assets/backup/ ディレクトリーにファイルが 2 つ作成されます。

snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.sh スクリプトで、その有効性を確認します。
static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。
注記
etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。
etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。

6.12.6. etcd データのデフラグ
リンクのコピー

大規模で密度の高いクラスターの場合に、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd は低下するパフォーマンスの影響を受ける可能性があります。etcd を定期的に維持および最適化して、データストアのスペースを解放します。Prometheus で etcd メトリックをモニターし、必要に応じてデフラグします。そうしないと、etcd はクラスター全体のアラームを発生させ、クラスターをメンテナンスモードにして、キーの読み取りと削除のみを受け入れる可能性があります。

これらの主要な指標をモニターします。

etcd_server_quota_backend_bytes、これは現在のクォータ制限です
etcd_mvcc_db_total_size_in_use_in_bytes、これはヒストリーコンパクション後の実際のデータベース使用状況を示します。
etcd_mvcc_db_total_size_in_bytes はデフラグ待ちの空き領域を含むデータベースサイズを表します。

etcd データをデフラグし、etcd 履歴の圧縮などのディスクの断片化を引き起こすイベント後にディスク領域を回収します。

履歴の圧縮は 5 分ごとに自動的に行われ、これによりバックエンドデータベースにギャップが生じます。この断片化された領域は etcd が使用できますが、ホストファイルシステムでは利用できません。ホストファイルシステムでこの領域を使用できるようにするには、etcd をデフラグする必要があります。

デフラグは自動的に行われますが、手動でトリガーすることもできます。

注記

etcd Operator はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。

6.12.6.1. 自動デフラグ
リンクのコピー

etcd Operator はディスクを自動的にデフラグします。手動による介入は必要ありません。

以下のログのいずれかを表示して、デフラグプロセスが成功したことを確認します。

etcd ログ
cluster-etcd-operator Pod
Operator ステータスのエラーログ

警告

自動デフラグにより、Kubernetes コントローラーマネージャーなどのさまざまな OpenShift コアコンポーネントでリーダー選出の失敗が発生し、失敗したコンポーネントの再起動がトリガーされる可能性があります。再起動は無害であり、次に実行中のインスタンスへのフェイルオーバーをトリガーするか、再起動後にコンポーネントが再び作業を再開します。

最適化が成功した場合のログ出力の例

etcd member has been defragmented: <member_name>, memberID: <member_id>

etcd member has been defragmented: <member_name>, memberID: <member_id>

Copy to Clipboard

Toggle word wrap

最適化に失敗した場合のログ出力の例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>

Copy to Clipboard

Toggle word wrap

6.12.6.2. 手動デフラグ
リンクのコピー

Prometheus アラートは、手動でのデフラグを使用する必要がある場合を示します。アラートは次の 2 つの場合に表示されます。

etcd が使用可能なスペースの 50% 以上を 10 分を超過して使用する場合
etcd が合計データベースサイズの 50% 未満を 10 分を超過してアクティブに使用している場合

また、PromQL 式を使用した最適化によって解放される etcd データベースのサイズ (MB 単位) を確認することで、最適化が必要かどうかを判断することもできます ((etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024)。

警告

etcd のデフラグはプロセスを阻止するアクションです。etcd メンバーはデフラグが完了するまで応答しません。このため、各 Pod のデフラグアクションごとに少なくとも 1 分間待機し、クラスターが回復できるようにします。

以下の手順に従って、各 etcd メンバーで etcd データをデフラグします。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

リーダーを最後にデフラグする必要があるため、どの etcd メンバーがリーダーであるかを判別します。

etcd Pod のリストを取得します。

oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

Copy to Clipboard

Toggle word wrap

出力例

etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

Copy to Clipboard

Toggle word wrap

Pod を選択し、以下のコマンドを実行して、どの etcd メンバーがリーダーであるかを判別します。

oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

Copy to Clipboard

Toggle word wrap

出力例

Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Copy to Clipboard

Toggle word wrap

この出力の IS LEADER 列に基づいて、https://10.0.199.170:2379 エンドポイントがリーダーになります。このエンドポイントを直前の手順の出力に一致させると、リーダーの Pod 名は etcd-ip-10-0-199-170.example.redhat.com になります。

etcd メンバーのデフラグ。

実行中の etcd コンテナーに接続し、リーダーではない Pod の名前を渡します。
```
oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
```
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
```
Copy to Clipboard Toggle word wrap
ETCDCTL_ENDPOINTS 環境変数の設定を解除します。
```
unset ETCDCTL_ENDPOINTS
```
```
sh-4.4# unset ETCDCTL_ENDPOINTS
```
Copy to Clipboard Toggle word wrap
etcd メンバーのデフラグを実行します。
```
etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
```
```
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
```
Copy to Clipboard Toggle word wrap
出力例
```
Finished defragmenting etcd member[https://localhost:2379]
```
```
Finished defragmenting etcd member[https://localhost:2379]
```
Copy to Clipboard Toggle word wrap
タイムアウトエラーが発生した場合は、コマンドが正常に実行されるまで --command-timeout の値を増やします。

データベースサイズが縮小されていることを確認します。

etcdctl endpoint status -w table --cluster

sh-4.4# etcdctl endpoint status -w table --cluster

Copy to Clipboard

Toggle word wrap

出力例

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        |


| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Copy to Clipboard

Toggle word wrap

この例では、この etcd メンバーのデータベースサイズは、開始時のサイズの 104 MB ではなく 41 MB です。

これらの手順を繰り返して他の etcd メンバーのそれぞれに接続し、デフラグします。常に最後にリーダーをデフラグします。
etcd Pod が回復するように、デフラグアクションごとに 1 分以上待機します。etcd Pod が回復するまで、etcd メンバーは応答しません。

領域のクォータの超過により NOSPACE アラームがトリガーされる場合、それらをクリアします。
1. NOSPACE アラームがあるかどうかを確認します。
  sh-4.4# etcdctl alarm list
  Copy to Clipboard Toggle word wrap
  出力例
  memberID:12345678912345678912 alarm:NOSPACE
  
  Copy to Clipboard Toggle word wrap
2. アラームをクリアします。
  sh-4.4# etcdctl alarm disarm
  Copy to Clipboard Toggle word wrap

6.12.7. クラスターの直前の状態への復元
リンクのコピー

保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.7.2 クラスターは、4.7.2 から取得した etcd バックアップを使用する必要があります。

前提条件

インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
コントロールプレーンホストへの SSH アクセス。
etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

重要

非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。

手順

リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作を実行するホストです。
リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。
kube-apiserver は復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。
重要
この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。
etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。
この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。
他のすべてのコントロールプレーンノードで静的 Pod を停止します。
注記
リカバリーホストで静的 Pod を停止する必要はありません。
1. リカバリーホストではないコントロールプレーンホストにアクセスします。
2. 以下を実行して、既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
  $ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp
  Copy to Clipboard Toggle word wrap
3. 以下を使用して、etcd Pod が停止していることを確認します。
  $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
  Copy to Clipboard Toggle word wrap
  このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。
4. 以下を実行して、既存の kube-apiserver ファイルを kubelet マニフェストディレクトリーから移動します。
  $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
  Copy to Clipboard Toggle word wrap
5. 以下を実行して、kube-apiserver コンテナーが停止していることを確認します。
  $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
  Copy to Clipboard Toggle word wrap
  このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。
6. 以下を使用して、既存の kube-controller-manager ファイルを kubelet マニフェストディレクトリーから移動します。
  $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
  Copy to Clipboard Toggle word wrap
7. 以下を実行して、kube-controller-manager コンテナーが停止していることを確認します。
  $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
  Copy to Clipboard Toggle word wrap
  このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。
8. 以下を使用して、既存の kube-scheduler ファイルを kubelet マニフェストディレクトリーから移動します。
  $ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
  Copy to Clipboard Toggle word wrap
9. 以下を使用して、kube-scheduler コンテナーが停止していることを確認します。
  $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
  Copy to Clipboard Toggle word wrap
  このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。
10. 次の例を使用して、etcd データディレクトリーを別の場所に移動します。
  $ sudo mv -v /var/lib/etcd/ /tmp
  Copy to Clipboard Toggle word wrap
11. /etc/kubernetes/manifests/keepalived.yaml ファイルが存在し、ノードが削除された場合は、次の手順に従います。
  1. /etc/kubernetes/manifests/keepalived.yaml ファイルを kubelet マニフェストディレクトリーから移動します。
    
    $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
    
    Copy to Clipboard Toggle word wrap
  2. keepalived デーモンによって管理されているコンテナーが停止していることを確認します。
    
    $ sudo crictl ps --name keepalived
    
    Copy to Clipboard Toggle word wrap
    
    コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
  3. コントロールプレーンに仮想 IP (VIP) が割り当てられているかどうかを確認します。
    
    $ ip -o address | egrep '<api_vip>|<ingress_vip>'
    
    Copy to Clipboard Toggle word wrap
  4. 報告された仮想 IP ごとに、次のコマンドを実行して仮想 IP を削除します。
    
    $ sudo ip address del <reported_vip> dev <reported_vip_device>
    
    Copy to Clipboard Toggle word wrap
12. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
リカバリーコントロールプレーンホストにアクセスします。
keepalived デーモンが使用されている場合は、リカバリーコントロールプレーンノードが仮想 IP を所有していることを確認します。
```
ip -o address | grep <api_vip>
```
```
$ ip -o address | grep <api_vip>
```
Copy to Clipboard Toggle word wrap
仮想 IP のアドレスが存在する場合、出力内で強調表示されます。仮想 IP が設定されていないか、正しく設定されていない場合、このコマンドは空の文字列を返します。
クラスター全体のプロキシーが有効になっている場合は、NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。
ヒント
oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

リカバリーコントロールプレーンホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。

sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup

$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup

Copy to Clipboard

Toggle word wrap

スクリプトの出力例

...stopping kube-scheduler-pod.yaml
...stopping kube-controller-manager-pod.yaml
...stopping etcd-pod.yaml
...stopping kube-apiserver-pod.yaml
Waiting for container etcd to stop
.complete
Waiting for container etcdctl to stop
.............................complete
Waiting for container etcd-metrics to stop
complete
Waiting for container kube-controller-manager to stop
complete
Waiting for container kube-apiserver to stop
..........................................................................................complete
Waiting for container kube-scheduler to stop
complete
Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
starting restore-etcd static pod
starting kube-apiserver-pod.yaml
static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
starting kube-controller-manager-pod.yaml
static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
starting kube-scheduler-pod.yaml
static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

...stopping kube-scheduler-pod.yaml
...stopping kube-controller-manager-pod.yaml
...stopping etcd-pod.yaml
...stopping kube-apiserver-pod.yaml
Waiting for container etcd to stop
.complete
Waiting for container etcdctl to stop
.............................complete
Waiting for container etcd-metrics to stop
complete
Waiting for container kube-controller-manager to stop
complete
Waiting for container kube-apiserver to stop
..........................................................................................complete
Waiting for container kube-scheduler to stop
complete
Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
starting restore-etcd static pod
starting kube-apiserver-pod.yaml
static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
starting kube-controller-manager-pod.yaml
static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
starting kube-scheduler-pod.yaml
static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

Copy to Clipboard

Toggle word wrap

cluster-restore.sh スクリプトは、etcd、kube-apiserver、kube-controller-manager、および kube-scheduler Pod が停止され、復元プロセスの最後に開始されたことを示す必要があります。

注記

最後の etcd バックアップの後にノード証明書が更新された場合、復元プロセスによってノードが NotReady 状態になる可能性があります。

ノードをチェックして、Ready 状態であることを確認します。

以下のコマンドを実行します。

oc get nodes -w

$ oc get nodes -w

Copy to Clipboard

Toggle word wrap

出力例

NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.27.3
host-172-25-75-38   Ready   infra,worker   3d20h   v1.27.3
host-172-25-75-40   Ready   master         3d20h   v1.27.3
host-172-25-75-65   Ready   master         3d20h   v1.27.3
host-172-25-75-74   Ready   infra,worker   3d20h   v1.27.3
host-172-25-75-79   Ready   worker         3d20h   v1.27.3
host-172-25-75-86   Ready   worker         3d20h   v1.27.3
host-172-25-75-98   Ready   infra,worker   3d20h   v1.27.3

NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.27.3
host-172-25-75-38   Ready   infra,worker   3d20h   v1.27.3
host-172-25-75-40   Ready   master         3d20h   v1.27.3
host-172-25-75-65   Ready   master         3d20h   v1.27.3
host-172-25-75-74   Ready   infra,worker   3d20h   v1.27.3
host-172-25-75-79   Ready   worker         3d20h   v1.27.3
host-172-25-75-86   Ready   worker         3d20h   v1.27.3
host-172-25-75-98   Ready   infra,worker   3d20h   v1.27.3

Copy to Clipboard

Toggle word wrap

すべてのノードが状態を報告するのに数分かかる場合があります。

NotReady 状態のノードがある場合は、ノードにログインし、各ノードの /var/lib/kubelet/pki ディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。
```
 ssh -i <ssh-key-path> core@<master-hostname>
```
```
$  ssh -i <ssh-key-path> core@<master-hostname>
```
Copy to Clipboard Toggle word wrap
サンプル pki ディレクトリー
```
pwd
ls
```
```
sh-4.4# pwd
/var/lib/kubelet/pki
sh-4.4# ls
kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
kubelet-client-current.pem              kubelet-server-current.pem
```
Copy to Clipboard Toggle word wrap

すべてのコントロールプレーンホストで kubelet サービスを再起動します。
1. 復元ホストから以下を実行します。
  $ sudo systemctl restart kubelet.service
  Copy to Clipboard Toggle word wrap
2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

保留中の証明書署名要求 (CSR) を承認します。

注記

単一ノードクラスターや 3 つのスケジュール可能なコントロールプレーンノードで構成されるクラスターなど、ワーカーノードを持たないクラスターには、承認する保留中の CSR はありません。この手順にリストされているすべてのコマンドをスキップできます。

次のコマンドを実行して、現在の CSR のリストを取得します。

oc get csr

$ oc get csr

Copy to Clipboard

Toggle word wrap

出力例

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 
csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 
...

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending


csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending


csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending


csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending

...

Copy to Clipboard

Toggle word wrap

1 1 2: kubelet 提供エンドポイントのノードによって要求される、保留中の kubelet 提供 CSR。
3 4: node-bootstrapper ノードのブートストラップ認証情報を使用して要求される、保留中の kubelet クライアント CSR。

次のコマンドを実行して、CSR の詳細と CSR が有効であることを確認します。
```
oc describe csr <csr_name>
```
```
$ oc describe csr <csr_name> 
```
1
Copy to Clipboard Toggle word wrap
1
<csr_name> は、現行の CSR のリストからの CSR の名前です。
以下を実行して、有効な node-bootstrapper CSR をそれぞれ承認します。
```
oc adm certificate approve <csr_name>
```
```
$ oc adm certificate approve <csr_name>
```
Copy to Clipboard Toggle word wrap
user-provisioned installation の場合、以下を実行して各 kubelet service CSR を承認します。
```
oc adm certificate approve <csr_name>
```
```
$ oc adm certificate approve <csr_name>
```
Copy to Clipboard Toggle word wrap

単一メンバーのコントロールプレーンが正常に起動していることを確認します。

以下を使用して、リカバリーホストから etcd コンテナーが実行中であることを確認します。

sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

Copy to Clipboard

Toggle word wrap

出力例

3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

Copy to Clipboard

Toggle word wrap

以下を使用して、リカバリーホストから etcd Pod が実行されていることを確認します。

oc -n openshift-etcd get pods -l k8s-app=etcd

$ oc -n openshift-etcd get pods -l k8s-app=etcd

Copy to Clipboard

Toggle word wrap

出力例

NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

Copy to Clipboard

Toggle word wrap

ステータスが Pending の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。

OVNKubernetes ネットワークプラグインを使用している場合は、ovnkube-controlplane Pod を再起動する必要があります。
1. 以下を実行して、すべての ovnkube-controlplane Pod を削除します。
  $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを使用して、すべての ovnkube-controlplane Pod が再デプロイされたことを確認します。
  $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
  Copy to Clipboard Toggle word wrap
OVN-Kubernetes ネットワークプラグインを使用している場合は、すべてのノードで Open Virtual Network (OVN) Kubernetes Pod を 1 つずつ再起動します。次の手順を使用して、各ノードで OVN-Kubernetes Pod を再起動します。
重要
次の順序で OVN-Kubernetes Pod を再起動します。
1. リカバリーコントロールプレーンホスト
2. 他のコントロールプレーンホスト (利用可能な場合)
3. 他のノード
注記
検証および変更用の受付 Webhook は Pod を拒否することができます。failurePolicy を Fail に設定して追加の Webhook を追加すると、Pod が拒否され、復元プロセスが失敗する可能性があります。これは、クラスターの状態の復元中に Webhook を保存および削除することで回避できます。クラスターの状態が正常に復元された後に、Webhook を再度有効にできます。
または、クラスターの状態の復元中に failurePolicy を一時的に Ignore に設定できます。クラスターの状態が正常に復元された後に、failurePolicy を Fail にすることができます。

ノースバウンドデータベース (nbdb) とサウスバウンドデータベース (sbdb) を削除します。Secure Shell (SSH)を使用してリカバリーホストと残りのノードにアクセスし、次のコマンドを実行します。

sudo rm -f /var/lib/ovn-ic/etc/*.db

$ sudo rm -f /var/lib/ovn-ic/etc/*.db

Copy to Clipboard

Toggle word wrap

OpenVSwitch サービスを再起動します。Secure Shell (SSH) を使用してノードにアクセスし、次のコマンドを実行します。
```
sudo systemctl restart ovs-vswitchd ovsdb-server
```
```
$ sudo systemctl restart ovs-vswitchd ovsdb-server
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、ノード上の ovnkube-node Pod を削除します。<node> は、再起動するノードの名前に置き換えます。
```
oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
```
```
$ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、OVN Pod のステータスを確認します。
```
oc get po -n openshift-ovn-kubernetes
```
```
$ oc get po -n openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap
1. OVN Pod のステータスが Terminating である場合は、次のコマンドを実行して、OVN Pod を実行しているノードを削除します。&lt ;node& gt; を、削除するノードの名前に置き換えます。
  $ oc delete node <node>
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、SSH を使用して Terminating ステータスの OVN Pod ノードにログインします。
  $ ssh -i <ssh-key-path> core@<node>
  Copy to Clipboard Toggle word wrap
3. 次のコマンドを実行して、すべての PEM ファイルを /var/lib/kubelet/pki ディレクトリーから移動します。
  $ sudo mv /var/lib/kubelet/pki/* /tmp
  Copy to Clipboard Toggle word wrap
4. 次のコマンドを実行して、kubelet サービスを再起動します。
  $ sudo systemctl restart kubelet.service
  Copy to Clipboard Toggle word wrap
5. 次のコマンドを実行して、リカバリー etcd マシンに戻ります。
  $ oc get csr
  Copy to Clipboard Toggle word wrap
  出力例
  NAME AGE SIGNERNAME REQUESTOR CONDITION csr-<uuid> 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending
  
  Copy to Clipboard Toggle word wrap
6. 以下のコマンドを実行して、すべての新規 CSR を承認します。ここで、csr-<uuid > は CSR の名前に置き換えてください。
  oc adm certificate approve csr-<uuid>
  Copy to Clipboard Toggle word wrap
7. 次のコマンドを実行して、ノードが復旧していることを確認します。
  $ oc get nodes
  Copy to Clipboard Toggle word wrap
以下を使用して、ovnkube-node Pod が再度実行されていることを確認します。
```
oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
```
```
$ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
```
Copy to Clipboard Toggle word wrap
注記
Pod が再起動するまでに数分かかる場合があります。
1. 他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。
  - ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。
    警告
    リカバリーホストのマシンを削除し、再作成しないでください。
  - installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。
    警告
    リカバリーホストのマシンを削除し、再作成しないでください。
    installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

失われたコントロールプレーンホストのいずれかのマシンを取得します。

クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

oc get machines -n openshift-machine-api -o wide

$ oc get machines -n openshift-machine-api -o wide

Copy to Clipboard

Toggle word wrap

出力例:

NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped


clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

Copy to Clipboard

Toggle word wrap

1: これは、失われたコントロールプレーンホストのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

以下を実行して、失われたコントロールプレーンホストのマシンを削除します。
```
oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
```
```
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
```
1
Copy to Clipboard Toggle word wrap
1
失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。
失われたコントロールプレーンホストのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

以下を実行して、新しいマシンが作成されたことを確認します。

oc get machines -n openshift-machine-api -o wide

$ oc get machines -n openshift-machine-api -o wide

Copy to Clipboard

Toggle word wrap

出力例:

NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running


clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

Copy to Clipboard

Toggle word wrap

1: 新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator は、マシンまたはノードが正常な状態に戻ると自動的に同期します。

リカバリーホストではない喪失したコントロールプレーンホストで、これらのステップを繰り返します。
1. 次のように入力して、クォーラムガードをオフにします。
  $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
  Copy to Clipboard Toggle word wrap
  このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
2. リカバリーホスト内の別のターミナルウィンドウで、以下を実行してリカバリー kubeconfig ファイルをエクスポートします。
  $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
  Copy to Clipboard Toggle word wrap
3. etcd の再デプロイメントを強制的に実行します。
  リカバリー kubeconfig ファイルをエクスポートしたのと同じターミナルウィンドウで、以下を実行します。
  $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
  1
  Copy to Clipboard Toggle word wrap
  1
  forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。
  etcd クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。
4. 次のように入力して、クォーラムガードをオンに戻します。
  $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  Copy to Clipboard Toggle word wrap
5. 以下を実行すると、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。
  $ oc get etcd/cluster -oyaml
  Copy to Clipboard Toggle word wrap
6. すべてのノードが最新のリビジョンに更新されていることを確認します。
  クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下を実行します。
  $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
  Copy to Clipboard Toggle word wrap
  etcd の NodeInstallerProgressing ステータス条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。
  AllNodesAtLatestRevision 3 nodes are at revision 7
  1
  Copy to Clipboard Toggle word wrap
  1
  この例では、最新のリビジョン番号は 7 です。
  出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。
7. etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet は内部ロードバランサーを使用して API サーバーに接続されているため、kube-apiserver は他のノードに再インストールされます。
  クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下を実行します。
kube-apiserver の新規ロールアウトを強制します。
```
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 Toggle word wrap
すべてのノードが最新のリビジョンに更新されていることを確認します。
```
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 Toggle word wrap
NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
1
Copy to Clipboard Toggle word wrap
1
この例では、最新のリビジョン番号は 7 です。
出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。
次のコマンドを実行して、Kubernetes コントローラーマネージャーの新規ロールアウトを強制します。
```
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 Toggle word wrap
以下を実行して、すべてのノードが最新リビジョンに更新されていることを確認します。
```
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 Toggle word wrap
NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
1
Copy to Clipboard Toggle word wrap
1
この例では、最新のリビジョン番号は 7 です。
出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。
以下を実行して、kube-scheduler の新規ロールアウトを強制します。
```
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 Toggle word wrap
以下を使用して、すべてのノードが最新のリビジョンに更新されていることを確認します。
```
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 Toggle word wrap
NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
```
AllNodesAtLatestRevision
3 nodes are at revision 7 
```
1
Copy to Clipboard Toggle word wrap
1
この例では、最新のリビジョン番号は 7 です。
出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。
1. すべてのコントロールプレーンホストが起動しており、クラスターに参加していることを確認します。
  クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
  $ oc -n openshift-etcd get pods -l k8s-app=etcd
  Copy to Clipboard Toggle word wrap
  出力例
  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 Toggle word wrap

リカバリー手順の後にすべてのワークロードが通常の操作に戻るようにするには、すべてのコントロールプレーンノードを再起動します。

注記

前の手順が完了したら、すべてのサービスが復元された状態に戻るまで数分間待つ必要がある場合があります。たとえば、oc login を使用した認証は、OAuth サーバー Pod が再起動するまですぐに機能しない可能性があります。

即時認証に system:admin kubeconfig ファイルを使用することを検討してください。この方法は、OAuth トークンではなく SSL/TLS クライアント証明書に基づいて認証を行います。以下のコマンドを実行し、このファイルを使用して認証できます。

export KUBECONFIG=<installation_directory>/auth/kubeconfig

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行て、認証済みユーザー名を表示します。

oc whoami

$ oc whoami

Copy to Clipboard

Toggle word wrap

6.12.8. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー

OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。たとえば、Pod で実行されている Elasticsearch クラスター、または StatefulSet オブジェクトで実行されているデータベースなどである可能性があります。etcd バックアップから復元する場合には、OpenShift Container Platform のワークロードのステータスも復元されます。ただし、etcd スナップショットが古い場合には、ステータスは無効または期限切れの可能性があります。

重要

永続ボリューム (PV) の内容は etcd スナップショットには含まれません。etcd スナップショットから OpenShift Container Platform クラスターを復元する時に、重要ではないワークロードから重要なデータにアクセスしたり、その逆ができたりする場合があります。

以下は、古いステータスを生成するシナリオ例です。

MySQL データベースが PV オブジェクトでバックアップされる Pod で実行されている。etcd スナップショットから OpenShift Container Platform を復元すると、Pod の起動を繰り返し試行しても、ボリュームをストレージプロバイダーに戻したり、実行中の MySQL Pod が生成したりされるわけではありません。この Pod は、ストレージプロバイダーでボリュームを復元し、次に PV を編集して新規ボリュームを参照するように手動で復元する必要があります。
Pod P1 は、ノード X に割り当てられているボリューム A を使用している。別の Pod がノード Y にある同じボリュームを使用している場合に etcd スナップショットが作成された場合に、etcd の復元が実行されると、ボリュームがノード Y に割り当てられていることが原因で Pod P1 が正常に起動できなくなる可能性があります。OpenShift Container Platform はこの割り当てを認識せず、ボリュームが自動的に切り離されるわけではありません。これが生じる場合には、ボリュームをノード Y から手動で切り離し、ノード X に割り当ててることで Pod P1 を起動できるようにします。
クラウドプロバイダーまたはストレージプロバイダーの認証情報が etcd スナップショットの作成後に更新された。これが原因で、プロバイダーの認証情報に依存する CSI ドライバーまたは Operator が機能しなくなります。これらのドライバーまたは Operator で必要な認証情報を手動で更新する必要がある場合があります。
デバイスが etcd スナップショットの作成後に OpenShift Container Platform ノードから削除されたか、名前が変更された。ローカルストレージ Operator で、/dev/disk/by-id または /dev ディレクトリーから管理する各 PV のシンボリックリンクが作成されます。この状況では、ローカル PV が存在しないデバイスを参照してしまう可能性があります。
この問題を修正するには、管理者は以下を行う必要があります。
1. デバイスが無効な PV を手動で削除します。
2. 各ノードからシンボリックリンクを削除します。
3. LocalVolume または LocalVolumeSet オブジェクトを削除します (ストレージ 永続ストレージの設定 ローカルボリュームを使用した永続ストレージ ローカルストレージ Operator のリソースの削除 を参照)。

トップに戻る

6.12. etcd タスク

6.12.1. etcd 暗号化について
リンクのコピー

6.12.2. サポートされている暗号化の種類
リンクのコピー

6.12.3. etcd 暗号化の有効化
リンクのコピー

6.12.4. etcd 暗号化の無効化
リンクのコピー

6.12.5. etcd データのバックアップ
リンクのコピー

6.12.6. etcd データのデフラグ
リンクのコピー

6.12.6.1. 自動デフラグ
リンクのコピー

6.12.6.2. 手動デフラグ
リンクのコピー

6.12.7. クラスターの直前の状態への復元
リンクのコピー

6.12.8. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.12. etcd タスク

6.12.1. etcd 暗号化についてリンクのコピーリンクがクリップボードにコピーされました!

6.12.2. サポートされている暗号化の種類リンクのコピーリンクがクリップボードにコピーされました!

6.12.3. etcd 暗号化の有効化リンクのコピーリンクがクリップボードにコピーされました!

6.12.4. etcd 暗号化の無効化リンクのコピーリンクがクリップボードにコピーされました!

6.12.5. etcd データのバックアップリンクのコピーリンクがクリップボードにコピーされました!

6.12.6. etcd データのデフラグリンクのコピーリンクがクリップボードにコピーされました!

6.12.6.1. 自動デフラグリンクのコピーリンクがクリップボードにコピーされました!

6.12.6.2. 手動デフラグリンクのコピーリンクがクリップボードにコピーされました!

6.12.7. クラスターの直前の状態への復元リンクのコピーリンクがクリップボードにコピーされました!

6.12.8. 永続ストレージの状態復元に関する問題および回避策リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.12.1. etcd 暗号化について
リンクのコピー

6.12.2. サポートされている暗号化の種類
リンクのコピー

6.12.3. etcd 暗号化の有効化
リンクのコピー

6.12.4. etcd 暗号化の無効化
リンクのコピー

6.12.5. etcd データのバックアップ
リンクのコピー

6.12.6. etcd データのデフラグ
リンクのコピー

6.12.6.1. 自動デフラグ
リンクのコピー

6.12.6.2. 手動デフラグ
リンクのコピー

6.12.7. クラスターの直前の状態への復元
リンクのコピー

6.12.8. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー