5.3. 灾难恢复
5.3.1. 关于灾难恢复
灾难恢复文档为管理员提供了如何从 OpenShift Container Platform 集群可能出现的几个灾难情形中恢复的信息。作为管理员，您可能需要遵循以下一个或多个步骤将集群恢复为工作状态。
灾难恢复要求您至少有一个健康的 control plane 主机（也称为 master 主机）。
- 恢复到一个以前的集群状态
如果您希望将集群恢复到一个以前的状态时（例如，管理员错误地删除了一些关键信息），则可以使用这个解决方案。这包括您丢失了大多数 control plane 主机并导致 etcd 仲裁丢失，且集群离线的情况。只要您执行了 etcd 备份，就可以按照这个步骤将集群恢复到之前的状态。
如果适用，可能还需要从过期的 control plane 证书中恢复。
警告在一个正在运行的集群中恢复到以前的集群状态是破坏性的，而不稳定的操作。这仅应作为最后的手段使用。
在执行恢复前，请参阅关于恢复集群状态以了解有关对集群的影响的更多信息。
注意如果大多数 master 仍可用，且仍有 etcd 仲裁，请按照以下步骤替换一个不健康的 etcd 成员。
- 从 control plane 证书已过期的情况下恢复
- 如果 control plane 证书已经过期，则可以使用这个解决方案。例如：在第一次证书轮转前（在安装后 24 小时内）关闭了集群，您的证书将不会被轮转，且会过期。可以按照以下步骤从已过期的 control plane 证书中恢复。
5.3.2. 恢复到一个以前的集群状态
为了将集群还原到以前的状态，您必须已通过创建快照备份了 etcd 数据 。您将需要使用此快照来还原集群状态。
5.3.2.1. 关于恢复集群状态
您可以使用 etcd 备份将集群恢复到以前的状态。在以下情况中可以使用这个方法进行恢复：
- 集群丢失了大多数 control plane 主机（仲裁丢失）。
- 管理员删除了一些关键内容，必须恢复才能恢复集群。
在一个正在运行的集群中恢复到以前的集群状态是破坏性的，而不稳定的操作。这仅应作为最后的手段使用。
如果您可以使用 Kubernetes API 服务器检索数据，则代表 etcd 可用，且您不应该使用 etcd 备份来恢复。
恢复 etcd 实际相当于把集群返回到以前的一个状态，所有客户端都会遇到一个有冲突的、并行历史记录。这会影响 kubelet、Kubernetes 控制器、SDN 控制器和持久性卷控制器等监视组件的行为。
当 etcd 中的内容与磁盘上的实际内容不匹配时，可能会导致 Operator churn，从而导致 Kubernetes API 服务器、Kubernetes 控制器管理器、Kubernetes 调度程序和 etcd 的 Operator 在磁盘上的文件与 etcd 中的内容冲突时卡住。这可能需要手动操作来解决问题。
在极端情况下，集群可能会丢失持久性卷跟踪，删除已不存在的关键工作负载，重新镜像机器，以及重写带有过期证书的 CA 捆绑包。
5.3.2.2. 恢复到一个以前的集群状态
您可以使用已保存的 etcd 备份来恢复以前的集群状态，或者恢复丢失了大多数 control plane 主机（也称为 master 主机）的集群。
恢复集群时，必须使用同一 z-stream 发行版本中获取的 etcd 备份。例如，OpenShift Container Platform 4.7.2 集群必须使用从 4.7.2 开始的 etcd 备份。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 - 用作恢复主机的健康 control plane 主机。
- SSH 对 control plane 主机的访问。
-
包含从同一备份中获取的 etcd 快照和静态 pod 资源的备份目录。该目录中的文件名必须采用以下格式:
snapshot_<datetimestamp>.db和static_kuberesources_<datetimestamp>.tar.gz。
对于非恢复 control plane 节点，不需要建立 SSH 连接或停止静态 pod。您可以逐个删除并重新创建其他非恢复 control plane 机器。
流程
- 选择一个要用作恢复主机的 control plane 主机。这是您要在其中运行恢复操作的主机。
建立到每个 control plane 节点（包括恢复主机）的 SSH 连接。
恢复过程启动后，Kubernetes API 服务器将无法访问，因此您无法访问 control plane 节点。因此，建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。
重要如果没有完成这个步骤，将无法访问 control plane 主机来完成恢复过程，您将无法从这个状态恢复集群。
将 etcd 备份目录复制复制到恢复 control plane 主机上。
此流程假设您将
backup目录（其中包含 etcd 快照和静态 pod 资源）复制到恢复 control plane 主机的/home/core/目录中。在任何其他 control plane 节点上停止静态 pod。
注意不需要手动停止恢复主机上的 pod。恢复脚本将停止恢复主机上的 pod。
- 访问不是恢复主机的 control plane 主机。
将现有 etcd pod 文件从 Kubelet 清单目录中移出：
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
验证 etcd pod 是否已停止。
$ sudo crictl ps | grep etcd | grep -v operator
命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。
将现有 Kubernetes API 服务器 pod 文件移出 kubelet 清单目录中：
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
验证 Kubernetes API 服务器 pod 是否已停止。
$ sudo crictl ps | grep kube-apiserver | grep -v operator
命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。
将 etcd 数据目录移到不同的位置：
$ sudo mv /var/lib/etcd/ /tmp
- 在其他不是恢复主机的 control plane 主机上重复此步骤。
- 访问恢复 control plane 主机。
如果启用了集群范围的代理，请确定已导出了
NO_PROXY、HTTP_PROXY和HTTPS_PROXY环境变量。提示您可以通过查看
oc get proxy cluster -o yaml的输出来检查代理是否已启用。如果httpProxy、httpsProxy和noProxy字段设置了值，则会启用代理。在恢复 control plane 主机上运行恢复脚本，提供到 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
注意如果在上次 etcd 备份后更新了节点，则恢复过程可能会导致节点进入
NotReady状态。检查节点以确保它们处于
Ready状态。运行以下命令:
$ oc get nodes -w
输出示例
NAME STATUS ROLES AGE VERSION host-172-25-75-28 Ready master 3d20h v1.23.3+e419edf host-172-25-75-38 Ready infra,worker 3d20h v1.23.3+e419edf host-172-25-75-40 Ready master 3d20h v1.23.3+e419edf host-172-25-75-65 Ready master 3d20h v1.23.3+e419edf host-172-25-75-74 Ready infra,worker 3d20h v1.23.3+e419edf host-172-25-75-79 Ready worker 3d20h v1.23.3+e419edf host-172-25-75-86 Ready worker 3d20h v1.23.3+e419edf host-172-25-75-98 Ready infra,worker 3d20h v1.23.3+e419edf
所有节点都可能需要几分钟时间报告其状态。
如果有任何节点处于
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
在所有 control plane 主机上重启 kubelet 服务。
在恢复主机中运行以下命令：
$ sudo systemctl restart kubelet.service
- 在所有其他 control plane 主机上重复此步骤。
批准待处理的 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 ...
查看一个 CSR 的详细信息以验证其是否有效：
$ oc describe csr <csr_name> 1- 1
<csr_name>是当前 CSR 列表中 CSR 的名称。
批准每个有效的
node-bootstrapperCSR：$ oc adm certificate approve <csr_name>
对于用户置备的安装，请批准每个有效的 kubelet 服务 CSR：
$ oc adm certificate approve <csr_name>
确认单个成员 control plane 已被成功启动。
从恢复主机上，验证 etcd 容器是否正在运行。
$ sudo crictl ps | grep etcd | grep -v operator
输出示例
3ad41b7908e32 36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009 About a minute ago Running etcd 0 7c05f8af362f0
从恢复主机上，验证 etcd pod 是否正在运行。
$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
注意如果您试图在运行这个命令前运行
oc login并接收以下错误，请等待一些时间以便身份验证控制器启动并再次尝试。Unable to connect to the server: EOF
输出示例
NAME READY STATUS RESTARTS AGE etcd-ip-10-0-143-125.ec2.internal 1/1 Running 1 2m47s
如果状态是
Pending，或者输出中列出了多个正在运行的 etcd pod，请等待几分钟，然后再次检查。- 对不是恢复主机的每个已丢失的 control plane 主机重复此步骤。
逐个删除并重新创建其他非恢复 control plane 机器。重新创建此机器后，会强制一个新修订版本并自动扩展 etcd。
如果您正在运行安装程序置备的基础架构，或者您使用 Machine API 创建机器，请按照以下步骤执行。否则，您必须使用最初创建控制平面节点时使用的相同方法创建新的控制平面。
警告不要为恢复主机删除和重新创建计算机。
为丢失的 control plane 主机之一获取机器。
在一个终端中使用 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
- 这是用于丢失的 control plane 主机
ip-10-0-131-183.ec2.internal的 control plane 机器。
将机器配置保存到文件系统中的一个文件中：
$ oc get machine clustername-8qw5l-master-0 \ 1 -n openshift-machine-api \ -o yaml \ > new-master-machine.yaml- 1
- 为丢失的 control plane 主机指定 control plane 机器的名称。
编辑上一步中创建的
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
删除丢失的 control plane 主机的机器：
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1- 1
- 为丢失的 control plane 主机指定 control plane 机器的名称。
验证机器是否已删除：
$ 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 cluster Operator 将自动同步。
- 对不是恢复主机的每个已丢失的 control plane 主机重复此步骤。
在一个单独的终端窗口中，使用以下命令以具有
cluster-admin角色的用户身份登录到集群：$ oc login -u <cluster_admin> 1- 1
- 对于
<cluster_admin>，使用cluster-admin角色指定一个用户名。
强制 etcd 重新部署。
在一个终端中使用
cluster-admin用户连接到集群，运行以下命令：$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1- 1
forceRedeploymentReason值必须是唯一的，这就是为什么附加时间戳的原因。
当 etcd cluster Operator 执行重新部署时，现有节点开始使用与初始 bootstrap 扩展类似的新 pod。
验证所有节点是否已更新至最新的修订版本。
在一个终端中使用
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 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。在重新部署 etcd 后，为 control plane 强制进行新的 rollout。由于 kubelet 使用内部负载平衡器连接到 API 服务器，因此 Kubernetes API 将在其他节点上重新安装自己。
在一个终端中使用
cluster-admin用户连接到集群，运行以下命令。为 Kubernetes API 服务器强制进行新的推出部署：
$ 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 个节点为修订版本 6；1 个节点为修订版本 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 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。为 Kubernetes 调度程序强制进行新的推出部署：
$ 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 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。
验证所有 control plane 主机是否已启动并加入集群。
在一个终端中使用
cluster-admin用户连接到集群，运行以下命令：$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
输出示例
etcd-ip-10-0-143-125.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-154-194.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-173-171.ec2.internal 2/2 Running 0 9h
为确保所有工作负载在恢复过程后返回到正常操作，请重启存储 Kubernetes API 信息的每个 pod。这包括 OpenShift Container Platform 组件，如路由器、Operator 和第三方组件。
请注意，在完成这个过程后，可能需要几分钟才能恢复所有服务。例如，在重启 OAuth 服务器 pod 前，使用 oc login 进行身份验证可能无法立即正常工作。
5.3.2.3. 恢复持久性存储状态的问题和解决方法
如果您的 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 不会使卷恢复到存储供应商上，且不会生成正在运行的 MySQL pod，尽管 pod 会重复尝试启动。您必须通过在存储供应商中恢复卷，然后编辑 PV 以指向新卷来手动恢复这个 pod。
- Pod P1 使用卷 A，它附加到节点 X。如果另一个 pod 在节点 Y 上使用相同的卷，则执行 etcd 恢复时，pod P1 可能无法正确启动，因为卷仍然被附加到节点 Y。OpenShift Container Platform 并不知道附加，且不会自动分离它。发生这种情况时，卷必须从节点 Y 手动分离，以便卷可以在节点 X 上附加，然后 pod P1 才可以启动。
- 在执行 etcd 快照后，云供应商或存储供应商凭证会被更新。这会导致任何依赖于这些凭证的 CSI 驱动程序或 Operator 无法正常工作。您可能需要手动更新这些驱动程序或 Operator 所需的凭证。
在生成 etcd 快照后，会从 OpenShift Container Platform 节点中删除或重命名设备。Local Storage Operator 会为从
/dev/disk/by-id或/dev目录中管理的每个 PV 创建符号链接。这种情况可能会导致本地 PV 引用不再存在的设备。要解决这个问题，管理员必须：
- 手动删除带有无效设备的 PV。
- 从对应节点中删除符号链接。
-
删除
LocalVolume或LocalVolumeSet对象（请参阅 StorageConfiguring persistent storage Persistent storage Persistent storage Deleting the Local Storage Operator Resources）。
其他资源
- 如需有关如何创建堡垒主机来访问 OpenShift Container Platform 实例和使用 SSH 的 control plane 节点，请参阅访问主机。
5.3.3. 从 control plane 证书已过期的情况下恢复
5.3.3.1. 从 control plane 证书已过期的情况下恢复
集群可以从过期的 control plane 证书中自动恢复。
但是，您需要手动批准待处理的 node-bootstrapper 证书签名请求（CSR）来恢复 kubelet 证书。对于用户置备的安装，您可能需要批准待处理的 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 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 ...
查看一个 CSR 的详细信息以验证其是否有效：
$ oc describe csr <csr_name> 1- 1
<csr_name>是当前 CSR 列表中 CSR 的名称。
批准每个有效的
node-bootstrapperCSR：$ oc adm certificate approve <csr_name>
对于用户置备的安装，请批准每个有效的 kubelet 服务 CSR：
$ oc adm certificate approve <csr_name>
