Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.12. etcd 任务

备份 etcd、启用或禁用 etcd 加密或清除 etcd 数据。

注意

如果部署了裸机集群，您可以将集群扩展至 5 个节点作为安装后任务的一部分。如需更多信息，请参阅 etcd 的节点扩展。

4.12.1. 关于 etcd 加密
复制链接

默认情况下，OpenShift Container Platform 不加密 etcd 数据。在集群中启用对 etcd 进行加密的功能可为数据的安全性提供额外的保护层。例如，如果 etcd 备份暴露给不应该获得这个数据的人员，它会帮助保护敏感数据。

启用 etcd 加密时，以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密：

  • Secrets
  • 配置映射
  • Routes
  • OAuth 访问令牌
  • OAuth 授权令牌

当您启用 etcd 加密时，会创建加密密钥。您必须具有这些密钥才能从 etcd 备份中恢复。

注意

etcd 加密只加密值，而不加密键。资源类型、命名空间和对象名称是未加密的。

如果在备份过程中启用了 etcd 加密，static_kuberesources_<datetimestamp>.tar.gz 文件包含 etcd 快照的加密密钥。为安全起见，请将此文件与 etcd 快照分开存储。但是，需要这个文件才能从相应的 etcd 快照恢复以前的 etcd 状态。

4.12.2. 支持的加密类型
复制链接

在 OpenShift Container Platform 中，支持以下加密类型来加密 etcd 数据：

AES-CBC
使用带有 PKCS#7 padding 和 32 字节密钥的 AES-CBC 来执行加密。加密密钥每周轮转。
AES-GCM
使用带有随机 nonce 和 32 字节密钥的 AES-GCM 来执行加密。加密密钥每周轮转。

4.12.3. 启用 etcd 加密
复制链接

您可以启用 etcd 加密来加密集群中的敏感资源。

警告

在初始加密过程完成前，不要备份 etcd 资源。如果加密过程还没有完成，则备份可能只被部分加密。

启用 etcd 加密后，可能会出现一些更改：

  • etcd 加密可能会影响几个资源的内存消耗。
  • 您可能会注意到对备份性能具有临时影响，因为领导必须提供备份服务。
  • 磁盘 I/O 可能会影响接收备份状态的节点。

您可以在 AES-GCM 或 AES-CBC 加密中加密 etcd 数据库。

注意

要将 etcd 数据库从一个加密类型迁移到另一个加密类型，您可以修改 API 服务器的 spec.encryption.type 字段。将 etcd 数据迁移到新的加密类型会自动进行。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象： 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. 将 spec.encryption.type 字段设置为 aesgcm 或 aescbc ： 

    spec:
  encryption:
    type: aesgcm
    1
    Copy to Clipboard Toggle word wrap
    1
    设置为 aesgcm 用于 AES-GCM 加密，或设置为 aescbc 用于 AES-CBC 加密。

  3. 保存文件以使改变生效。

    加密过程开始。根据 etcd 数据库的大小，这个过程可能需要 20 分钟或更长时间才能完成。

  4. 验证 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，加密仍在进行中。等待几分钟后重试。

4.12.4. 禁用 etcd 加密
复制链接

您可以在集群中禁用 etcd 数据的加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象： 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. 将 encryption 字段类型设置为 identity： 

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    1
    identity 类型是默认值，意味着没有执行任何加密。

  3. 保存文件以使改变生效。

    解密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。

  4. 验证 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 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

      在成功解密后输出显示 DecryptionCompleted： 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

4.12.5. 备份 etcd 数据
复制链接

按照以下步骤，通过创建 etcd 快照并备份静态 pod 的资源来备份 etcd 数据。这个备份可以被保存，并在以后需要时使用它来恢复 etcd 数据。

重要

只保存单一 control plane 主机的备份。不要从集群中的每个 control plane 主机进行备份。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

  • 您已检查是否启用了集群范围代理。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxy、httpsProxy和 noProxy 字段设置了值，则会启用代理。

流程

  1. 以 root 用户身份为 control plane 节点启动一个 debug 会话： 

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 在 debug shell 中将根目录改为 /host ： 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  3. 如果启用了集群范围代理，请运行以下命令导出 NO_PROXY、HTTP_PROXY 和 HTTPS_PROXY 环境变量： 

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  4. 在 debug shell 中运行 cluster-backup.sh 脚本，并传递保存备份的位置。

    提示

    cluster-backup.sh 脚本作为 etcd Cluster Operator 的一个组件被维护，它是 etcdctl snapshot save 命令的包装程序（wrapper）。 

    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
    Copy to Clipboard Toggle word wrap

    在这个示例中，在 control plane 主机上的 /home/core/assets/backup/ 目录中创建了两个文件：

    • snapshot_<datetimestamp>.db：这个文件是 etcd 快照。cluster-backup.sh 脚本确认其有效。

    • static_kuberesources_<datetimestamp>.tar.gz：此文件包含静态 pod 的资源。如果启用了 etcd 加密，它也包含 etcd 快照的加密密钥。

      注意

      如果启用了 etcd 加密，建议出于安全考虑，将第二个文件与 etcd 快照分开保存。但是，需要这个文件才能从 etcd 快照中进行恢复。

      请记住，etcd 仅对值进行加密，而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

4.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 数据进行清理以回收磁盘空间。

历史压缩将自动每五分钟执行一次，并在后端数据库中造成混乱。此碎片空间可供 etcd 使用，但主机文件系统不可用。您必须对碎片 etcd 进行碎片清除，才能使这个空间可供主机文件系统使用。

碎片清理会自动发生，但您也可以手动触发它。

注意

自动清理碎片非常适合大多数情况，因为 etcd operator 使用集群信息来确定用户最有效的操作。

4.12.6.1. 自动清理
复制链接

etcd Operator 自动清理碎片磁盘。不需要人工干预。

查看以下日志之一来验证碎片整理过程是否成功：

  • etcd 日志
  • cluster-etcd-operator pod
  • Operator 状态错误日志
警告

自动清除可能会导致各种 OpenShift 核心组件中的领导选举失败，如 Kubernetes 控制器管理器，这会触发重启失败的组件。重启会有危害，并会触发对下一个正在运行的实例的故障切换，或者组件在重启后再次恢复工作。

成功进行碎片处理的日志输出示例

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>
Copy to Clipboard Toggle word wrap

4.12.6.2. 手动清理
复制链接

Prometheus 警报指示您需要手动进行碎片处理。该警报在两个情况下显示：

  • 当 etcd 使用超过 50% 的可用空间超过了 10 分钟
  • 当 etcd 活跃使用小于其数据库总大小的 50% 超过了 10 分钟

您还可以通过检查 etcd 数据库大小（MB）来决定是否需要进行碎片整理。通过 PromQL 表达 (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024 来释放空间。

警告

分离 etcd 是一个阻止性操作。在进行碎片处理完成前，etcd 成员将没有响应。因此，在每个下一个 pod 要进行碎片清理前，至少等待一分钟，以便集群可以恢复正常工作。

按照以下步骤对每个 etcd 成员上的 etcd 数据进行碎片处理。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 确定哪个 etcd 成员是领导成员，因为领导会进行最后的碎片处理。

    1. 获取 etcd pod 列表： 

      $ 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>
      Copy to Clipboard Toggle word wrap

    2. 选择 pod 并运行以下命令来确定哪个 etcd 成员是领导： 

      $ 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 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      基于此输出的 IS LEADER 列，https://10.0.199.170:2379 端点是领导。与上一步输出匹配此端点，领导的 pod 名称为 etcd-ip-10-0-199-170.example.redhat.com。

  2. 清理 etcd 成员。

    1. 连接到正在运行的 etcd 容器，传递 不是 领导的 pod 的名称： 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
      Copy to Clipboard Toggle word wrap

    2. 取消设置 ETCDCTL_ENDPOINTS 环境变量： 

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

    3. 清理 etcd 成员： 

      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]
      Copy to Clipboard Toggle word wrap

      如果发生超时错误，增加 --command-timeout 的值，直到命令成功为止。

    4. 验证数据库大小是否已缩小： 

      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 |        |
      1 
      
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      本例显示这个 etcd 成员的数据库大小现在为 41 MB，而起始大小为 104 MB。

    5. 重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。

      至少要在碎片处理操作之间等待一分钟，以便 etcd pod 可以恢复。在 etcd pod 恢复前，etcd 成员不会响应。

  3. 如果因为超过空间配额而触发任何 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

4.12.7. 为多个节点恢复到一个以前的集群状态
复制链接

您可以使用保存的 etcd 备份来恢复以前的集群状态，或恢复丢失了大多数 control plane 主机的集群。

对于高可用性 (HA) 集群，三节点集群需要在两个主机上关闭 etcd，以避免出现集群分割的情况。在四节点和五个节点 HA 集群中，您必须关闭三个主机。仲裁只需要具有多数节点的情况。三节点 HA 集群中，仲裁最少需要两个节点。在四节点和五个节点 HA 集群中，仲裁需要的最小节点数为三。如果您从恢复主机上的备份启动新集群，其他 etcd 成员可能仍然可以组成仲裁并继续服务。

注意

如果您的集群使用 control plane 机器集，请参阅"为 etcd 恢复 control plane 机器集"中的"恢复降级的 etcd Operator"。对于单一节点上的 OpenShift Container Platform，请参阅"为单一节点提供以前的集群状态"。

重要

恢复集群时，必须使用同一 z-stream 发行版本中获取的 etcd 备份。例如，OpenShift Container Platform 4.19.2 集群必须使用在 4.19.2 中进行的 etcd 备份。

先决条件

  • 通过一个基于证书的 kubeconfig 使用具有 cluster-admin 角色的用户访问集群，如安装期间的情况。
  • 用作恢复主机的健康 control plane 主机。
  • 有到 control plane 主机的 SSH 访问权限。
  • 包含从同一备份中获取的 etcd 快照和静态 pod 资源的备份目录。该目录中的文件名必须采用以下格式: snapshot_<datetimestamp>.db 和 static_kuberesources_<datetimestamp>.tar.gz。
  • 节点必须能够访问或可引导。
重要

对于非恢复 control plane 节点，不需要建立 SSH 连接或停止静态 pod。您可以逐个删除并重新创建其他非恢复 control plane 机器。

流程

  1. 选择一个要用作恢复主机的 control plane 主机。这是在其中运行恢复操作的主机。

  2. 建立到每个 control plane 节点（包括恢复主机）的 SSH 连接。

    恢复过程启动后，kube-apiserver 将无法访问，因此您无法访问 control plane 节点。因此，建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。

    重要

    如果没有完成这个步骤，将无法访问 control plane 主机来完成恢复过程，您将无法从这个状态恢复集群。

  3. 使用 SSH 连接到每个 control plane 节点，并运行以下命令来禁用 etcd： 

    $ sudo -E /usr/local/bin/disable-etcd.sh
    Copy to Clipboard Toggle word wrap

  4. 将 etcd 备份目录复制复制到恢复 control plane 主机上。

    此流程假设您将 backup 目录（其中包含 etcd 快照和静态 pod 资源）复制到恢复 control plane 主机的 /home/core/ 目录中。

  5. 运行以下命令，使用 SSH 连接到恢复主机并从以前的备份中恢复集群： 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
    Copy to Clipboard Toggle word wrap
  6. 退出 SSH 会话。

  7. API 响应后，通过运行nning 来关闭 etcd Operator 仲裁保护： 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

  8. 运行以下命令监控 control plane 的恢复进度： 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    注意

    control plane 最多可能需要 15 分钟才能恢复。

  9. 恢复后，运行以下命令来启用仲裁保护： 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

故障排除

如果推出 etcd 静态 pod 的过程没有进展，您可以通过运行以下命令来强制从 cluster-etcd-operator 重新部署： 

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Toggle word wrap

4.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 不会使卷恢复到存储供应商上，且不会生成正在运行的 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 引用不再存在的设备。

    要解决这个问题，管理员必须：

    1. 手动删除带有无效设备的 PV。
    2. 从对应节点中删除符号链接。
    3. 删除 LocalVolume 或 LocalVolumeSet 对象（请参阅 Storage Configuring persistent storage Persistent storage Persistent storage Deleting the Local Storage Operator Resources）。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat