故障排除
第 1 章 检查您已安装了哪个版本
要开始故障排除，请确定您已安装了哪个红帽构建的 MicroShift 版本。
1.1. 使用命令行界面检查版本
在开始故障排除前，需要知道您的 MicroShift 版本。获取此信息的一种方法是使用 CLI。
流程
运行以下命令来检查版本信息：
$ microshift version
输出示例
Red Hat build of MicroShift Version: 4.17-0.microshift-e6980e25 Base OCP Version: 4.17
1.2. 使用 API 检查 MicroShift 版本
在开始故障排除前，需要知道您的 MicroShift 版本。获取此信息的一种方法是使用 API。
流程
要使用 OpenShift CLI (
oc) 获取版本号，请运行以下命令来查看kube-public/microshift-version配置映射：$ oc get configmap -n kube-public microshift-version -o yaml
输出示例
apiVersion: v1 data: major: "4" minor: "13" version: 4.13.8-0.microshift-fa441af87431 kind: ConfigMap metadata: creationTimestamp: "2023-08-03T21:06:11Z" name: microshift-version namespace: kube-public
1.3. 检查 etcd 版本
您可以使用以下方法之一获取 MicroShift 中包含的 etcd 数据库的版本信息，具体取决于您需要的信息级别。
流程
要显示基本数据库版本信息，请运行以下命令：
$ microshift-etcd version
输出示例
microshift-etcd Version: 4.17.1 Base etcd Version: 3.5.13
要显示完整的数据库版本信息，请运行以下命令：
$ microshift-etcd version -o json
输出示例
{ "major": "4", "minor": "16", "gitVersion": "4.17.1~rc.1", "gitCommit": "140777711962eb4e0b765c39dfd325fb0abb3622", "gitTreeState": "clean", "buildDate": "2024-05-10T16:37:53Z", "goVersion": "go1.21.9" "compiler": "gc", "platform": "linux/amd64", "patch": "", "etcdVersion": "3.5.13" }
第 2 章 集群故障排除
要开始对 MicroShift 集群进行故障排除，首先访问集群状态。
2.1. 检查集群的状态
您可以检查 MicroShift 集群的状态，或查看活跃的 pod。以下流程中给出有三个不同的命令，可用于检查集群状态。您可以选择运行一个、两个或所有命令，以帮助您获取对集群进行故障排除所需的信息。
流程
运行以下命令，检查返回集群状态的系统状态：
$ sudo systemctl status microshift
如果 MicroShift 无法启动，这个命令会返回上一个运行的日志。
健康输出示例
● microshift.service - MicroShift Loaded: loaded (/usr/lib/systemd/system/microshift.service; enabled; preset: disabled) Active: active (running) since <day> <date> 12:39:06 UTC; 47min ago Main PID: 20926 (microshift) Tasks: 14 (limit: 48063) Memory: 542.9M CPU: 2min 41.185s CGroup: /system.slice/microshift.service └─20926 microshift run <Month-Day> 13:23:06 i-06166fbb376f14a8b.<hostname> microshift[20926]: kube-apiserver I0528 13:23:06.876001 20926 controll> <Month-Day> 13:23:06 i-06166fbb376f14a8b.<hostname> microshift[20926]: kube-apiserver I0528 13:23:06.876574 20926 controll> # ...可选：运行以下命令来获取全面的日志：
$ sudo journalctl -u microshift
注意systemd日志服务的默认配置会将数据存储在易失性目录中。要在系统重启后保留系统日志，请启用日志持久性并为最大日志数据大小设置限制。可选：如果 MicroShift 正在运行，请输入以下命令检查活跃 pod 的状态：
$ oc get pods -A
输出示例
NAMESPACE NAME READY STATUS RESTARTS AGE default i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr 1/1 Running 0 46m kube-system csi-snapshot-controller-5c6586d546-lprv4 1/1 Running 0 51m kube-system csi-snapshot-webhook-6bf8ddc7f5-kz6k9 1/1 Running 0 51m openshift-dns dns-default-45jl7 2/2 Running 0 50m openshift-dns node-resolver-7wmzf 1/1 Running 0 51m openshift-ingress router-default-78b86fbf9d-qvj9s 1/1 Running 0 51m openshift-ovn-kubernetes ovnkube-master-5rfhh 4/4 Running 0 51m openshift-ovn-kubernetes ovnkube-node-gcnt6 1/1 Running 0 51m openshift-service-ca service-ca-bf5b7c9f8-pn6rk 1/1 Running 0 51m openshift-storage topolvm-controller-549f7fbdd5-7vrmv 5/5 Running 0 51m openshift-storage topolvm-node-rht2m 3/3 Running 0 50m
注意这个示例输出显示基本的 MicroShift。如果您安装了可选的 RPM，则您的输出中也会显示运行这些服务的 pod 状态。
第 3 章 安装问题的故障排除
要排除 MicroShift 安装失败的问题，您可以运行 sos 报告。使用 sos report 命令生成一个详细报告，其中显示了系统中不同组件和应用程序的所有启用插件和数据。
3.1. 从 sos 报告收集数据
先决条件
-
已安装
sos软件包。
流程
- 以 root 用户身份登录到失败的主机。
运行以下命令执行 debug 报告创建过程：
$ microshift-sos-report
输出示例
sosreport (version 4.5.1) This command will collect diagnostic and configuration information from this Red Hat Enterprise Linux system and installed applications. An archive containing the collected information will be generated in /var/tmp/sos.o0sznf_8 and may be provided to a Red Hat support representative. Any information provided to Red Hat will be treated in accordance with the published support policies at: Distribution Website : https://www.redhat.com/ Commercial Support : https://www.access.redhat.com/ The generated archive may contain data considered sensitive and its content should be reviewed by the originating organization before being passed to any third party. No changes will be made to system configuration. Setting up archive ... Setting up plugins ... Running plugins. Please wait ... Starting 1/2 microshift [Running: microshift] Starting 2/2 microshift_ovn [Running: microshift microshift_ovn] Finishing plugins [Running: microshift] Finished running plugins Found 1 total reports to obfuscate, processing up to 4 concurrently sosreport-microshift-rhel9-2023-03-31-axjbyxw : Beginning obfuscation... sosreport-microshift-rhel9-2023-03-31-axjbyxw : Obfuscation completed Successfully obfuscated 1 report(s) Creating compressed archive... A mapping of obfuscated elements is available at /var/tmp/sosreport-microshift-rhel9-2023-03-31-axjbyxw-private_map Your sosreport has been generated and saved in: /var/tmp/sosreport-microshift-rhel9-2023-03-31-axjbyxw-obfuscated.tar.xz Size 444.14KiB Owner root sha256 922e5ff2db25014585b7c6c749d2c44c8492756d619df5e9838ce863f83d4269 Please send this file to your support representative.
3.2. 其他资源
第 4 章 数据备份和恢复故障排除
要排除失败的数据备份和恢复的问题，请首先检查基本知识，如数据路径、存储配置和存储容量。
4.1. 备份数据失败
在 rpm-ostree 系统上，数据备份是自动的。如果您不使用 rpm-ostree 系统并尝试创建手动备份，则以下原因可能会导致备份失败：
- 在系统启动成功停止 MicroShift 后，不会等待几分钟。系统必须在备份成功前完成健康检查和任何其他后台进程。
如果 MicroShift 因错误而停止运行，则无法对数据执行备份。
- 确保系统健康。
- 在尝试备份前，停止它处于健康状态。
- 如果您没有足够的存储数据，备份会失败。确保有足够的存储 MicroShift 数据。
- 如果您没有足够的权限，备份可能会失败。确保您有正确的用户权限来创建备份并执行所需的配置。
4.2. 备份日志
- 在手动备份过程中，日志会打印到终端控制台。
作为 MicroShift 日志的一部分，会自动为
rpm-ostree系统自动备份生成日志。您可以运行以下命令来检查日志：$ sudo journalctl -u microshift
4.3. 恢复数据失败
恢复数据可能会因为许多原因失败，包括存储和权限问题。不匹配的数据版本可能会导致 MicroShift 重启时失败。
4.3.1. 基于 RPM-OSTree 的系统数据恢复失败
数据恢复是在 rpm-ostree 系统上自动进行的，但可能会失败，例如：
在
rpm-ostree系统上恢复的唯一备份是从当前部署或回滚部署备份。备份不会在不健康的系统上进行。- 只有具有相应部署的最新备份才会保留。过时的备份没有匹配的部署会被自动删除。
- 数据通常不会从较新的 MicroShift 版本恢复。
- 确保正在恢复的数据遵循与更新路径相同的版本模式。例如，如果 MicroShift 的目的地版本比您当前使用的 MicroShift 数据版本旧版本，则恢复可能会失败。
4.3.2. 基于 RPM 的手动数据恢复失败
如果您使用不是 rpm-ostree 的 RPM 系统，并尝试恢复手动备份，则以下原因可能会导致恢复失败：
如果 MicroShift 因错误而停止运行，则无法恢复数据。
- 确保系统健康。
- 在尝试恢复数据前，启动它处于健康状态。
如果您没有为传入的数据分配足够存储空间，恢复会失败。
- 确保您的当前系统存储已配置为接受恢复的数据。
尝试从新版本的 MicroShift 恢复数据。
- 确保正在恢复的数据遵循与更新路径相同的版本模式。例如，如果 MicroShift 的目的地版本比您试图使用的 MicroShift 数据版本旧版本，则恢复可能会失败。
4.4. 存储迁移失败
存储迁移失败通常是因为自定义资源(CR)中的大量更改从一个 MicroShift 变为下一个。如果存储迁移失败，则通常会在需要手动审核的版本之间存在无法解析的差异。
第 5 章 对更新进行故障排除
要对 MicroShift 更新进行故障排除，请使用以下指南。
5.1. MicroShift 更新故障排除
在某些情况下，MicroShift 可能无法更新。在这些事件中，了解设备类型以及如何对它们进行故障排除会很有帮助。
5.1.1. 更新路径会受版本不兼容阻止
如果 MicroShift 更新与 Red Hat Enterprise Linux for Edge 版本(RHEL for Edge)或 Red Hat Enterprise Linux (RHEL)版本不兼容，则 RPM 依赖项错误结果。
5.1.1.1. 兼容性表
检查以下兼容性表：
Red Hat Device Edge 发行版本兼容性列表
Red Hat Enterprise Linux (RHEL)和 MicroShift 作为一个设备边缘计算的单一解决方案一起工作。您可以单独更新每个组件，但产品版本必须兼容。支持的 Red Hat Device Edge 配置会为每个版本一起使用验证的版本，如下表所示：
| RHEL 版本 | MicroShift 版本 | 支持的 MicroShift 版本 → 版本更新 |
|---|---|---|
| 9.4 | 4.17 | 4.17.1 → 4.17.z |
| 9.4 | 4.16 | 4.16.0 → 4.16.z, 4.16 → 4.17 |
| 9.2, 9.3 | 4.15 | 4.15.0 → 4.15.z, 4.15 → 4.16 on RHEL 9.4 |
| 9.2, 9.3 | 4.14 | 4.14.0 → 4.14.z, 4.14 → 4.15 或 4.14 → 4.16 on RHEL 9.4 |
5.1.1.2. 版本兼容性
检查以下更新路径：
红帽 MicroShift 更新路径的构建
- RHEL for Edge 9.4 上正式发布版本 4.17.1 到 4.17.z
- RHEL 9.4 上正式发布版本 4.15.0 从 RHEL 9.2 升级到 4.16.0
- RHEL 9.4 上正式发布版本 4.14.0 从 RHEL 9.2 到 4.15.0
5.1.2. ostree 更新失败
如果您在 OSTree 系统中更新，Greenboot 健康检查会自动记录并操作系统健康状况。Greenboot 可以表示系统回滚失败。如果更新失败，但 Greenboot 没有完成系统回滚，您可以使用遵循此内容的"Additional resources"部分中的 RHEL for Edge 文档进行故障排除。
- 手动检查 Greenboot 日志
运行以下命令手动检查 Greenboot 日志以验证系统健康状况：
$ sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheck
5.1.3. 手动 RPM 更新失败
如果您使用非OSTree 系统上的 RPM 更新，则 Greenboot 可以指示更新失败，但健康检查只是信息性。检查系统日志是对手动 RPM 更新失败的故障排除步骤。您可以使用 Greenboot 和 sos 报告 来检查 MicroShift 更新和主机系统。
5.2. 在更新后检查日志
在某些情况下，MicroShift 可能无法更新。在这些事件中，了解设备类型以及如何对它们进行故障排除会很有帮助。日志可帮助诊断更新失败。
systemd 日志服务的默认配置会将数据存储在易失性目录中。要在系统重启后保留系统日志，请启用日志持久性并为最大日志数据大小设置限制。
流程
运行以下命令来获取全面的 MicroShift 日志：
$ sudo journalctl -u microshift
运行以下命令检查 Greenboot 日志：
$ sudo journalctl -u greenboot-healthcheck
检查特定引导的综合日志使用了三个步骤：首先列出引导，然后从您获取的列表中选择您想要的：
运行以下命令，列出日志日志中的引导：
$ sudo journalctl --list-boots
输出示例
IDX BOOT ID FIRST ENTRY LAST ENTRY 0 681ece6f5c3047e183e9d43268c5527f <Day> <Date> 12:27:58 UTC <Day> <Date>> 13:39:41 UTC #....
运行以下命令，检查您想要的特定引导的日志：
$ sudo journalctl --boot <idx_or_boot_id> 1
- 1
- 将
<idx_or_boot_id> 替换为分配给您要检查的特定引导的IDX或BOOT ID号。
运行以下命令，检查特定服务的引导日志：
$ sudo journalctl --boot <idx_or_boot_id> -u <service_name> 1 2
5.3. 检查 greenboot 健康检查的状态
在对系统进行更改或故障排除期间，检查 greenboot 健康检查的状态。您可以使用以下任一命令来帮助确保 greenboot 脚本已完成运行。
流程
要查看健康检查状态的报告，请使用以下命令：
$ systemctl show --property=SubState --value greenboot-healthcheck.service
-
start的输出表示 greenboot 检查仍在运行。 -
退出的输出表示检查已通过，reenboot 已退出。当系统处于健康状态时，greenboot 在green.d目录中运行脚本。 -
失败的输出表示检查尚未通过。greenboot 在系统处于此状态时在red.d目录中运行脚本，并可能重启系统。
-
要查看一个报告显示服务的数字退出代码，其中
0表示成功，非零值表示发生了失败，请使用以下命令：$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
要查看显示引导状态的报告，如
Boot Status 为 GREEN - Health Check SUCCESS，请使用以下命令：$ cat /run/motd.d/boot-status
第 6 章 检查审计日志
您可以使用审计日志来识别 pod 安全违反情况。
6.1. 通过审计日志识别 Pod 安全违反情况
您可以通过查看服务器审计日志来识别工作负载上的 pod 安全准入违反情况。以下流程演示了如何访问审计日志并解析它们以在工作负载中查找 pod 安全准入违反情况。
先决条件
-
您已安装了
jq。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
要检索节点名称，请运行以下命令：
$ <node_name>=$(oc get node -ojsonpath='{.items[0].metadata.name}')要查看审计日志，请运行以下命令：
$ oc adm node-logs <node_name> --path=kube-apiserver/ 1- 1
- 将 <node_name > 替换为从上一步中检索的节点的名称。
输出示例
rhel-94.lab.local audit-2024-10-18T18-25-41.663.log rhel-94.lab.local audit-2024-10-19T11-21-29.225.log rhel-94.lab.local audit-2024-10-20T04-16-09.622.log rhel-94.lab.local audit-2024-10-20T21-11-41.163.log rhel-94.lab.local audit-2024-10-21T14-06-10.402.log rhel-94.lab.local audit-2024-10-22T06-35-10.392.log rhel-94.lab.local audit-2024-10-22T23-26-27.667.log rhel-94.lab.local audit-2024-10-23T16-52-15.456.log rhel-94.lab.local audit-2024-10-24T07-31-55.238.log
要解析受影响的审计日志，请输入以下命令：
$ oc adm node-logs <node_name> --path=kube-apiserver/audit.log \ | jq -r 'select((.annotations["pod-security.kubernetes.io/audit-violations"] != null) and (.objectRef.resource=="pods")) | .objectRef.namespace + " " + .objectRef.name + " " + .objectRef.resource' \ | sort | uniq -c 1- 1
- 将 <node_name > 替换为从上一步中检索的节点的名称。
第 7 章 对 etcd 进行故障排除
要对 etcd 进行故障排除并提高性能，请配置服务的内存允许。
7.1. 配置 memoryLimitMB 值来为 etcd 服务器设置参数
默认情况下，etcd 根据需要使用尽可能多的内存来处理系统上的负载。在内存有限制的系统中，您可能需要限制 etcd 使用的内存量。
流程
编辑
/etc/microshift/config.yaml文件，以设置memoryLimitMB值。etcd: memoryLimitMB: 128
注意MicroShift 上
memoryLimitMB所需的最小值为 128 MB。接近最小值的值可能会影响 etcd 性能。较小的限制，etcd 会对查询做出响应所需的时间。如果限制太小，或者 etcd 的使用量很高，查询会超时。
验证
修改
/etc/microshift/config.yaml中的memoryLimitMB值后，运行以下命令重启 MicroShift：$ sudo systemctl restart microshift
运行以下命令验证新的
memoryLimitMB值是否在使用中：$ systemctl show --property=MemoryHigh microshift-etcd.scope
第 8 章 响应重启和安全证书
红帽构建的 MicroShift 在检测到更改后会对系统配置的更改（包括 IP 地址更改、时钟调整和安全证书期限）进行响应并重启。
8.1. IP 地址更改或时钟调整
MicroShift 依赖于设备 IP 地址和系统范围的时钟设置，以便在运行时保持一致。但是，这些设置偶尔可能会在边缘设备上更改，如 DHCP 或网络时间协议 (NTP) 更新。
当进行此类更改时，一些 MicroShift 组件可能会停止正常运行。为缓解这种情况，MalShift 会监控 IP 地址和系统时间，并在检测到任一设置更改时重新启动。
触发时钟更改的阈值是，时间的调整超过 10 秒（早或晚）。网络时间协 议(NTP) 服务会定期执行小的时间调整，这不会造成重启。
8.2. 安全证书生命周期
MicroShift 证书被分为两个基本组：
- 短期证书的有效期为一年。
- 长期证书的有效期为 10 年。
大多数服务器或叶证书都是短期的。
一个长期的证书示例是用于 system:admin 用户身份验证的客户端证书，或 kube-apiserver 外部服务证书的证书。
8.2.1. 证书轮转
过期或接近其过期日期的证书需要轮转，以确保继续 MicroShift 操作。当 MicroShift 因任何原因重启时，接近过期的证书将被轮转。当证书被设置为马上过期或已过期，可能会导致自动 MicroShift 重启执行轮转。
如果轮转的证书是证书颁发机构（CA），则其签署的所有证书都会轮转。
8.2.1.1. 短期证书
以下情况描述了在短期证书生命周期内 MicroShift 的操作：
无轮转：
- 当短期证书最多已存在 5 个月时，不会发生轮转。
重启时轮转：
- 当短期证书已存在 5 到 8 个月时，它会在 MicroShift 启动或重启时进行轮转。
自动重启进行轮转：
- 当短期证书存在超过 8 个月时，MicroShift 可以自动重启以轮转并应用新证书。
8.2.1.2. 长期证书
以下情况描述了在长期证书生命周期内 MicroShift 的操作：
无轮转：
- 当长期证书存在最多 8.5 年时，不会发生轮转。
重启时轮转：
- 当长期证书存在 8.5 到 9 年时，它会在 MicroShift 启动或重启时进行轮转。
自动重启进行轮转：
- 当长期证书存在超过 9 年时，MicroShift 可以自动重启来轮转并应用新证书。
第 9 章 使用支持清理数据
MicroShift 为各种故障排除任务提供 microshift-cleanup-data 脚本，如删除所有数据、证书和容器镜像。
不要在没有产品支持的指导的情况下运行此脚本。通过 提交支持问题单来联系支持。
9.1. 数据清理脚本概述
您可以通过运行不带参数的脚本来查看 microshift-cleanup-data 脚本的使用和列出可用选项。不带参数运行脚本不会删除任何数据或停止 MicroShift 服务。
流程
输入以下命令，查看使用并列出
microshift-cleanup-data脚本的可用选项：警告以下脚本操作中的一些选项是破坏性的，可能会导致数据丢失。有关警告，请查看每个参数的步骤。
$ microshift-cleanup-data
输出示例
Stop all MicroShift services, also cleaning their data Usage: microshift-cleanup-data <--all [--keep-images] | --ovn | --cert> --all Clean all MicroShift and OVN data --keep-images Keep container images when cleaning all data --ovn Clean OVN data only --cert Clean certificates only
9.2. 清理所有数据和配置
您可以通过运行 microshift-cleanup-data 脚本清理所有 MicroShift 数据和配置。
当使用- all 参数运行 脚本时，您可以执行以下清理操作：
- 停止并禁用所有 MicroShift 服务
- 删除所有 MicroShift pod
- 删除所有容器镜像存储
- 重置网络配置
-
删除
/var/lib/microshift数据目录 - 删除 OVN-K 网络配置
先决条件
- 您以具有 root-user 访问权限的管理员身份登录到 MicroShift。
- 您已提交了一个支持问题单。
流程
输入以下命令，使用--
all参数运行microshift-cleanup-data脚本清理所有 MicroShift 数据和配置：警告这个选项删除所有 MicroShift 数据和用户工作负载。请谨慎使用。
$ sudo microshift-cleanup-data --all
提示该脚本提示您显示一条消息来确认操作。键入 1 或 Yes 以继续。任何其它条目都取消清理。
继续清理时的输出示例
DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads? 1) Yes 2) No #? 1 Stopping MicroShift services Disabling MicroShift services Removing MicroShift pods Removing crio image storage Deleting the br-int interface Killing conmon, pause and OVN processes Removing MicroShift configuration Removing OVN configuration MicroShift service was stopped MicroShift service was disabled Cleanup succeeded
取消清理时的输出示例
DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads? 1) Yes 2) No #? no Aborting cleanup
重要在运行脚本后，MicroShift 服务会停止并禁用。
运行以下命令来重启 MicroShift 服务：
$ sudo systemctl enable --now microshift
9.3. 清理所有数据并保留容器镜像
您可以使用--all 和- keep-images 参数运行 时保留 MicroShift 容器镜像。microshift-cleanup-data 脚本，在清理所有数据
保留容器镜像有助于在数据清理后加快 MicroShift 重启，因为启动服务时所需的容器镜像已在本地存在。
使用-- all 和 -keep-images 参数运行脚本时，您将执行以下清理操作：
- 停止并禁用所有 MicroShift 服务
- 删除所有 MicroShift pod
- 重置网络配置
-
删除
/var/lib/microshift数据目录 - 删除 OVN-K 网络配置
这个选项删除所有 MicroShift 数据和用户工作负载。请谨慎使用。
先决条件
- 您以具有 root-user 访问权限的管理员身份登录到 MicroShift。
- 您已提交了一个支持问题单。
流程
输入以下命令通过运行带有--all 和-
keep-images 参数的脚本来清理所有数据和用户工作负载：microshift-cleanup-data$ sudo microshift-cleanup-data --all --keep-images
输出示例
DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads? 1) Yes 2) No #? Yes Stopping MicroShift services Disabling MicroShift services Removing MicroShift pods Deleting the br-int interface Killing conmon, pause and OVN processes Removing MicroShift configuration Removing OVN configuration MicroShift service was stopped MicroShift service was disabled Cleanup succeeded
运行以下命令验证容器镜像是否仍然存在：
$ sudo crictl images | awk '{print $1}'输出示例
IMAGE quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev quay.io/openshift-release-dev/ocp-v4.0-art-dev registry.redhat.io/lvms4/topolvm-rhel9 registry.redhat.io/openshift4/ose-csi-external-provisioner registry.redhat.io/openshift4/ose-csi-external-resizer registry.redhat.io/openshift4/ose-csi-livenessprobe registry.redhat.io/openshift4/ose-csi-node-driver-registrar registry.redhat.io/ubi9
重要在运行脚本后，MicroShift 服务会停止并禁用。
运行以下命令来重启 MicroShift 服务：
$ sudo systemctl enable --now microshift
9.4. 清理 OVN-Kubernetes 数据
您可以通过运行 microshift-cleanup-data 脚本来清理 OVN-Kubernetes (ONV-K)数据。使用 脚本重置 OVN-K 网络配置。
当使用- ovn 参数运行 脚本时，您可以执行以下清理操作：
- 停止所有 MicroShift 服务
- 删除所有 MicroShift pod
- 删除 OVN-K 网络配置
先决条件
- 您以具有 root-user 访问权限的管理员身份登录到 MicroShift。
- 您已提交了一个支持问题单。
流程
输入以下命令，使用--
ovn参数运行microshift-cleanup-data脚本清理 OVN-K 数据：$ sudo microshift-cleanup-data --ovn
输出示例
Stopping MicroShift services Removing MicroShift pods Killing conmon, pause and OVN processes Removing OVN configuration MicroShift service was stopped Cleanup succeeded
重要在运行脚本后，MicroShift 服务将停止。
运行以下命令来重启 MicroShift 服务：
$ sudo systemctl start microshift
9.5. 清理自定义证书数据
您可以使用 microshift-cleanup-data 脚本重置 MicroShift 自定义证书，以便在 MicroShift 服务重启时重新创建它们。
当使用- cert 参数运行 脚本时，您可以执行以下清理操作：
- 停止所有 MicroShift 服务
- 删除所有 MicroShift pod
- 删除所有 MicroShift 证书
先决条件
- 您以具有 root-user 访问权限的管理员身份登录到 MicroShift。
- 您已提交了一个支持问题单。
流程
输入以下命令，使用-
cert参数运行microshift-cleanup-data脚本来清理 MicroShift 证书：$ sudo microshift-cleanup-data --cert
输出示例
Stopping MicroShift services Removing MicroShift pods Removing MicroShift certificates MicroShift service was stopped Cleanup succeeded
重要在运行脚本后，MicroShift 服务将停止。
运行以下命令来重启 MicroShift 服务：
$ sudo systemctl start microshift
