第 5 章 使用 RWO 存储恢复应用程序

使用 RWO 存储(ReadWriteOnce)的应用程序具有在此 Kubernetes 问题中描述的已知行为。由于此问题，如果数据区出现任何挂载 RWO 卷的应用程序 pod 失败（例如： 基于 cephrbd 的卷）在 6-8 分钟后处于 Terminating 状态，且不会在没有手动干预的情况下在活动区重新创建。

检查 OpenShift Container Platform 节点，其状态为 NotReady。它可能会遇到阻止他们与 OpenShift 控制平面通信的问题。尽管存在这个通信问题，仍然可能对持久卷执行 IO 操作。

如果两个 pod 同时写入同一个 RWO 卷，则存在数据崩溃的风险。必须采取一些措施来确保 NotReady 节点上的进程被终止或阻止，直到进程被终止为止。

  • 例如，使用具有确认功能的带外管理系统关闭一个节点，是一个确保进程被中断的方法示例。

  • 另外一个方法是，撤回故障端点中被节点用于与存储进行通讯的网络路由器。

    注意

    在将服务恢复到失败的区域或节点前，必须先确认所有带有持久性卷的 pod 都已成功终止。

要让 Terminating pod 在活跃区中重新创建，您可以强制删除 pod 或删除关联的 PV 上的终结器。完成这两个操作之一后，应用程序 Pod 应在 active 区域中重新创建，并成功挂载其 RWO 存储。

强制删除 pod

强制删除不需要等待 kubelet 确认 Pod 已终止的信息。 

$ oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>
<PODNAME>
是 pod 的名称
<NAMESPACE>
是项目的命名空间
删除关联的 PV 上的终结器

找到由 Terminating pod 挂载的持久性卷声明(PVC)关联的 PV，并使用 oc patch 命令删除终结器。 

$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge
<PV_NAME>

是 PV 的名称

查找关联的 PV 的一种简单方法是描述 Terminating pod。如果您看到多附件警告，在警告中应具有 PV 名称（例如： pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c）。 

$ oc describe pod <PODNAME> --namespace <NAMESPACE>
<PODNAME>
是 pod 的名称
<NAMESPACE>

是项目的命名空间

输出示例： 

[...]
Events:
  Type     Reason                  Age   From                     Message
  ----     ------                  ----  ----                     -------
  Normal   Scheduled               4m5s  default-scheduler        Successfully assigned openshift-storage/noobaa-db-pg-0 to perf1-mz8bt-worker-d2hdm
  Warning  FailedAttachVolume      4m5s  attachdetach-controller  Multi-Attach error for volume "pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c" Volume is already exclusively attached to one node and can't be attached to another