5.3. 障害復旧

5.3.1. 障害復旧について

この障害復旧ドキュメントでは、OpenShift Container Platform クラスターで発生する可能性のある複数の障害のある状態からの復旧方法についての管理者向けの情報を提供しています。管理者は、クラスターの状態を機能する状態に戻すために、以下の 1 つまたは複数の手順を実行する必要がある場合があります。

重要

障害復旧には、少なくとも 1 つの正常なコントロールプレーンホストが必要です。

クラスターの直前の状態への復元

このソリューションは、管理者が重要なものを削除した場合など、クラスターを直前の状態に復元する必要がある状態に対応します。これには、大多数のコントロールプレーンホストが失われたために etcd クォーラム (定足数) が失われ、クラスターがオフラインになる状態も含まれます。etcd バックアップを取得している限り、以下の手順に従ってクラスターを直前の状態に復元できます。

該当する場合は、コントロールプレーン証明書の期限切れの状態からのリカバリーが必要になる場合もあります。

警告

クラスターの直前の状態への復元は、実行中のクラスターで行う破壊的で、不安定なアクションです。この手順は、最後の手段としてのみ使用してください。

復元の実行前に、クラスターへの影響の詳細についてクラスターの復元を参照してください。

注記

大多数のマスターが依然として利用可能であり、etcd のクォーラムがある場合は、手順に従って単一の正常でない etcd メンバーの置き換えを実行します。

コントロールプレーン証明書の期限切れの状態からのリカバリー

このソリューションは、コントロールプレーン証明書の期限が切れた状態に対応します。たとえば、インストールの 24 時間後に行われる最初の証明書のローテーション前にクラスターをシャットダウンする場合、証明書はローテーションされず、期限切れになります。以下の手順に従って、コントロールプレーン証明書の期限切れの状態からのリカバリーを実行できます。

5.3.2. クラスターの直前の状態への復元

クラスターを直前の状態に復元するには、スナップショットを作成して、事前に etcd データのバックアップを行っている必要があります。このスナップショットを使用して、クラスターの状態を復元します。

5.3.2.1. クラスターの状態の復元について

etcd バックアップを使用して、クラスターを直前の状態に復元できます。これは、以下の状況から回復するために使用できます。

クラスターは、大多数のコントロールプレーンホストを失いました (クォーラムの喪失)。
管理者が重要なものを削除し、クラスターを復旧するために復元する必要があります。

警告

クラスターの直前の状態への復元は、実行中のクラスターで行う破壊的で、不安定なアクションです。これは、最後の手段としてのみ使用してください。

Kubernetes API サーバーを使用してデータを取得できる場合は、etcd が利用できるため、etcd バックアップを使用して復元することはできません。

etcd を効果的に復元すると、クラスターが時間内に元に戻され、すべてのクライアントは競合する並列履歴が発生します。これは、kubelet、Kubernetes コントローラーマネージャー、SDN コントローラー、永続ボリュームコントローラーなどのコンポーネントを監視する動作に影響を与える可能性があります。

etcd のコンテンツがディスク上の実際のコンテンツと一致しないと、Operator チャーンが発生し、ディスク上のファイルが etcd のコンテンツと競合すると、Kubernetes API サーバー、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーなどの Operator が停止する場合があります。この場合は、問題の解決に手動のアクションが必要になる場合があります。

極端な場合、クラスターは永続ボリュームを追跡できなくなり、存在しなくなった重要なワークロードを削除し、マシンのイメージを再作成し、期限切れの証明書を使用して CA バンドルを書き換えることができます。

5.3.2.2. クラスターの直前の状態への復元

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

注記

クラスターがコントロールプレーンマシンセットを使用している場合、より簡単な etcd リカバリー手順については、コントロールプレーンマシンセットのトラブルシューティングを参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.4.2 クラスターは、4.4.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 /etc/kubernetes/manifests/etcd-pod.yaml /tmp
```
3. 以下を使用して、etcd Pod が停止していることを確認します。
```
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
```
  このコマンドの出力が空でない場合は、数分待機してから再度確認します。
4. 以下を実行して、既存の kube-apiserver ファイルを kubelet マニフェストディレクトリーから移動します。
```
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
```
5. 以下を実行して kube-apiserver コンテナーが停止していることを確認します。
```
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
```
  このコマンドの出力が空でない場合は、数分待機してから再度確認します。
6. 以下を使用して、既存の kube-controller-manager ファイルを kubelet マニフェストディレクトリーから移動します。
```
$ sudo mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
```
7. 以下を実行して、kube-controller-manager コンテナーが停止していることを確認します。
```
$ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
```
  このコマンドの出力が空でない場合は、数分待機してから再度確認します。
8. 以下を使用して、既存の kube-scheduler ファイルを kubelet マニフェストディレクトリーから移動します。
```
$ sudo mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
```
9. 以下を使用して、kube-scheduler コンテナーが停止していることを確認します。
```
$ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
```
  このコマンドの出力が空でない場合は、数分待機してから再度確認します。
10. 以下の例を使用して、etcd データディレクトリーを別の場所に移動します。
```
$ sudo mv /var/lib/etcd/ /tmp
```
11. /etc/kubernetes/manifests/keepalived.yaml ファイルが存在する場合、以下の手順を実行します。
  1. /etc/kubernetes/manifests/keepalived.yaml ファイルを kubelet マニフェストディレクトリーから移動します。
    $ sudo mv /etc/kubernetes/manifests/keepalived.yaml /tmp
  2. keepalived デーモンで管理されるコンテナーが停止していることを確認します。
    $ sudo crictl ps --name keepalived
    コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
  3. コントロールプレーンに仮想 IP (VIP)が割り当てられているかどうかを確認します。
    $ ip -o address | egrep '<api_vip>|<ingress_vip>'
  4. 報告された各 VIP について、以下のコマンドを実行してこれを削除します。
    $ sudo ip address del <reported_vip> dev <reported_vip_device>
12. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
リカバリーコントロールプレーンホストにアクセスします。
keepalived デーモンが使用されている場合は、リカバリーコントロールプレーンノードが VIP を所有していることを確認します。
```
$ ip -o address | grep <api_vip>
```
VIP のアドレスが存在する場合は、出力で強調表示されます。VIP が設定されていない場合、または正しく設定されていない場合、このコマンドは空の文字列を返します。
クラスター全体のプロキシーが有効になっている場合は、 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/backup

スクリプトの出力例

...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

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

注記

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

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

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

$ oc get nodes -w

出力例

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

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

NotReady 状態のノードがある場合は、ノードにログインし、各ノードの /var/lib/kubelet/pki ディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。
```
$  ssh -i <ssh-key-path> core@<master-hostname>
```
サンプル pki ディレクトリー
```
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
```

すべてのコントロールプレーンホストで kubelet サービスを再起動します。
1. リカバリーホストから以下を実行します。
```
$ sudo systemctl restart kubelet.service
```
2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

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

注記

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

以下を実行して、現在の CSR のリストを取得します。

$ oc get csr

出力例

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

1 2: 保留中の kubelet サービス

CSR （ユーザーによってプロビジョニングされるインストール用）。<2> 保留中の node-bootstrapper CSR。

CSR の詳細を確認し、以下を実行してこれが有効であることを確認します。
```
$ oc describe csr <csr_name> 1
```
1
<csr_name> は、現行の CSR のリストからの CSR の名前です。
以下を実行してそれぞれの有効な node-bootstrapper CSR を承認します。
```
$ oc adm certificate approve <csr_name>
```
ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。
```
$ oc adm certificate approve <csr_name>
```
1. 単一メンバーのコントロールプレーンが正常に起動していることを確認します。

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

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

出力例

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

リカバリーホストから、etcd Pod が実行されていることを確認します。
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
出力例
```
NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
```
ステータスが Pending の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。
1. OVNKubernetes ネットワークプラグインを使用している場合は、ovnkube-controlplane Pod を再起動する必要があります。
以下を実行してすべての ovnkube-controlplane Pod を削除します。
```
$ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
```
以下を使用して、すべての ovnkube-controlplane Pod が再デプロイされたことを確認します。
```
$ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
```
1. Cluster Network Operator (CNO) が OVN-Kubernetes コントロールプレーンを再デプロイし、回復していないコントローラー IP アドレスを参照していないことを確認します。この結果を確認するには、以下のコマンドの出力を定期的に確認します。空の結果が返されるまで待ってから、次の手順ですべてのホスト上の Open Virtual Network (OVN) Kubernetes Pod の再起動に進みます。
```
$ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<non-recovery_controller_ip_1>|<non-recovery_controller_ip_2>'
```
  注記
  OVN-Kubernetes コントロールプレーンが再デプロイされ、直前のコマンドが空の出力を返すまでに 5-10 分以上かかる場合があります。
2. すべてのホストで Open Virtual Network (OVN) Kubernetes Pod を再起動します。
  注記
  検証および変更用の受付 Webhook は Pod を拒否することができます。failurePolicy を Fail に設定して追加の Webhook を追加すると、Pod が拒否され、復元プロセスが失敗する可能性があります。これは、クラスターの状態の復元中に Webhook を保存および削除することで回避できます。クラスターの状態が正常に復元された後に、Webhook を再度有効にできます。
  または、クラスターの状態の復元中に failurePolicy を一時的に Ignore に設定できます。クラスターの状態が正常に復元された後に、failurePolicy を Fail にすることができます。
ノースバウンドデータベース (nbdb) とサウスバウンドデータベース (sbdb) を削除します。Secure Shell (SSH)を使用してリカバリーホストと残りのコントロールプレーンノードにアクセスし、以下を実行します。
```
$ sudo rm -f /var/lib/ovn/etc/*.db
```
次のコマンドを実行して、すべての OVN-Kubernetes コントロールプレーン Pod を削除します。
```
$ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
```
次のコマンドを実行して、OVN-Kubernetes コントロールプレーン Pod が再度デプロイされ、Running 状態になっていることを確認します。
```
$ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
```
出力例
```
NAME                   READY   STATUS    RESTARTS   AGE
ovnkube-master-nb24h   4/4     Running   0          48s
```

以下を実行して、ovnkube-node Pod が再び実行されていることを確認します。

$ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done

次のコマンドを実行して、すべての ovnkube-node Pod が再度デプロイされ、Running 状態になっていることを確認します。
```
$ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node
```
1. 他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。
  - ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細については、ユーザーがプロビジョニングしたクラスターをベアメタルにインストールするを参照してください。
    警告
    リカバリーホストのマシンを削除し、再作成しないでください。
  - installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。
    警告
    リカバリーホストのマシンを削除し、再作成しないでください。
    installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細については、ベアメタルコントロールプレーンノードの交換を参照してください。

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

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

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

出力例:

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 1
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

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

以下を実行して、マシン設定をファイルシステムのファイルに保存します。
```
$ oc get machine clustername-8qw5l-master-0 \ 1
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
```
1
失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

次のコマンドを実行して、status セクション全体を削除します。

status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus

以下を実行して metadata.name フィールドを新規の名前に変更します。
古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、clustername-8qw5l-master-0 は clustername-8qw5l-master-3 に変更されています。
```
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
```
以下を実行して spec.providerID フィールドを削除します。
```
providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
```
以下を実行して metadata.annotations および metadata.generation フィールドを削除します。
```
annotations:
  machine.openshift.io/instance-state: running
...
generation: 2
```
以下を実行して metadata.resourceVersion および metadata.uid フィールドを削除します。
```
resourceVersion: "13291"
uid: a282eb70-40a2-4e89-8009-d05dd420d31a
```

以下を実行して、失われたコントロールプレーンホストのマシンを削除します。
```
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
```
1
失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

以下を実行して、マシンが削除されていることを確認します。

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

出力例:

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-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

以下を実行して new-master-machine.yaml ファイルを使用してマシンを作成します。
```
$ oc apply -f new-master-machine.yaml
```

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

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

出力例:

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 1
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

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

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

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

復元手順の後にすべてのワークロードが通常の動作に戻るようにするには、Kubernetes API 情報を保存している各 Pod を再起動します。これには、ルーター、Operator、サードパーティーコンポーネントなどの OpenShift Container Platform コンポーネントが含まれます。

注記

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

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

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig

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

$ oc whoami

5.3.2.3. 関連情報

5.3.2.4. 永続ストレージの状態復元に関する問題および回避策

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 のリソースの削除 を参照)。

5.3.3. コントロールプレーン証明書の期限切れの状態からのリカバリー

5.3.3.1. コントロールプレーン証明書の期限切れの状態からのリカバリー

クラスターはコントロールプレーン証明書の期限切れの状態から自動的に回復できます。

ただし、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。ユーザーによってプロビジョニングされるインストールの場合は、保留中の kubelet 提供の CSR を承認しないといけない場合があります。

保留中の CSR を承認するには、以下の手順に従います。

手順

現在の CSR の一覧を取得します。

$ oc get csr

出力例

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
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 2
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

1: 保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。
2: 保留中の node-bootstrapper CSR。

CSR の詳細をレビューし、これが有効であることを確認します。
```
$ oc describe csr <csr_name> 1
```
1
<csr_name> は、現行の CSR のリストからの CSR の名前です。
それぞれの有効な node-bootstrapper CSR を承認します。
```
$ oc adm certificate approve <csr_name>
```
ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。
```
$ oc adm certificate approve <csr_name>
```

5.3. 障害復旧

5.3.1. 障害復旧について

5.3.2. クラスターの直前の状態への復元

5.3.2.1. クラスターの状態の復元について

5.3.2.2. クラスターの直前の状態への復元

5.3.2.3. 関連情報

5.3.2.4. 永続ストレージの状態復元に関する問題および回避策

5.3.3. コントロールプレーン証明書の期限切れの状態からのリカバリー

5.3.3.1. コントロールプレーン証明書の期限切れの状態からのリカバリー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links