4.10. etcd 任务

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

4.10.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.10.2. 启用 etcd 加密

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

警告

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

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

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

先决条件

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

流程

修改 APIServer 对象：
```
$ oc edit apiserver
```
把 encryption 项类型设置为 aescbc：
```
spec:
  encryption:
    type: aescbc 1
```
1
aescbc 类型表示 AES-CBC 使用 PKCS#7 padding 和 32 字节密钥来执行加密。
保存文件以使改变生效。
加密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。
验证 etcd 加密是否成功。
1. 查看 OpenShift API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密：
```
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  在成功加密后输出显示 EncryptionCompleted：
```
EncryptionCompleted
All resources encrypted: routes.route.openshift.io
```
  如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。
2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密：
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  在成功加密后输出显示 EncryptionCompleted：
```
EncryptionCompleted
All resources encrypted: secrets, configmaps
```
  如果输出显示 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"}'
```
  在成功加密后输出显示 EncryptionCompleted：
```
EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
```
  如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

4.10.3. 禁用 etcd 加密

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

先决条件

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

流程

修改 APIServer 对象：
```
$ oc edit apiserver
```
将 encryption 字段类型设置为 identity：
```
spec:
  encryption:
    type: identity 1
```
1
identity 类型是默认值，意味着没有执行任何加密。
保存文件以使改变生效。
解密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。
验证 etcd 解密是否成功。
1. 查看 OpenShift API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密：
```
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  在成功解密后输出显示 DecryptionCompleted：
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。
2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密：
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  在成功解密后输出显示 DecryptionCompleted：
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  如果输出显示 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"}'
```
  在成功解密后输出显示 DecryptionCompleted：
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

4.10.4. 备份 etcd 数据

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

重要

仅保存单一 control plane 主机（也称为 master 主机）的备份。不要从集群中的每个 control plane 主机进行备份。

先决条件

您可以使用具有 cluster-admin 角色的用户访问集群。
您已检查是否启用了集群范围代理。
提示
您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxy、httpsProxy和 noProxy 字段设置了值，则会启用代理。

流程

为 control plane 节点启动一个 debug 会话：
```
$ oc debug node/<node_name>
```
将您的根目录改为 /host ：
```
sh-4.2# chroot /host
```
如果启用了集群范围的代理，请确定已导出了 NO_PROXY、HTTP_PROXY和 HTTPS_PROXY 环境变量。

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

脚本输出示例

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

在这个示例中，在 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.10.5. 分离 etcd 数据

对于大型、高密度的集群，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。定期维护并处理碎片化的 etcd，以释放数据存储中的空间。监控 Prometheus 以了解 etcd 指标数据，并在需要时对其进行碎片处理；否则，etcd 可能会引发一个集群范围的警报，使集群进入维护模式，仅能接受对键的读和删除操作。

监控这些关键指标：

etcd_server_quota_backend_bytes，这是当前配额限制
etcd_mvcc_db_total_size_in_use_in_bytes，表示历史压缩后实际数据库使用量
etcd_debugging_mvcc_db_total_size_in_bytes 会显示数据库大小，包括等待碎片整理的空闲空间

在导致磁盘碎片的事件后（如 etcd 历史记录紧凑）对 etcd 数据进行清理以回收磁盘空间。

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

因为 etcd 将数据写入磁盘，所以其性能主要取决于磁盘性能。根据您的集群的具体情况，考虑每个月清理一次 etcd 碎片，或每个月清理两次。您还可以监控 etcd_db_total_size_in_bytes 指标，以确定是否需要进行碎片操作。

您还可以通过检查 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 角色的用户访问集群。

流程

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

获取 etcd pod 列表：

$ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd

输出示例

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>

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

$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

输出示例

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.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

基于此输出的 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
```
取消设置 ETCDCTL_ENDPOINTS 环境变量：
```
sh-4.4# unset ETCDCTL_ENDPOINTS
```

清理 etcd 成员：

sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

输出示例

Finished defragmenting etcd member[https://localhost:2379]

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

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

sh-4.4# etcdctl endpoint status -w table --cluster

输出示例

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         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.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

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

重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。
至少要在碎片处理操作之间等待一分钟，以便 etcd pod 可以恢复。在 etcd pod 恢复前，etcd 成员不会响应。

如果因为超过空间配额而触发任何 NOSPACE 警告，请清除它们。
1. 检查是否有 NOSPACE 警告：
```
sh-4.4# etcdctl alarm list
```
  输出示例
```
memberID:12345678912345678912 alarm:NOSPACE
```
2. 清除警告：
```
sh-4.4# etcdctl alarm disarm
```

4.10.6. 恢复到一个以前的集群状态

您可以使用已保存的 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。
1. 访问不是恢复主机的 control plane 主机。
2. 将现有 etcd pod 文件从 Kubelet 清单目录中移出：
```
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
```
3. 验证 etcd pod 是否已停止。
```
$ sudo crictl ps | grep etcd | grep -v operator
```
  命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。
4. 将现有 Kubernetes API 服务器 pod 文件移出 kubelet 清单目录中：
```
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
```
5. 验证 Kubernetes API 服务器 pod 是否已停止。
```
$ sudo crictl ps | grep kube-apiserver | grep -v operator
```
  命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。
6. 将 etcd 数据目录移到不同的位置：
```
$ sudo mv /var/lib/etcd/ /tmp
```
7. 在其他不是恢复主机的 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 服务。
1. 在恢复主机中运行以下命令：
```
$ sudo systemctl restart kubelet.service
```
2. 在所有其他 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
...

1 1 2: 一个待处理的 kubelet 服务 CSR（用于用户置备的安装）。
3 4: 一个待处理的 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>
```

确认单个成员 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 用户连接到集群，运行以下命令。
1. 为 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，这意味着更新仍在进行中。等待几分钟后重试。
2. 为 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，这意味着更新仍在进行中。等待几分钟后重试。
3. 为 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 进行身份验证可能无法立即正常工作。

4.10.7. 恢复持久性存储状态的问题和解决方法

如果您的 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）。

4.10. etcd 任务

4.10.1. 关于 etcd 加密

4.10.2. 启用 etcd 加密

4.10.3. 禁用 etcd 加密

4.10.4. 备份 etcd 数据

4.10.5. 分离 etcd 数据

4.10.6. 恢复到一个以前的集群状态

4.10.7. 恢复持久性存储状态的问题和解决方法

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links