4.13. etcd タスク
etcd のバックアップ、etcd 暗号化の有効化または無効化、または etcd データのデフラグを行います。
ベアメタルクラスターをデプロイした場合は、インストール後のタスクの一環として、クラスターを最大 5 ノードまでスケーリングできます。詳細は、etcd によるノードのスケーリング を参照してください。
4.13.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 の以前の状態を復元するために必要です。
4.13.2. サポートされている暗号化の種類 リンクのコピーリンクがクリップボードにコピーされました!
以下の暗号化タイプは、OpenShift Container Platform で etcd データを暗号化するためにサポートされています。
- AES-CBC
- 暗号化を実行するために、PKCS#7 パディングと 32 バイトの鍵を含む AES-CBC を使用します。暗号化キーは毎週ローテーションされます。
- AES-GCM
- AES-GCM とランダムナンスおよび 32 バイトキーを使用して暗号化を実行します。暗号化キーは毎週ローテーションされます。
4.13.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 Copied! Toggle word wrap Toggle overflow spec.encryption.type
フィールドをaesgcm
またはaescbc
に設定します。spec: encryption: type: aesgcm
spec: encryption: type: aesgcm
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- AES-CBC 暗号化の場合は
aescbc
に、AES-GCM 暗号化の場合はaesgcm
に設定します。
変更を適用するためにファイルを保存します。
暗号化プロセスが開始されます。etcd データベースのサイズによっては、このプロセスが完了するまでに 20 分以上かかる場合があります。
etcd 暗号化が正常に行われたことを確認します。
OpenShift API サーバーの
Encrypted
ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、暗号化が正常に実行されると
EncryptionCompleted
が表示されます。EncryptionCompleted All resources encrypted: routes.route.openshift.io
EncryptionCompleted All resources encrypted: routes.route.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
EncryptionInProgress
が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。Kubernetes API サーバーの
Encrypted
ステータス状態を確認し、そのリソースが正常に暗号化されたことを確認します。oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、暗号化が正常に実行されると
EncryptionCompleted
が表示されます。EncryptionCompleted All resources encrypted: secrets, configmaps
EncryptionCompleted All resources encrypted: secrets, configmaps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
EncryptionInProgress
が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。OpenShift OAuth API サーバーの
Encrypted
ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、暗号化が正常に実行されると
EncryptionCompleted
が表示されます。EncryptionCompleted All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
EncryptionCompleted All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
EncryptionInProgress
が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。
4.13.4. etcd 暗号化の無効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで etcd データの暗号化を無効にできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
APIServer
オブジェクトを変更します。oc edit apiserver
$ oc edit apiserver
Copy to Clipboard Copied! Toggle word wrap Toggle overflow encryption
フィールドタイプをidentity
に設定します。spec: encryption: type: identity
spec: encryption: type: identity
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
identity
タイプはデフォルト値であり、暗号化は実行されないことを意味します。
変更を適用するためにファイルを保存します。
復号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。
etcd の復号化が正常に行われたことを確認します。
OpenShift API サーバーの
Encrypted
ステータス条件を確認し、そのリソースが正常に暗号化されたことを確認します。oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、復号化が正常に実行されると
DecryptionCompleted
が表示されます。DecryptionCompleted Encryption mode set to identity and everything is decrypted
DecryptionCompleted Encryption mode set to identity and everything is decrypted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
DecryptionInProgress
が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。Kubernetes API サーバーの
Encrypted
ステータス状態を確認し、そのリソースが正常に復号化されたことを確認します。oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、復号化が正常に実行されると
DecryptionCompleted
が表示されます。DecryptionCompleted Encryption mode set to identity and everything is decrypted
DecryptionCompleted Encryption mode set to identity and everything is decrypted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
DecryptionInProgress
が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。OpenShift API サーバーの
Encrypted
ステータス条件を確認し、そのリソースが正常に復号化されたことを確認します。oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、復号化が正常に実行されると
DecryptionCompleted
が表示されます。DecryptionCompleted Encryption mode set to identity and everything is decrypted
DecryptionCompleted Encryption mode set to identity and everything is decrypted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に
DecryptionInProgress
が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。
4.13.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 Copied! Toggle word wrap Toggle overflow デバッグシェルで root ディレクトリーを
/host
に変更します。chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、
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 Copied! Toggle word wrap Toggle overflow export HTTPS_PROXY=https://<your_proxy.example.com>:8080
$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export NO_PROXY=<example.com>
$ export NO_PROXY=<example.com>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デバッグシェルで
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 Copied! Toggle word wrap Toggle overflow スクリプトの出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、コントロールプレーンホストの
/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、およびオブジェクト名は暗号化されません。
-
4.13.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 はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。
4.13.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>
最適化に失敗した場合のログ出力の例
failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
4.13.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 Copied! Toggle word wrap Toggle overflow 出力例
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 Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力の
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 Copied! Toggle word wrap Toggle overflow ETCDCTL_ENDPOINTS
環境変数の設定を解除します。unset ETCDCTL_ENDPOINTS
sh-4.4# unset ETCDCTL_ENDPOINTS
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow 出力例
Finished defragmenting etcd member[https://localhost:2379]
Finished defragmenting etcd member[https://localhost:2379]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow タイムアウトエラーが発生した場合は、コマンドが正常に実行されるまで
--command-timeout
の値を増やします。データベースサイズが縮小されていることを確認します。
etcdctl endpoint status -w table --cluster
sh-4.4# etcdctl endpoint status -w table --cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、この etcd メンバーのデータベースサイズは、開始時のサイズの 104 MB ではなく 41 MB です。
これらの手順を繰り返して他の etcd メンバーのそれぞれに接続し、デフラグします。常に最後にリーダーをデフラグします。
etcd Pod が回復するように、デフラグアクションごとに 1 分以上待機します。etcd Pod が回復するまで、etcd メンバーは応答しません。
領域のクォータの超過により
NOSPACE
アラームがトリガーされる場合、それらをクリアします。NOSPACE
アラームがあるかどうかを確認します。etcdctl alarm list
sh-4.4# etcdctl alarm list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
memberID:12345678912345678912 alarm:NOSPACE
memberID:12345678912345678912 alarm:NOSPACE
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アラームをクリアします。
etcdctl alarm disarm
sh-4.4# etcdctl alarm disarm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.13.7. 以前のクラスター状態への復元 リンクのコピーリンクがクリップボードにコピーされました!
保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。
高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。
クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。シングルノード上の OpenShift Container Platform については、「シングルノードで以前のクラスター状態に復元する」を参照してください。
クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.18.2 クラスターでは、4.18.2 から取得した etcd バックアップを使用する必要があります。
前提条件
-
インストール時に使用したものと同様、証明書ベースの
kubeconfig
ファイルを介して、cluster-admin
ロールを持つユーザーとしてクラスターにアクセスします。 - リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
- コントロールプレーンホストへの SSH アクセス権がある。
-
etcd
スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db
およびstatic_kuberesources_<datetimestamp>.tar.gz
の形式にする必要があります。
非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。
手順
- リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作の実行対象とするホストです。
リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。
kube-apiserver
は復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。重要この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。
SSH を使用して各コントロールプレーンノードに接続し、次のコマンドを実行して etcd を無効にします。
sudo -E /usr/local/bin/disable-etcd.sh
$ sudo -E /usr/local/bin/disable-etcd.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。
この手順では、etcd スナップショットおよび静的 Pod のリソースを含む
backup
ディレクトリーを、リカバリーコントロールプレーンホストの/home/core/
ディレクトリーにコピーしていることを前提としています。SSH を使用してリカバリーホストに接続し、次のコマンドを実行して以前のバックアップからクラスターを復元します。
sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - SSH セッションを終了します。
API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。
oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。
oc adm wait-for-stable-cluster
$ oc adm wait-for-stable-cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記コントロールプレーンが回復するまでに最大 15 分かかります。
回復したら、次のコマンドを実行してクォーラムガードを有効にします。
oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
トラブルシューティング
etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、cluster-etcd-operator
から強制的に再デプロイを実行できます。
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
4.13.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 が存在しないデバイスを参照してしまう可能性があります。この問題を修正するには、管理者は以下を行う必要があります。
- デバイスが無効な PV を手動で削除します。
- 各ノードからシンボリックリンクを削除します。
-
LocalVolume
またはLocalVolumeSet
オブジェクトを削除します (ストレージ永続ストレージの設定 ローカルボリュームを使用した永続ストレージ ローカルストレージ Operator のリソースの削除 を参照)。