link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

支持

PDF

OpenShift Container Platform 4.8

获取 OpenShift Container Platform 支持

Red Hat OpenShift Documentation Team

法律通告

摘要

本文档提供了有关从红帽获取 OpenShift Container Platform 支持的信息。文中还包含有关通过 Telemetry 和 Insights Operator 进行远程健康监控的信息。本文档还详细介绍了远程健康监控的好处。

第 1 章支持概述

红帽提供了集群管理员工具，用于为集群、监控和故障排除收集数据。

1.1. 获得支持

获取支持：访问红帽客户门户网站查看知识库文章、提交支持问题单以及查看其他产品文档和资源。

1.2. 远程健康监控问题

远程健康监控问题：OpenShift Container Platform 会收集有关集群的遥测和配置数据，并使用 Telemeter Client 和 Insights Operator 向红帽报告。红帽使用此数据了解并解决 连接的集群 中的问题。与连接的集群类似，您可以在受限网络中使用远程健康监控。OpenShift Container Platform 使用以下方法收集数据和监控健康状况： Telemetry ：遥测客户端收集并每 4 分 30 秒将标值上传至红帽。红帽将此数据用于：监控集群。推出 OpenShift Container Platform 升级。改进升级体验。 Insights Operator ：默认情况下，OpenShift Container Platform 安装并启用 Insight Operator，每两小时报告配置和组件故障状态。Insight Operator 有助于：主动识别潜在的集群问题。在 Red Hat OpenShift Cluster Manager 中提供解决方案和预防性操作。您可以查看遥测信息。如果您启用了远程健康报告，请使用 Insights 来识别问题。您可以选择禁用远程健康报告。

1.3. 收集有关集群的数据

收集有关集群的数据：红帽建议在打开支持问题单时收集您的调试信息。这有助于红帽支持执行根本原因分析。集群管理员可以使用以下方法收集有关集群的数据： must-gather 工具 ：使用 must-gather 工具收集有关集群的信息并调试问题。 sosreport ：使用 sosreport 工具收集配置详情、系统信息和诊断数据用于调试目的。 集群 ID ：在向红帽支持提供信息时，获取集群的唯一标识符。 bootstrap 节点日志 : 收集 bootkube.service journald 单元日志和来自 bootstrap 节点的容器日志，以排除与 bootstrap 相关的问题。 集群节点 journal 日志 ：收集 journald 单元日志和独立集群节点上的 /var/log 中的日志，以排除与节点相关的问题。 网络追踪 ：从特定的 OpenShift Container Platform 集群节点或一个容器提供给红帽支持提供网络数据包跟踪，以帮助排除与网络相关的问题。 诊断数据 ：使用 redhat-support-tool 命令收集有关集群的诊断数据。

1.4. 故障排除问题

集群管理员可以监控并排除以下 OpenShift Container Platform 组件问题：安装问题：OpenShift Container Platform 安装可完成各种阶段。您可以执行以下操作：监控安装阶段。确定在哪个阶段安装问题发生。调查多个安装问题。从失败安装中收集日志。节点问题：集群管理员可以通过查看节点的状态、资源使用量和配置来验证和排除节点相关问题。您可以查询以下内容：节点上的 kubelet 状态。集群节点日志. Crio 问题：集群管理员可在每个集群节点上验证 CRI-O 容器运行时引擎状态。如果遇到容器运行时问题，请执行以下操作：收集 CRI-O journald 单元日志。清理 CRI-O 存储。操作系统问题：OpenShift Container Platform 在 Red Hat Enterprise Linux CoreOS 上运行。如果遇到操作系统问题，可以调查内核崩溃过程。确保以下内容：启用 kdump。测试 kdump 配置。分析内核转储。网络问题：要对 Open vSwitch 问题进行故障排除，集群管理员可以执行以下操作：临时配置 Open vSwitch 日志级别。永久配置 Open vSwitch 日志级别。显示 Open vSwitch 日志。 Operator 问题：集群管理员可以执行以下操作来解决 Operator 问题：验证 Operator 订阅状态。检查 Operator pod 健康状况。收集 Operator 日志。 Pod 问题：集群管理员可以通过查看 pod 的状态并完成以下内容来排除与 pod 相关的问题：查看 pod 和容器日志。启动具有 root 访问权限的 debug pod。 Source-to-image 问题：集群管理员可以观察 S2I 阶段，以确定 S2I 进程中的故障发生位置。收集以下内容来解决 Source-to-Image(S2I)问题： Source-to-Image 诊断数据。用于调查应用程序故障的应用程序诊断数据。存储问题：当无法在新节点中挂载卷时，会发生多附加存储错误，因为失败的节点无法卸载附加的卷。集群管理员可执行以下操作解决多附加存储问题：使用 RWX 卷启用多个附件。使用 RWO 卷时,恢复或删除故障节点。监控问题：集群管理员可按照监控故障排除页面中的步骤进行操作。如果您的用户定义的项目的指标不可用，或者 Prometheus 消耗了大量磁盘空间，请检查以下内容：调查用户定义的指标不可用的原因。确定为什么 Prometheus 消耗大量磁盘空间。日志记录问题：集群管理员可以按照 OpenShift Logging 问题的故障排除页面上的步骤进行操作。检查以下内容以解决日志问题： Logging Operator 的状态。日志存储的状态。 OpenShift Logging 警报 . 使用 oc adm must-gather 命令有关 OpenShift 日志记录环境的信息。 OpenShift CLI(oc)问题：通过增加日志级别来判断 OpenShift CLI(oc)问题。

第 2 章管理集群资源

您可以在 OpenShift Container Platform 中应用全局配置选项。Operator 在集群中应用这些配置设置。

2.1. 与集群资源交互

您可以使用 OpenShift Container Platform 中的 OpenShift CLI( oc )工具与集群资源交互。运行 oc api-resources 命令后看到的集群资源可以被编辑。您可以使用具有 cluster-admin 角色的用户访问集群。您可以访问 web 控制台或已安装了 oc CLI 工具。要查看应用了哪些配置 Operator，请运行以下命令：

$ oc api-resources -o name | grep config.openshift.io

要查看您可以配置的集群资源，请运行以下命令：

$ oc explain <resource_name>.config.openshift.io

要查看集群中的自定义资源定义(CRD)对象配置，请运行以下命令：

$ oc get <resource_name>.config -o yaml

要编辑集群资源配置，请运行以下命令：

$ oc edit <resource_name>.config -o yaml

第 3 章获取支持

3.1. 获取支持

如果您在执行本文档所述的某个流程或 OpenShift Container Platform 时遇到问题，请访问红帽客户门户网站。通过红帽客户门户网站：搜索或者浏览红帽知识库，了解与红帽产品相关的文章和解决方案。提交问题单给红帽支持。访问其他产品文档。要识别集群中的问题，您可以在 OpenShift Cluster Manager 中使用 Insights。Insights 提供了问题的详细信息，并在有可用的情况下，提供了如何解决问题的信息。如果您对本文档有任何改进建议，或发现了任何错误，请为相关文档组件提交 JIRA 问题。请提供具体详情，如章节名称和 OpenShift Container Platform 版本。

3.2. 关于红帽知识库

红帽知识库提供丰富的内容以帮助您最大程度地利用红帽的产品和技术。红帽知识库包括文章、产品文档和视频，概述了安装、配置和使用红帽产品的最佳实践。另外，您还可以搜索已知问题的解决方案，其提供简洁的根原因描述和补救措施。

3.3. 搜索红帽知识库

如果出现 OpenShift Container Platform 问题，您可以先进行搜索，以确定红帽知识库中是否已存在相关的解决方案。您有红帽客户门户网站帐户。登录到红帽客户门户网站。在主红帽客户门户网站搜索字段中，输入与问题相关的关键字和字符串，包括： OpenShift Container Platform 组件（如 etcd ）相关步骤（比如安装）警告、错误消息和其他与输出与特定的问题相关点 Search 。选择 OpenShift Container Platform 产品过滤器。在内容类型过滤中选择 Knowledgebase 。

3.4. 提交支持问题单

先决条件

已安装 OpenShift CLI（ oc ）。您有红帽客户门户网站帐户。您可以访问 OpenShift Cluster Manager 。登录到红帽客户门户网站并选择 SUPPORT CASES → Open a case 。为您的问题选择适当的类别（如 Defect / Bug ）、产品( OpenShift Container Platform )和产品版本（如果还没有自动填充则为 4.8 ）。查看推荐的红帽知识库解决方案列表，它们可能会与您要报告的问题相关。如果建议的文章没有解决这个问题，请点 Continue 。输入一个简洁但描述性的问题概述，以及问题症状的详细信息，以及您预期的结果。查看更新的推荐红帽知识库解决方案列表，它们可能会与您要报告的问题相关。这个列表的范围会缩小，因为您在创建问题单的过程中提供了更多信息。如果建议的文章没有解决这个问题，请点 Continue 。请确保提供的帐户信息是正确的，如果需要，请相应调整。检查自动填充的 OpenShift Container Platform 集群 ID 是否正确。如果不正确，请手动提供集群 ID。使用 OpenShift Container Platform Web 控制台手动获得集群 ID：导航到 Home → Dashboards → Overview 。该值包括在 Details 中的 Cluster ID 项中。另外，也可以通过 OpenShift Container Platform Web 控制台直接创建新的支持问题单，并自动填充集群 ID。从工具栏导航至 （？） help → Open Support Case 。 Cluster ID 的值会被自动填充。要使用 OpenShift CLI（ oc ）获取集群 ID，请运行以下命令：
```
$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
```

完成以下提示的问题，点 Continue : 您在哪里遇到了这个问题？什么环境？这个行为在什么时候发生？发生频率？重复发生？是否只在特定时间发生？请提供这个问题对您的业务的影响及与时间相关的信息？上传相关的诊断数据文件并点击 Continue 。建议您将使用 oc adm must-gather 命令收集的数据作为起点，并提供这个命令没有收集的与您的具体问题相关的其他数据。输入相关问题单管理详情，点 Continue 。预览问题单详情，点 Submit 。

3.5. 其他资源

有关识别集群问题的详情，请参阅使用 Insights 识别集群中的问题。

第 4 章通过连接集群进行远程健康监控

4.1. 关于远程健康监控

OpenShift Container Platform 会收集有关集群的遥测和配置数据，并使用 Telemeter Client 和 Insights Operator 向红帽报告。提供给红帽的数据可实现本文档概述的好处。通过 Telemetry 和 Insights Operator 向红帽报告数据的集群被称为 连接的集群 (connected cluster) 。 Telemetry 是红帽用来描述 OpenShift Container Platform Telemeter 客户端向红帽发送的信息的术语。轻量级属性从连接的集群发送到红帽，以便启用订阅管理自动化、监控集群的健康状态、提供支持以及改进客户体验。 Insights Operator 收集 OpenShift Container Platform 配置数据并将其发送到红帽。这些数据用于生成有关集群可能潜在存在的问题的分析报告。这些分析结果会通过 console.redhat.com/openshift 提供给集群管理员。本文档中提供了有关这两个工具的更多信息。

Telemetry 和 Insights Operator 的优点

Telemetry 和 Insights Operator 为最终用户提供以下优点： 增强了识别和解决问题的能力 。对于一些事件，最终用户可能会认为是正常的，但从更广泛深入的角度来说，红帽会对这些事件的影响有不同的评估。因此，一些问题可以被更快地识别并解决，而不需要用户创建一个支持问题单或 Jira issue 。 高级的版本管理 。OpenShift Container Platform 提供了 candidate 、 fast 和 stable 发行频道，供您选择一个最佳的更新策略。版本从 fast 到 stable 的过程取决于更新的速度以及升级过程中的事件。通过连接的集群提供的信息，红帽可以将发行版本质量提高到 stable 频道，并对在 fast 频道中发现的问题做出更快反应。 有针对性地对新功能的开发进行优先级排序 。通过收集的数据，可以了解哪些 OpenShift Container Platform 的功能被用户广泛使用。通过这些信息，红帽可以专注于开发对客户有严重影响的新功能。 更好的支持体验 。在红帽客户门户网站上创建支持问题单时，可以为连接的集群提供集群 ID。这可让红帽通过使用连接的信息，简化用户的支持体验。本文档提供有关改进的支持体验的更多信息。 预测分析 。通过从连接集群收集到的信息，可以在 console.redhat.com/openshift 中显示与您的集群相关的 insights 信息。红帽正在积极应用深入学习、机器学习及智能自动化，以帮助识别 OpenShift Container Platform 集群潜在的问题。

4.1.1. 关于 Telemetry

Telemetry 会向红帽发送一组精选的集群监控指标子集。Telemeter 客户端每四分三十秒获取一次指标值，并将数据上传到红帽。本文档中描述了这些指标。红帽使用这一数据流来实时监控集群，必要时将对影响客户的问题做出反应。它同时还有助于红帽向客户推出 OpenShift Container Platform 升级，以便最大程度降低服务影响，持续改进升级体验。这类调试信息将提供给红帽支持和工程团队，其访问限制等同于访问通过问题单报告的数据。红帽利用所有连接集群信息来帮助改进 OpenShift Container Platform，提高其易用性。有关更新或升级集群的更多信息，请参阅 OpenShift Container Platform 更新文档。

4.1.1.1. Telemetry 收集的信息

Telemetry 收集以下信息：安装期间生成的唯一随机标识符版本信息，包括 OpenShift Container Platform 集群版本并安装了用于决定更新版本可用性的更新详情更新信息，包括每个集群可用的更新数、用于更新的频道和镜像存储库、更新进度信息以及更新中发生的错误数部署 OpenShift Container Platform 的供应商平台的名称及数据中心位置有关集群、机器类型和机器的大小信息，包括 CPU 内核数和每个机器所使用的 RAM 量 etcd 成员数和存储在 etcd 集群中的对象数量在集群中安装的 OpenShift Container Platform 框架组件及其状况和状态有关组件、功能和扩展的使用情况信息有关技术预览和不受支持配置的使用详情有关降级软件的信息标记为 NotReady 的节点的信息为降级 Operator 列出为 "related objects" 的所有命名空间的事件帮助红帽支持为客户提供有用支持的配置详情，包括云基础架构级别的节点配置、主机名、IP 地址、Kubernetes pod 名称、命名空间和服务有关证书的有效性的信息根据构建策略类型进行应用构建数量 Telemetry 不会收集任何身份识别的信息，如用户名或密码。红帽不会收集个人信息。如果红帽发现个人信息被意外地收到，红帽会删除这些信息。有关红帽隐私实践的更多信息，请参考红帽隐私声明。如需了解如何列出 Telemetry 中从 Prometheus 收集的属性的详细信息，请参阅显示 Telemetry 收集的数据。如需 Telemetry 从 Prometheus 收集的属性列表，请参阅上游 cluster-monitoring-operator 源代码。在默认情况下，Telemetry 会被安装并启用。如果您需要选择不使用远程健康报告，请参阅不使用远程健康报告。

4.1.2. 关于 Insights Operator

Insights Operator 会定期收集配置和组件故障状态信息，默每两小时向红帽报告这些数据。这些信息可让红帽评估配置，它提供了比 Telemetry 报告更深入的数据。 OpenShift Container Platform 用户可以在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中显示每个集群的报告。如果发现了任何问题，Insights 会提供更详细的信息，并在可能的情况下提供如何解决相关问题的步骤。 Insights Operator 不会收集任何身份识别信息，如用户名、密码或证书。如需有关 Red Hat Insights 数据收集和控制的信息，请参阅 Red Hat Insights 数据和应用程序安全性。红帽使用所有连接的集群信息以实现：识别潜在的集群问题，并在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中提供解决方案和防止动作通过为产品和支持团队提供聚合和重要信息来改进 OpenShift Container Platform 使 OpenShift Container Platform 更直观 Insights Operator 被默认安装并启用。如果您需要选择不使用远程健康报告，请参阅不使用远程健康报告。

4.1.2.1. Insights Operator 收集的信息

Insights Operator 收集以下信息：有关集群及其组件的常规信息，以识别与您所使用的具体 OpenShift Container Platform 版本和环境的相关问题集群的配置文件（如容器镜像仓库的配置）用于识别设置参数中的问题集群组件中发生的错误正在运行的更新的进度信息，以及组件升级的状态有关 OpenShift Container Platform 部署平台（如 Amazon Web Services）以及集群所在区域的详情集群工作负载信息转换为 diset Secure Hash Algorithm（SHA）值，它允许红帽评估工作负载中的安全性和版本漏洞，而不会泄漏敏感详情如果 Operator 报告了一个问题，则会收集 openshift-* 和 kube-* 项目中 OpenShift Container Platform 核心 pod 的信息。这包括状态、资源、安全上下文、卷信息等。如需了解如何查看 Insights Operator 收集的数据，请参阅 Insights Operator 收集的数据。用户可以查看 Insights Operator 的源代码，并对代码进行贡献。如需 Insights Operator 收集的项目列表，请参阅 Insights Operator 上游项目。

4.1.3. 了解 Telemetry 和 Insights Operator 数据流

Telemeter Client 从 Prometheus API 收集所选的时间序列数据。时间序列数据每 4 分 30 秒上传到 api.openshift.com 进行处理。 Insights Operator 从 Kubernetes API 和 Prometheus API 中收集所选的数据并进行存档。该归档会每两小时上传到 console.redhat.com 进行处理。Insights Operator 还从 console.redhat.com 下载最新的 Insights 分析。这用于填充 OpenShift Container Platform Web 控制台的 Overview 页面中包含的 Insights status 。所有与红帽的通信都使用传输层安全（TLS）和 mutual 证书验证通过加密频道进行。所有数据在传输及非活跃的情况下都会被加密。对处理客户数据的系统是通过多因素验证和严格的授权控制来控制的。访问权限的设置是基于需要的，仅限于针对需要的操作。

telemetry 和 Insights Operator 数据流

如需有关 OpenShift Container Platform 监控堆栈的更多信息，请参阅监控概述。如需有关配置防火墙，以及为 Telemetry 和 Insights 启用端点的详情，请参阅配置防火墙

4.1.4. 有关如何使用远程健康监控数据的更多详情

Telemetry 收集的信息和 Insights Operator 收集的信息中提供了与启用健康检查健康相关的数据收集的信息。如本文档前面部分所述，红帽会收集您使用红帽产品的数据，如提供支持和升级、优化性能或配置、减小服务影响、识别和补救威胁、故障排除、改进提供和用户体验、响应问题、根据情况提供账单目的。红帽采用一些技术和机构措施来保护遥测数据和配置数据。红帽可以在红帽内部通过 Telemetry 和 Insights Operator 共享收集的数据，以提升您的用户体验。红帽可能会以汇总的方式与业务合作伙伴共享遥测和配置数据，该表格可帮助合作伙伴更好地了解其业务及其客户对红帽产品的使用，或者确保成功整合这些合作伙伴支持的产品。红帽可能会与某些第三方合作，协助收集、分析和存储遥测和配置数据。

用户控制/启用和禁用遥测和配置数据收集

您可以按照不使用远程健康报告中的说明禁用 OpenShift Container Platform Telemetry 和 Insights Operator。

4.2. 显示远程健康监控收集的数据

作为管理员，您可以查看 Telemetry 和 Insights Operator 收集的指标。

4.2.1. 显示 Telemetry 收集的数据

您可以查看 Telemetry 收集的集群和组件的时间序列数据。安装 OpenShift CLI（ oc ）。您必须使用具有 cluster-admin 角色或 cluster-monitoring-view 角色的用户登录集群。找到在 OpenShift Container Platform 集群中运行的 Prometheus 服务的 URL：

$ oc get route prometheus-k8s -n openshift-monitoring -o jsonpath="{.spec.host}"

访问此 URL。在 Expression 中输入查询条件并点 Execute ：

{__name__=~"cluster:usage:.*|count:up0|count:up1|cluster_version|cluster_version_available_updates|cluster_operator_up|cluster_operator_conditions|cluster_version_payload|cluster_installer|cluster_infrastructure_provider|cluster_feature_set|instance:etcd_object_counts:sum|ALERTS|code:apiserver_request_total:rate:sum|cluster:capacity_cpu_cores:sum|cluster:capacity_memory_bytes:sum|cluster:cpu_usage_cores:sum|cluster:memory_usage_bytes:sum|openshift:cpu_usage_cores:sum|openshift:memory_usage_bytes:sum|workload:cpu_usage_cores:sum|workload:memory_usage_bytes:sum|cluster:virt_platform_nodes:sum|cluster:node_instance_type_count:sum|cnv:vmi_status_running:count|node_role_os_version_machine:cpu_capacity_cores:sum|node_role_os_version_machine:cpu_capacity_sockets:sum|subscription_sync_total|csv_succeeded|csv_abnormal|ceph_cluster_total_bytes|ceph_cluster_total_used_raw_bytes|ceph_health_status|job:ceph_osd_metadata:count|job:kube_pv:count|job:ceph_pools_iops:total|job:ceph_pools_iops_bytes:total|job:ceph_versions_running:count|job:noobaa_total_unhealthy_buckets:sum|job:noobaa_bucket_count:sum|job:noobaa_total_object_count:sum|noobaa_accounts_num|noobaa_total_usage|console_url|cluster:network_attachment_definition_instances:max|cluster:network_attachment_definition_enabled_instance_up:max|insightsclient_request_send_total|cam_app_workload_migrations|cluster:apiserver_current_inflight_requests:sum:max_over_time:2m|cluster:telemetry_selected_series:count",alertstate=~"firing|"}

此查询复制 Telemetry 对正在运行的 OpenShift Container Platform 集群的 Prometheus 服务所做的请求，并返回由 Telemetry 收集的完整时间序列集。

4.2.2. 显示 Insights Operator 收集的数据

您可以查看 Insights Operator 收集的数据。使用具有 cluster-admin 角色的用户访问集群。为 Insights Operator 查找当前正在运行的 pod 的名称：

$ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

复制 Insights Operator 收集的最近数据存档：

$ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

Insights Operator 最近存档可在 insights-data 目录中找到。

4.3. 不使用远程健康报告功能

您可以选择不报告集群健康和使用情况数据。要选择不使用远程健康报告，您必须：修改全局集群 pull secret ，以禁用远程健康报告。更新集群，以使用这个修改后的 pull secret。

4.3.1. 禁用远程健康报告的后果

在 OpenShift Container Platform 中，用户可以选择不报告使用信息。但是，红帽通过连接的集群可加快对问题的反应速度，为客户提供更好支持，同时更好地了解产品升级对集群的影响。连接的集群还可帮助简化订阅和权利过程，并让 Red Hat OpenShift Cluster Manager 服务提供集群及其订阅状态概述。红帽强烈建议，即使需要在生产环境集群中禁用这个功能，在预生产环境集群和测试集群中启用健康和使用情况报告功能，。这样红帽便可在您的环境中参与对 OpenShift Container Platform 质量的审核，并对产品问题做出更快反应。选择不使用连接的集群的一些后果包括：如果没有提交问题单，红帽将无法监控产品升级是否成功，以及您的集群的健康状况。红帽将无法使用配置数据来更好地分类客户问题单，无法识别客户认为比较重要的配置。 Red Hat OpenShift Cluster Manager 将无法显示您的集群数据，包括健康和使用情况信息。没有自动使用情况报告功能，您必须通过 console.redhat.com 手动输入您的订阅授权信息。即使在受限网络中，Telemetry 和 Insights 数据仍可通过正确配置代理来报告。

4.3.2. 修改全局集群 pull secret，以禁用远程健康报告

您可以修改现有全局集群 pull secret，以禁用远程健康报告。该操作将同时禁用 Telemetry 和 Insights Operator。您可以使用具有 cluster-admin 角色的用户访问集群。把全局集群 pull secret 下载到本地文件系统。

$ oc extract secret/pull-secret -n openshift-config --to=.

在文本编辑器中编辑所下载的


       .dockerconfigjson

文件。删除


       cloud.openshift.com

JSON 条目，如：

"cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}

保存该文件。现在，您可以更新集群，使用修改后的 pull secret。

4.3.3. 更新全局集群 pull secret

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。当用户使用单独的 registry 存储镜像而不使用安装过程中的 registry时，需要这个过程。您可以使用具有 cluster-admin 角色的用户访问集群。可选：要将新的 pull secret 附加到现有 pull secret 中，请完成以下步骤：输入以下命令下载 pull secret：

$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

1

提供 pull secret 文件的路径。输入以下命令来添加新 pull secret：

$ oc registry login --registry="<registry>" \ 1
--auth-basic="<username>:<password>" \ 2
--to=<pull_secret_location> 3

1

提供新的 registry。您可以在同一个 registry 中包含多个软件仓库，例如：


              --registry="<registry/my-namespace/my-repository>"

。提供新 registry 的凭据。提供 pull secret 文件的路径。另外，您可以对 pull secret 文件执行手动更新。输入以下命令为您的集群更新全局 pull secret：

$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

1: 提供新 pull secret 文件的路径。该更新将推广至所有节点，可能需要一些时间，具体取决于集群大小。从 OpenShift Container Platform 4.7.4 开始，对全局 pull secret 的更改不再触发节点排空或重启。

4.4. 使用 Insights 发现集群中的问题

Insights 会反复分析 Insights Operator 发送的数据。OpenShift Container Platform 用户可以在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中显示报告。

4.4.1. 关于 OpenShift Container Platform 的 Red Hat Insights Advisor

您可以使用 Insights Advisor 来评估和监控 OpenShift Container Platform 集群的健康状态。无论您是关注单个集群还是与整个基础架构相关，都必须了解对您可能会影响服务可用性、容错、性能或安全性的问题。 Insights 会重复使用一个建议的数据库来重复分析 Insights Operator 发送的数据，这是会使 OpenShift Container Platform 集群处于风险状态的条件集。然后，您的数据将上传到 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务，您可以执行以下操作：请参阅受特定建议影响的集群。使用可靠的过滤功能，将结果优化为这些建议。了解更多有关单独建议、了解它们存在的风险的详细信息，并针对您的单个集群量身定制解决方案。与其他利益相关者分享结果。

4.4.2. 了解 Insights Advisor 建议

深入了解顾问捆绑包信息，它们可能对集群的服务可用性、容错、性能或安全性造成负面影响。这些信息集在 Insights Advisor 中称为建议，并包含以下信息： Name： 有关建议的简要描述 Added: 在将建议发布到 Insights Advisor 归档时 Category: 问题是否有可能对服务可用性、容错、性能或安全性造成负面影响 Total risk: 从条件对基础架构造成负面影响的 可能性 派生的值，以及发生以下情况时对操作的影响 Clusters： 检测到建议的集群列表 Description： 这个问题的简要概要，包括它对您的集群的影响 Link to associated topics: 红帽的相关信息

4.4.3. 显示集群中的潜在问题

本节论述了如何在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 中显示 Insights 报告。请注意，Insights 会重复分析您的集群并显示最新结果。这些结果可能会改变，如您解决了一个问题，或发现了一个新问题时。您的集群已在 Red Hat Hybrid Cloud Console 中注册。启用了远程健康报告（这是默认设置）。登录到 Red Hat Hybrid Cloud Console 。进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations 。根据结果，Insights Advisor 会显示以下之一：如果 Insights 没有发现任何问题，则 不会找到匹配的建议 。 Insights 检测到的问题列表，按风险分组（低、中、重要和严重）。 No clusters yet ，如果 Insights 还没有分析集群。这个分析会在集群安装、注册并连接到互联网后立即开始。如果显示任何问题，请点击条目前面的 > 图标以了解更多详情。根据具体问题，详细信息还可以包含来自红帽有关此问题的更多信息的链接。

4.4.4. 显示所有 Insights Advisor 建议

默认情况下，Recommendations 视图仅显示集群中检测到的建议。但是，您可以查看 advisor 归档中的所有建议。启用了远程健康报告（这是默认设置）。集群在 Red Hat Hybrid Cloud Console 注册。登录到 Red Hat Hybrid Cloud Console 。进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations 。点 Clusters Impacted 和 Status 过滤器旁边的 X 图标。现在，您可以浏览集群的所有潜在建议。

4.4.5. 禁用 Insights Advisor 建议

您可以禁用影响集群的具体建议，以便它们不再出现在报告中。可以禁用单个集群或所有集群的建议。禁用对所有集群的建议也适用于所有集群。启用了远程健康报告（这是默认设置）。您的集群已在 Red Hat Hybrid Cloud Console 中注册。登录到 Red Hat Hybrid Cloud Console 。进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations 。点要禁用的建议名称。您会被定向到单一推荐页面。禁用单个集群的建议：点击该集群的 Options 菜单，然后点 Disable recommendations for cluster 。输入说明并单击保存。禁用所有集群的建议：点 Actions → Disable recommendations 。输入说明并单击保存。

4.4.6. 启用之前禁用的 Insights Advisor 建议

当所有集群都禁用了一个建议时，您将不再看到 Insights Advisor 中的建议。您可以更改此行为。启用了远程健康报告（这是默认设置）。您的集群已在 Red Hat Hybrid Cloud Console 中注册。登录到 Red Hat Hybrid Cloud Console 。进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations 。按 Status → Disabled 过滤建议。找到启用的建议。点击 Options 菜单，然后点 Enable recommendations 。

4.4.7. 在 web 控制台中显示 Insights 状态

Insights 会重复分析您的集群，可以在 OpenShift Container Platform web 控制台中显示已识别的集群潜在问题的状态。此状态显示不同类别中的问题数量，以及 OpenShift Cluster Manager 报告的链接。集群在 OpenShift Cluster Manager 中注册。启用了远程健康报告（这是默认设置）。已登陆到 OpenShift Container Platform Web 控制台。在 OpenShift Container Platform Web 控制台中进入 Home → Overview 。点 Status 卡上的 Insights 。弹出窗口列出了按风险分组的潜在问题。点击独立类别或 查看 Insights Advisor 中的所有建议 ，以显示更多详情。

4.5. 使用 Insights Operator

Insights Operator 会定期收集配置和组件故障状态信息，默每两小时向红帽报告这些数据。这些信息可让红帽评估配置，它提供了比 Telemetry 报告更深入的数据。OpenShift Container Platform 用户可以在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中显示报告。 Insights Operator 被默认安装并启用。如果您需要选择不使用远程健康报告，请参阅不使用远程健康报告。有关使用 Insights Advisor 发现集群中的问题的更多信息，请参阅使用 Insights 识别集群中的问题。

4.5.1. 下载 Insights Operator 存档

Insights Operator 将收集的数据存储在集群的 openshift-insights 命名空间中的存档中。您可以下载并查看 Insights Operator 收集的数据。使用具有 cluster-admin 角色的用户访问集群。为 Insights Operator 查找正在运行的 pod 的名称：

$ oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running

复制 Insights Operator 收集的最近数据存档：

$ oc cp openshift-insights/<insights_operator_pod_name>:/var/lib/insights-operator ./insights-data 1

1: 将 <insights_operator_pod_name> 替换为上一命令中的 pod 名称输出。 Insights Operator 最近存档可在 insights-data 目录中找到。

4.5.2. 查看 Insights Operator 收集持续时间

您可以查看 Insights Operator 收集存档中包含的信息所使用的时间。这有助于您了解 Insights Operator 资源使用情况和 Insights Advisor 的问题。 Insights Operator 归档的最新副本。在归档中，打开 /insights-operator/gathers.json 。文件包含 Insights Operator 收集操作列表： "name": "clusterconfig/authentication", "duration_in_ms": 730, 1 "records_count": 1, "errors": null, "panic": null duration_in_ms 是每个收集操作的时间（毫秒）。检查每个收集操作是否有异常情况。

4.6. 在受限网络中使用远程健康报告

您可以手动收集和上传 Insights Operator 存档，以便从受限网络中诊断问题。要在受限网络中使用 Insights Operator，您必须：创建 Insights Operator 归档的副本。将 Insights Operator 存档上传到 console.redhat.com 。另外，您可以选择在上传前模糊处理 Insights Operator 数据。

4.6.1. 运行 Insights Operator 收集操作

您必须运行收集操作来创建 Insights Operator 存档。以 cluster-admin 用户身份登录 OpenShift Container Platform。使用此模板创建名为 gather-job.yaml 的文件：

apiVersion: batch/v1
kind: Job
metadata:
  name: insights-operator-job
  annotations:
    config.openshift.io/inject-proxy: insights-operator
spec:
  backoffLimit: 6
  ttlSecondsAfterFinished: 600
  template:
    spec:
      restartPolicy: OnFailure
      serviceAccountName: operator
      nodeSelector:
        beta.kubernetes.io/os: linux
        node-role.kubernetes.io/master: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 900
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 900
      volumes:
      - name: snapshots
        emptyDir: {}
      - name: service-ca-bundle
        configMap:
          name: service-ca-bundle
          optional: true
      initContainers:
      - name: insights-operator
        image: quay.io/openshift/origin-insights-operator:latest
        terminationMessagePolicy: FallbackToLogsOnError
        volumeMounts:
        - name: snapshots
          mountPath: /var/lib/insights-operator
        - name: service-ca-bundle
          mountPath: /var/run/configmaps/service-ca-bundle
          readOnly: true
        ports:
        - containerPort: 8443
          name: https
        resources:
          requests:
            cpu: 10m
            memory: 70Mi
        args:
        - gather
        - -v=4
        - --config=/etc/insights-operator/server.yaml
      containers:
        - name: sleepy
          image: quay.io/openshift/origin-base:latest
          args:
            - /bin/sh
            - sleep 10m
          volumeMounts: [{name: snapshots, mountPath: /var/lib/insights-operator}]

复制 insights-operator 镜像版本：

$ oc get -n openshift-insights deployment insights-operator -o yaml

将您的镜像版本粘贴到 gather-job.yaml 中：

initContainers:
      - name: insights-operator
        image: <your_insights_operator_image_version>
        terminationMessagePolicy: FallbackToLogsOnError
        volumeMounts:

创建收集作业：

$ oc apply -n openshift-insights -f gather-job.yaml

查找作业 pod 的名称：

$ oc describe -n openshift-insights job/insights-operator-job

输出示例

Events:
  Type    Reason            Age    From            Message
  ----    ------            ----   ----            -------
  Normal  SuccessfulCreate  7m18s  job-controller  Created pod: insights-operator-job-<your_job>

其中


        insights-operator-job-
        
         
          <your_job>

是 pod 的名称。验证操作是否已完成：

$ oc logs -n openshift-insights insights-operator-job-<your_job> insights-operator

输出示例

I0407 11:55:38.192084       1 diskrecorder.go:34] Wrote 108 records to disk in 33ms

保存创建的归档：

$ oc cp openshift-insights/insights-operator-job-<your_job>:/var/lib/insights-operator ./insights-data

清理作业：

$ oc delete -n openshift-insights job insights-operator-job

4.6.2. 上传 Insights Operator 存档

您可以将 Insights Operator 存档手动上传到 console.redhat.com ，以诊断潜在的问题。以 cluster-admin 用户身份登录 OpenShift Container Platform。您有一个没有互联网访问限制的工作站。您已创建了 Insights Operator 归档的副本。下载 dockerconfig.json 文件：

$ oc extract secret/pull-secret -n openshift-config --to=.

复制来自 dockerconfig.json 文件的 "cloud.openshift.com" "auth" 令牌： "auths": { "cloud.openshift.com": { "auth": " <your_token> ", "email": "[email protected]" 将存档上传到 console.redhat.com ：

$ curl -v -H "User-Agent: insights-operator/one10time200gather184a34f6a168926d93c330 cluster/<cluster_id>" -H "Authorization: Bearer <your_token>" -F "upload=@<path_to_archive>; type=application/vnd.redhat.openshift.periodic+tar" https://console.redhat.com/api/ingress/v1/upload

其中 <cluster_id> 是集群 ID， <your_token> 是来自 pull secret 的令牌， <path_to_archive> 是 Insights Operator 归档的路径。如果操作成功，该命令会返回 "request_id" 和 "account_number" ：

* Connection #0 to host console.redhat.com left intact
{"request_id":"393a7cf1093e434ea8dd4ab3eb28884c","upload":{"account_number":"6274079"}}%

登录到 https://console.redhat.com/openshift 。点左侧面板中的 Cluster 菜单。要显示集群详情，点集群名称。打开集群的 Insights Advisor 选项卡。如果上传成功，标签会显示以下之一：如果 Insights Advisor 没有发现任何问题，代表 您的集群已通过了所有建议 。 Insights Advisor 检测到的问题列表，按风险级别排列（低、中、重要和严重）。

4.6.3. 启用 Insights Operator 数据模糊处理

您可以启用模糊处理，以屏蔽敏感、可识别的 IPv4 地址以及 Insights Operator 发送到 console.redhat.com 的集群基础域。虽然此功能可用，但红帽建议禁用混淆以获得更有效的支持体验。模糊处理会将非标识值分配给集群 IPv4 地址，并使用保留在内存中的转换表，在将数据上传到 console.redhat.com 之前，在整个 Insights Operator 归档中将 IP 地址更改为其模糊的版本。对于集群基础域，模糊处理会将基域更改为硬编码子字符串。例如， cluster-api.openshift.example.com 变为 cluster-api.<CLUSTER_BASE_DOMAIN> 。以下流程使用 openshift-config 命名空间中的 support secret 启用混淆。以 cluster-admin 用户身份登录到 OpenShift Container Platform Web 控制台。导航到 Workloads → Secrets 。选择 openshift-config 项目。使用 Search by name 字段搜索 support secret。如果不存在，请点击 Create → Key/value secret 创建它。点击 Options 菜单，然后点 Edit Secret 。单击 Add Key/Value 。创建名为 enableGlobalObfuscation 的键，值为 true ，然后点 Save 。进入 Workloads → Pods 选择 openshift-insights 项目。查找 insights-operator pod。要重启 insights-operator pod，点 Options 菜单，然后点 Delete Pod 。导航到 Workloads → Secrets 。选择 openshift-insights 项目。使用 Search by name 字段搜索 obfuscat ion-translation-table secret。如果 obfuscat ion-translation-table secret 存在，则启用混淆并正常工作。或者，您可以在 Insights Operator 存档中检查 /insights-operator/gathers.json 的值 "is_global_obfuscation_enabled": true 。如需有关如何下载 Insights Operator 存档的更多信息，请参阅显示 Insights Operator 收集的数据。

第 5 章收集集群数据

在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。建议您提供：使用 oc adm must-gather 命令收集的数据唯一的集群 ID

5.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息，包括：默认情况下， oc adm must-gather 命令使用默认的插件镜像，并写入 ./must-gather.local 。另外，您可以使用适当的参数运行命令来收集具体信息，如以下部分所述：要收集与一个或多个特定功能相关的数据，请使用 --image 参数和镜像，如以下部分所述。

$ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.9.0

要收集审计日志，请使用 -- /usr/bin/gather_audit_logs 参数，如以下部分所述。

$ oc adm must-gather -- /usr/bin/gather_audit_logs

注意

作为默认信息集合的一部分，不会收集审计日志来减小文件的大小。当您运行 oc adm must-gather 时，集群的新项目中会创建一个带有随机名称的新 pod。在该 pod 上收集数据，并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

5.1.1. 为红帽支持收集您的集群数据

您可使用 oc adm must-gather CLI 命令收集有关您的集群的调试信息。使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift Container Platform CLI ( oc )。进入存储 must-gather 数据的目录。如果集群使用受限网络，则需要执行额外的步骤。如果您镜像的容器镜像仓库有一个信任的 CA，您必须首先将这个信任的 CA 添加到集群中。对于受限网络中的所有集群，您必须导入默认的 must-gather 镜像作为镜像流。

$ oc import-image is/must-gather -n openshift

运行 oc adm must-gather 命令：

$ oc adm must-gather

注意

因为这个命令会默认会选择一个随机 control plane 节点，所以 pod 可能会被调度到处于 NotReady 和 SchedulingDisabled 状态的 control plane 节点。如果此命令失败，例如，您无法在集群中调度 pod，则使用 oc adm inspect 命令来收集特定资源的信息。请联络红帽支持以获取推荐收集的资源信息。从刚刚在您的工作目录中创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

1: 务必将 must-gather-local.5421342344627712289/ 替换为实际目录名称。在红帽客户门户中为您的问题单附上压缩文件。

5.1.2. 收集有关特定功能的数据

您可通过将 oc adm must-gather CLI 命令与 --image 或 --image-stream 参数结合使用来收集有关特定功能的调试信息。 must-gather 工具支持多个镜像，这样您便可通过运行单个命令收集多个功能的数据。

Image 目的

registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.8.7 OpenShift Virtualization 的数据收集。 registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8 OpenShift Serverless 的数据收集。 registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8 Red Hat OpenShift Service Mesh 的数据收集。 registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7 MTC 的数据收集。 registry.redhat.io/ocs4/ocs-must-gather-rhel8 Red Hat OpenShift Container Storage 的数据收集。 registry.redhat.io/openshift-logging/cluster-logging-rhel8-operator OpenShift Logging 的数据收集。 registry.redhat.io/openshift4/ose-local-storage-mustgather-rhel8 Local Storage Operator 的数据收集。要收集除特定功能数据外的默认 must-gather 数据，请添加 --image-stream=openshift/must-gather 参数。使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift Container Platform CLI ( oc )。进入存储 must-gather 数据的目录。使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。例如，使用以下命令可收集默认集群数据和 OpenShift Virtualization 特定信息：

$ oc adm must-gather \
 --image-stream=openshift/must-gather \ 1
 --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.8.7 2

1

默认 OpenShift Container Platform


              must-gather

镜像 OpenShift Virtualization 的 must-gather 镜像您可以将


              must-gather

工具与额外参数搭配使用，以收集集群中与 OpenShift Logging 和 Red Hat OpenShift Logging Operator 相关的数据。对于 OpenShift Logging，运行以下命令：

$ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
 -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

例 5.1. OpenShift Logging 的 must-gather 输出示例

├── cluster-logging
│  ├── clo
│  │  ├── cluster-logging-operator-74dd5994f-6ttgt
│  │  ├── clusterlogforwarder_cr
│  │  ├── cr
│  │  ├── csv
│  │  ├── deployment
│  │  └── logforwarding_cr
│  ├── collector
│  │  ├── fluentd-2tr64
│  ├── eo
│  │  ├── csv
│  │  ├── deployment
│  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
│  ├── es
│  │  ├── cluster-elasticsearch
│  │  │  ├── aliases
│  │  │  ├── health
│  │  │  ├── indices
│  │  │  ├── latest_documents.json
│  │  │  ├── nodes
│  │  │  ├── nodes_stats.json
│  │  │  └── thread_pool
│  │  ├── cr
│  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
│  │  └── logs
│  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
│  ├── install
│  │  ├── co_logs
│  │  ├── install_plan
│  │  ├── olmo_logs
│  │  └── subscription
│  └── kibana
│     ├── cr
│     ├── kibana-9d69668d4-2rkvz
├── cluster-scoped-resources
│  └── core
│     ├── nodes
│     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
│     └── persistentvolumes
│        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
├── event-filter.html
├── gather-debug.log
└── namespaces
   ├── openshift-logging
   │  ├── apps
   │  │  ├── daemonsets.yaml
   │  │  ├── deployments.yaml
   │  │  ├── replicasets.yaml
   │  │  └── statefulsets.yaml
   │  ├── batch
   │  │  ├── cronjobs.yaml
   │  │  └── jobs.yaml
   │  ├── core
   │  │  ├── configmaps.yaml
   │  │  ├── endpoints.yaml
   │  │  ├── events
   │  │  │  ├── elasticsearch-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
   │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
   │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
   │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
   │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
   │  │  │  ├── elasticsearch-im-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
   │  │  ├── events.yaml
   │  │  ├── persistentvolumeclaims.yaml
   │  │  ├── pods.yaml
   │  │  ├── replicationcontrollers.yaml
   │  │  ├── secrets.yaml
   │  │  └── services.yaml
   │  ├── openshift-logging.yaml
   │  ├── pods
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  │  ├── cluster-logging-operator
   │  │  │  │  └── cluster-logging-operator
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
   │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
   │  │  │  ├── cluster-logging-operator-registry
   │  │  │  │  └── cluster-logging-operator-registry
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
   │  │  │  └── mutate-csv-and-generate-sqlite-db
   │  │  │     └── mutate-csv-and-generate-sqlite-db
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  │  ├── elasticsearch-im-app-1596030300-bpgcx
   │  │  │  ├── elasticsearch-im-app-1596030300-bpgcx.yaml
   │  │  │  └── indexmanagement
   │  │  │     └── indexmanagement
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── fluentd-2tr64
   │  │  │  ├── fluentd
   │  │  │  │  └── fluentd
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── fluentd-2tr64.yaml
   │  │  │  └── fluentd-init
   │  │  │     └── fluentd-init
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── kibana-9d69668d4-2rkvz
   │  │  │  ├── kibana
   │  │  │  │  └── kibana
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
   │  │  │  └── kibana-proxy
   │  │  │     └── kibana-proxy
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  └── route.openshift.io
   │     └── routes.yaml
   └── openshift-operators-redhat
      ├── ...

使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。例如，使用以下命令可收集默认集群数据和 KubeVirt 特定信息：

$ oc adm must-gather \
 --image-stream=openshift/must-gather \ 1
 --image=quay.io/kubevirt/must-gather 2

1

默认 OpenShift Container Platform


                   must-gather

镜像 KubeVirt 的 must-gather 镜像从工作目录中刚刚创建的


                   must-gather

目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

1: 务必将 must-gather-local.5421342344627712289/ 替换为实际目录名称。在红帽客户门户中为您的问题单附上压缩文件。

5.1.3. 收集审计日志

您可以收集审计日志，它们是与安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。您可以收集以下的审计日志： etcd 服务器 Kubernetes API 服务器 OpenShift OAuth API 服务器 OpenShift API 服务器使用 -- /usr/bin/gather_audit_logs 标志运行 oc adm must-gather 命令：

$ oc adm must-gather -- /usr/bin/gather_audit_logs

从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

$ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

1: 将 must-gather-local.472290403699006248 替换为实际目录名称。在红帽客户门户中为您的问题单附上压缩文件。

5.2. 获取集群 ID

在向红帽支持提供信息时，提供集群的唯一标识符会很有帮助。您可以使用 OpenShift Container Platform Web 控制台自动填充集群 ID。您还可以使用 web 控制台或 OpenShift CLI（ oc ）手工获取集群 ID。使用具有 cluster-admin 角色的用户访问集群。访问安装的 web 控制台或 OpenShift CLI（ oc ）。使用 Web 控制台开支持问题单并自动填充集群 ID：从工具栏导航至 （？） help → Open Support Case 。 Cluster ID 的值会被自动填充。使用 web 控制台手动获取集群 ID：导航到 Home → Dashboards → Overview 。该值包括在 Details 中的 Cluster ID 项中。要使用 OpenShift CLI（ oc ）获取集群 ID，请运行以下命令：

$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'

5.3. 关于 sosreport

sosreport 是一个从 Red Hat Enterprise Linux((RHEL)和 Red Hat Enterprise Linux CoreOS(RHCOS)系统收集配置详情、系统信息和诊断数据的工具。 sosreport 提供了一种标准的方法来收集有关节点的诊断信息,然后可以提供给红帽支持以进行诊断。在一些情况下，红帽支持可能会要求您为特定 OpenShift Container Platform 节点收集 sosreport 归档。例如，有时可能需要查看系统日志或其他没有包括在 oc adm must-gather 输出的针对于节点的特定数据。

5.4. 为 OpenShift Container Platform 集群节点生成 sosreport 归档

为 OpenShift Container Platform 4.8 集群节点生成 sosreport 的建议方法是通过 debug pod。您可以使用具有 cluster-admin 角色的用户访问集群。您需要有到主机的 SSH 访问权限。已安装 OpenShift CLI（ oc ）。您有红帽标准订阅或高级订阅。您有红帽客户门户网站帐户。您已有一个红帽支持问题单 ID。获取集群节点列表：

$ oc get nodes

在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

$ oc debug node/my-cluster-node

要在目标节点上进入带有 NoExecute 效果的 debug 会话，请向 dummy 命名空间添加一个容限，并在 dummy 命名空间中启动 debug pod：

$ oc new-project dummy

$ oc patch namespace dummy --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

$ oc debug node/my-cluster-node

将 /host 设置为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host ，您可以运行主机可执行路径中包含的二进制文件：

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。启动 toolbox 容器，其中包括运行 sosreport 所需的二进制文件和插件：

# toolbox

注意

如果一个已存在的 toolbox pod 已在运行，则 toolbox 命令会输出 'toolbox-' already exists.Trying to start… .使用 podman rm toolbox- 删除正在运行的 toolbox容器，并生成新的 toolbox 容器以避免 sosreport 插件出现问题。收集 sosreport 归档。运行 sosreport 命令并启用 crio.all 和 crio.logs CRI-O 容器引擎 sosreport 插件：

# sosreport -k crio.all=on -k crio.logs=on 1

1

-k

可让您在默认值之外定义


                    sosreport

插件参数。提示后按 Enter 键继续。提供红帽支持问题单 ID。


                    sosreport

将 ID 添加到存档的文件名中。


                    sosreport

输出提供了归档的位置和 checksum。以下示例输出引用支持问题单 ID

01234567

Your sosreport has been generated and saved in:
  /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz 1
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

1


                        sosreport

归档的文件路径在


                        chroot

环境之外，因为 toolbox 容器会在


                        /host

挂载主机的根目录。使用以下方法之一为红帽支持提供


                        sosreport

归档以供分析。将文件直接从 OpenShift Container Platform 集群上传到现有红帽支持问题单。在 toolbox 容器内，运行


                        redhat-support-tool

将存档直接附加到现有红帽支持问题单中。这个示例使用问题单 ID

01234567

# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-sosreport.tar.xz 1

1

toolbox 容器将主机的根目录挂载到


                            /host

。当指定要通过


                            redhat-support-tool

命令上传的文件时，使用 toolbox 容器的根目录（包括


                            /host/

）的绝对路径。将文件上传到现有红帽支持问题单中。运行


                            oc debug node/<node_name>

命令调整


                            sosreport

归档，并将输出重定向到文件中。此命令假设您已退出以前的


                            oc debug

会话：

$ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz 1

1: debug 容器将主机的根目录挂载到 /host 。在指定用于连接的目标文件时，引用 debug 容器的根目录的绝对路径，包括 /host 。运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 scp 从集群节点传输 sosreport 归档，这会使节点出现 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以通过运行 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> 从节点复制 sosreport 归档文件。进入 https://access.redhat.com/support/cases/ 中的现有支持问题单。选择 Attach files 并按提示上传该文件。

5.5. 查询 bootstrap 节点日志

如果遇到与 bootstrap 相关的问题，可以从 bootstrap 节点收集 bootkube.service journald 单元日志和容器日志。具有到 bootstrap 节点的 SSH 访问权限。具有 bootstrap 节点的完全限定域名。在 OpenShift Container Platform 安装过程中，查询 bootstrap 节点的 bootkube.service journald 单元日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

注意

bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点（也称为 master 节点）上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。使用 bootstrap 节点上的 podman 从 bootstrap 节点容器收集日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

5.6. 查询集群节点 journal 日志

您可以在独立集群节点的 /var/log 中收集 journald 单元日志和其他日志。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。查询 OpenShift Container Platform 集群节点的 kubelet journald 单元日志。以下示例仅查询 control plane 节点（也称为 master 节点）：

$ oc adm node-logs --role=master -u kubelet  1

1

根据情况替换


               kubelet

以查询其他单元日志。从集群节点上


               /var/log/

下的特定子目录收集日志。获取


               /var/log/

子目录中所含的日志列表。以下示例列出所有 control plane 节点上的


               /var/log/openshift-apiserver/

中的文件：

$ oc adm node-logs --role=master --path=openshift-apiserver

检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

$ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

5.7. 从 OpenShift Container Platform 节点或容器收集网络追踪（trace）

在调查与网络相关的 OpenShift Container Platform 问题时，红帽可能会从特定的 OpenShift Container Platform 集群节点或从特定容器请求网络数据包追踪。在 OpenShift Container Platform 中捕获网络 trace 的建议方法是通过 debug pod。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您有红帽标准订阅或高级订阅。您有红帽客户门户网站帐户。您已有一个红帽支持问题单 ID。您需要有到主机的 SSH 访问权限。获取集群节点列表：

$ oc get nodes

在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

$ oc debug node/my-cluster-node

将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host ，您可以运行主机可执行路径中包含的二进制文件：

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。在 chroot 环境控制台中获取节点接口名称：

# ip ad

启动 toolbox 容器，其中包括运行 sosreport 所需的二进制文件和插件：

# toolbox

注意

如果一个已存在的 toolbox pod 已在运行，则 toolbox 命令会输出 'toolbox-' already exists.Trying to start… .要避免 tcpdump 出现问题，请使用 podman rm toolbox- 删除正在运行的 toolbox 容器，并生成新 toolbox 容器。在集群节点中启动 tcpdump 会话，并将输出重定向到捕获文件中。这个示例使用 ens5 作为接口名称：

$ tcpdump -nn -s 0 -i ens5 -w /host/var/tmp/my-cluster-node_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap  1

1


                  tcpdump

捕获文件路径在


                  chroot

环境之外，因为 toolbox 容器会在


                  /host

中挂载主机的根目录。如果节点上的特定容器需要


                  tcpdump

捕获，请按照以下步骤操作。确定目标容器 ID。


                  chroot host

命令先于这一步中的


                  crictl

命令，因为 toolbox 容器在


                  /host

中挂载主机的根目录：

# chroot /host crictl ps

确定容器的进程 ID。在本例中，容器 ID 是 a7fe32346b120 :

# chroot /host crictl inspect --output yaml a7fe32346b120 | grep 'pid' | awk '{print $2}'

在容器上启动 tcpdump 会话，并将输出重定向到捕获文件中。本例使用 49628 作为容器的进程 ID， ens5 是接口名称。 nsenter 命令进入目标进程的命名空间并在命名空间中运行命令。因为本例中的目标进程是一个容器的进程 ID， tcpdump 命令从主机在容器的命名空间中运行：

# nsenter -n -t 49628 -- tcpdump -nn -i ens5 -w /host/var/tmp/my-cluster-node-my-container_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap.pcap  1

1


                tcpdump

捕获文件路径在


                chroot

环境之外，因为 toolbox 容器会在


                /host

中挂载主机的根目录。使用以下方法之一向红帽支持提供


                tcpdump

捕获文件进行分析。将文件直接从 OpenShift Container Platform 集群上传到现有红帽支持问题单。在 toolbox 容器内，运行


                redhat-support-tool

将该文件直接附加到现有红帽支持问题单中。这个示例使用问题单 ID

01234567

# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-tcpdump-capture-file.pcap 1

1

toolbox 容器将主机的根目录挂载到


                    /host

。当指定要通过


                    redhat-support-tool

命令上传的文件时，使用 toolbox 容器的根目录（包括


                    /host/

）的绝对路径。将文件上传到现有红帽支持问题单中。运行


                    oc debug node/<node_name>

命令调整


                    sosreport

归档，并将输出重定向到文件中。此命令假设您已退出以前的


                    oc debug

会话：

$ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-tcpdump-capture-file.pcap' > /tmp/my-tcpdump-capture-file.pcap 1

1: debug 容器将主机的根目录挂载到 /host 。在指定用于连接的目标文件时，引用 debug 容器的根目录的绝对路径，包括 /host 。运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 scp 从集群节点传输 tcpdump 捕获文件，这会使节点出现 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以运行 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> 从一个节点复制 tcpdump 捕获文件。进入 https://access.redhat.com/support/cases/ 中的现有支持问题单。选择 Attach files 并按提示上传该文件。

5.8. 为红帽支持提供诊断数据

在解决 OpenShift Container Platform 问题时，红帽可能会要求您将诊断数据上传到支持问题单中。文件可以通过红帽客户门户网站或使用 redhat-support-tool 命令直接从 OpenShift Container Platform 集群上传到支持问题单。您可以使用具有 cluster-admin 角色的用户访问集群。您需要有到主机的 SSH 访问权限。已安装 OpenShift CLI（ oc ）。您有红帽标准订阅或高级订阅。您有红帽客户门户网站帐户。您已有一个红帽支持问题单 ID。通过红帽客户门户网站将诊断数据上传到现有红帽支持问题单中。使用 oc debug node/<node_name> 命令调整一个 OpenShift Container Platform 节点中包含的诊断文件，并将输出重定向到文件中。以下示例将 debug 容器中的 /host/var/tmp/my-diagnostic-data.tar.gz 复制到 /var/tmp/my-diagnostic-data.tar.gz :

$ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-diagnostic-data.tar.gz' > /var/tmp/my-diagnostic-data.tar.gz 1

1

debug 容器将主机的根目录挂载到


               /host

。在指定用于连接的目标文件时，引用 debug 容器的根目录的绝对路径，包括


               /host

。运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用

scp

从集群节点传输文件，这会使节点出现 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作,

oc

操作将会受到影响。在这种情况下，可以使用


               scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>

从一个节点复制诊断文件。进入 https://access.redhat.com/support/cases/ 中的现有支持问题单。选择 Attach files 并按提示上传该文件。将诊断数据直接从 OpenShift Container Platform 集群上传到现有红帽支持问题单中。获取集群节点列表：

$ oc get nodes

在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

$ oc debug node/my-cluster-node

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。启动 toolbox 容器，其中包含运行 redhat-support-tool 所需的二进制文件：

# toolbox

注意

如果一个已存在的 toolbox pod 已在运行，则 toolbox 命令会输出 'toolbox-' already exists.Trying to start… .使用 podman rm toolbox- 删除正在运行的 toolbox 容器，并生成新的 toolbox 容器以避免出现问题。运行 redhat-support-tool 将 debug pod 的文件直接附加到现有的红帽支持问题单中。这个示例使用支持问题单 ID '01234567' 和示例文件路径 /host/var/tmp/my-diagnostic-data.tar.gz :

# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-diagnostic-data.tar.gz 1

1: toolbox 容器将主机的根目录挂载到 /host 。当指定要通过 redhat-support-tool 命令上传的文件时，使用 toolbox 容器的根目录（包括 /host/ ）的绝对路径。

5.9. 关于 `toolbox`

toolbox 是一个在 Red Hat Enterprise Linux CoreOS（RHCOS）系统上启动容器的工具。该工具主要用于启动包含运行 sosreport 和 redhat-support-tool 等命令所需的二进制文件和插件的容器。 toolbox 容器的主要目的是收集诊断信息并将其提供给红帽支持。但是，如果需要额外的诊断工具，您可以添加 RPM 软件包或运行标准支持工具镜像的替代镜像。

将软件包安装到 `toolbox` 容器

默认情况下，运行 toolbox 命令会启动带有 registry.redhat.io/rhel8/support-tools:latest 镜像的容器。该镜像包含最常用的支持工具。如果需要一个不是镜像的一部分的支持工具来收集特定于具体节点的数据，可以安装额外的软件包。已使用 oc debug node/<node_name> 命令访问节点。将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host ，您可以运行主机可执行路径中包含的二进制文件：

# chroot /host

启动 toolbox 容器：

# toolbox

安装额外的软件包，如 wget :

# dnf install -y <package_name>

使用 `toolbox` 启动备用镜像

默认情况下，运行 toolbox 命令会启动带有 registry.redhat.io/rhel8/support-tools:latest 镜像的容器。您可以通过创建 .toolboxrc 文件并指定要运行的镜像来启动其他镜像。已使用 oc debug node/<node_name> 命令访问节点。将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host ，您可以运行主机可执行路径中包含的二进制文件：

# chroot /host

在 root 用户的主目录中，创建一个 .toolboxrc 文件：

# vi ~/.toolboxrc

REGISTRY=quay.io                1
IMAGE=fedora/fedora:33-x86_64   2
TOOLBOX_NAME=toolbox-fedora-33  3

1

可选：指定替代容器 registry。指定要启动的替代镜像。可选：指定 toolbox 容器的替代名称。使用备用镜像启动 toolbox 容器：

# toolbox

注意

第 6 章集群规格总结

6.1. 通过 `clusterversion` 总结集群规格

您可以通过查询 clusterversion 资源来获取一个 OpenShift Container Platform 集群规格的总结数据。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。查询集群版本、可用性、运行时间以及常规状态：

$ oc get clusterversion

获取集群规格、更新可用性和更新历史记录的详细概述：

$ oc describe clusterversion

第 7 章故障排除

7.1. 安装故障排除

7.1.1. 确定安装问题在哪里发生

当对 OpenShift Container Platform 安装问题进行故障排除时，可以监控安装日志来确定在哪个阶段出现问题。然后，检索与该阶段相关的诊断数据。 OpenShift Container Platform 安装过程包括以下阶段：创建 Ignition 配置文件。启动引导计算机并开始托管要启动的 control plane 机器（也称为 master 机器）所需的远程资源。 control plane 机器从 bootstrap 机器获取远程资源并完成启动。 control plane 机器使用 bootstrap 机器组成 etcd 集群。 bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。临时 control plane 将生产环境 control plane 调度到 control plane 机器。临时 control plane 关机，并将控制权交给生产环境 control plane。 bootstrap 机器将 OpenShift Container Platform 组件添加到生产环境 control plane。安装程序关闭 bootstrap 机器。 control plane 设置 worker 节点。 control plane 以一组 Operator 的形式安装其他服务。集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建 worker 机器。

7.1.2. 用户置备的基础架构安装注意事项

默认安装方法使用安装程序置备的基础架构。对于安装程序置备的基础架构的集群，OpenShift Container Platform 可以管理集群的所有方面，包括操作系统本身。若有可能，可以使用此功能来避免置备和维护集群基础架构。您也可以在自己提供的基础架构上安装 OpenShift Container Platform 4.8。如果您使用这个安装方法，请完全遵循用户置备的基础架构安装文档中的内容。另外，在安装前请考虑以下事项：查看 Red Hat Enterprise Linux（RHEL）生态系统中的内容来决定您所使用的服务器硬件或虚拟环境可以获得的 Red Hat Enterprise Linux CoreOS（RHCOS）对其支持的级别。很多虚拟化和云环境需要在客户端操作系统中安装代理。确保将这些代理作为通过守护进程集部署的容器化工作负载安装。如果要启用动态存储、按需服务路由、节点主机名到 Kubernetes 主机名解析以及集群自动扩展等功能，请安装云供应商集成。不可能在混合有不同云供应商，或跨多个物理或虚拟平台的 OpenShift Container Platform 环境中启用云供应商集成。节点生命周期控制器不允许将来自现有供应商外部的节点添加到集群中，且无法指定多个云供应商集成。如果要使用机器集或自动扩展来自动置备 OpenShift Container Platform 集群节点，则需要针对于供应商的 Machine API 实现。检查您所选云供应商是否提供了将 Ignition 配置文件注入主机的方法作为其初始部署的一部分。如果不这样做，则需要使用 HTTP 服务器托管 Ignition 配置文件。解决 Ignition 配置文件问题的步骤会因部署了这两种方法的不同而有所不同。如果要利用可选的框架组件，如嵌入式容器 registry、Elasticsearch 或 Prometheus，则需要手动置备存储。除非明确进行了配置，用户置备的基础架构安装中不定义默认存储类。在高可用性 OpenShift Container Platform 环境中，需要一个负载均衡器来在所有 control plane 节点（也称为 master 节点）之间分发 API 请求。您可以使用任何满足 OpenShift Container Platform DNS 路由和端口要求的基于 TCP 的负载平衡解决方案。

7.1.3. 在 OpenShift Container Platform 安装前检查负载均衡器配置

在开始 OpenShift Container Platform 安装前，请检查您的负载均衡器配置。已根据选择配置了外部负载均衡器，准备 OpenShift Container Platform 安装。以下示例基于使用 HAProxy 为集群提供负载均衡服务的 Red Hat Enterprise Linux（RHEL）主机。为准备 OpenShift Container Platform 安装已配置了 DNS 准备。有到负载均衡器的 SSH 访问权限。检查 haproxy systemd 服务是否活跃：

$ ssh <user_name>@<load_balancer> systemctl status haproxy

验证负载均衡器是否在监听所需端口。以下示例引用端口 80 、 443 、 6443 和 22623 。对于在 Red Hat Enterprise Linux（RHEL）6 上运行的 HAProxy 实例，请使用 netstat 命令验证端口状态：

$ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

对于在 Red Hat Enterprise Linux（RHEL）7 或 8 上运行的 HAProxy 实例，请使用 ss 命令验证端口状态：

$ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

注意

红帽建议在 Red Hat Enterprise Linux(RHEL)7 或更高版本中使用 ss 命令而不是 netstat 。 SS 由 iproute 软件包提供。有关 ss 命令的详情请参考 Red Hat Enterprise Linux（RHEL）7 性能调节指南。检查通配符 DNS 记录是否被解析为负载均衡器：

$ dig <wildcard_fqdn> @<dns_server>

7.1.4. 指定 OpenShift Container Platform 安装程序日志级别

默认情况下，OpenShift Container Platform 安装程序日志级别设置为 info 。如果在诊断失败的 OpenShift Container Platform 安装时需要更详细的日志记录，您可以在重新开始安装时将 openshift-install 日志级别提高为 debug 。有访问安装主机的访问权限。在启动安装时将安装日志级别设置为 debug :

$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete --log-level debug  1

1: 可能的日志级别包括 info 、 warn 、error 和 debug 。

7.1.5. openshift-install 命令问题故障排除

如果您在运行 openshift-install 命令时遇到问题，请检查以下内容：安装过程在 Ignition 配置文件创建后 24 小时内启动。运行以下命令时创建 Ignition 文件：

$ ./openshift-install create ignition-configs --dir=./install_dir


              install-config.yaml

文件与安装程序位于同一个目录中。如果使用


              ./openshift-install --dir

选项声明了其他不同的安装路径，请验证


              install-config.yaml

文件是否存在于该目录中。

7.1.6. 监控安装进度

您可以在 OpenShift Container Platform 安装过程中监控高级别安装、bootstrap 和 control plane 日志。这提高了安装过程的可视性，并有助于识别安装失败的阶段。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。您有 bootstrap 和 control plane 节点的完全限定域名（也称为 master 节点）。初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。在安装过程中监控安装日志：

$ tail -f ~/<installation_directory>/.openshift_install.log

在 bootstrap 节点引导后，监控 bootkube.service journald 单元日志。这可让您了解第一个 control plane 的 bootstrap。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

注意

bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。使用 oc 监控日志：

$ oc adm node-logs --role=master -u kubelet

如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

引导后，监控 control plane 节点上的 crio.service journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。使用 oc 监控日志：

$ oc adm node-logs --role=master -u crio

如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh [email protected]_name.sub_domain.domain journalctl -b -f -u crio.service

7.1.7. 收集 bootstrap 节点诊断数据

当遇到与 bootstrap 相关的问题，可以从 bootstrap 节点收集 bootkube.service journald 单元日志和容器日志。具有到 bootstrap 节点的 SSH 访问权限。具有 bootstrap 节点的完全限定域名。如果使用 HTTP 服务器托管 Ignition 配置文件，则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。如果可以访问 bootstrap 节点的控制台，请监控控制台，直到节点可以提供登录提示。验证 Ignition 文件配置。如果您使用 HTTP 服务器托管 Ignition 配置文件。验证 bootstrap 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

$ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

1

-I

选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回


                 200 OK

状态。如果没有，该命令会返回


                 404 file not found

。要验证 bootstrap 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件，请输入以下命令：

$ grep -is 'bootstrap.ign' /var/log/httpd/access_log

如果收到 bootstrap Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，这表示请求成功。如果未收到 Ignition 文件，请检查 Ignition 文件是否存在，是否在服务主机上具有适当的文件和 Web 服务器权限。如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。查看 bootstrap 节点的控制台，以确定机制是否正确注入 bootstrap 节点 Ignition 文件。验证 bootstrap 节点分配的存储设备是否可用。验证 bootstrap 节点是否已从 DHCP 服务器分配了一个 IP 地址。从 bootstrap 节点收集 bootkube.service journald 单元日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

注意

bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点（也称为 master 节点）上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。从 bootstrap 节点容器收集日志。使用 bootstrap 节点上的 podman 来收集日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

如果 bootstrap 过程失败，请验证以下内容。您可从安装主机解析 api.<cluster_name>.<base_domain> 。负载均衡器代理端口 6443 连接到 bootstrap 和 control plane 节点。确保代理配置满足 OpenShift Container Platform 安装要求。

7.1.8. 调查 control plane 节点安装问题

如果您遇到 control plane 节点（也称为 master 节点）安装问题，请确定 control plane 节点 OpenShift Container Platform 软件定义的网络 (SDN) 和网络 Operator 状态。收集 kubelet.service 、 crio.service journald 单元日志和 control plane 节点容器日志，以检查 control plane 节点代理、CRI-O 容器运行时和 pod 的情况。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。您有 bootstrap 和 control plane 节点的完全限定域名。如果使用 HTTP 服务器托管 Ignition 配置文件，则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。如果您可以访问 control plane 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。验证 Ignition 文件配置。如果您使用 HTTP 服务器托管 Ignition 配置文件。验证 control plane 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

$ curl -I http://<http_server_fqdn>:<port>/master.ign  1

1

-I

选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回


                 200 OK

状态。如果没有，该命令会返回


                 404 file not found

。要验证 control plane 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

$ grep -is 'master.ign' /var/log/httpd/access_log

如果收到 master Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。查看 control plane 节点的控制台，以确定机制是否正确注入 control plane 节点 Ignition 文件。检查分配给 control plane 节点的存储设备是否可用。验证 control plane 节点是否已从 DHCP 服务器分配了一个 IP 地址。确定 control plane 节点状态。查询 control plane 节点状态：

$ oc get nodes

如果一个 control plane 节点没有处于 Ready 状态，检索详细的节点描述：

$ oc describe node <master_node>

注意

如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令：确定 OpenShift Container Platform SDN 状态。在 openshift-sdn 命名空间内查看 sdn-controller 、 sdn 和 ovs 守护进程集的状态：

$ oc get daemonsets -n openshift-sdn

如果这些资源列为 Not found ，查看 openshift-sdn 命名空间中的 pod：

$ oc get pods -n openshift-sdn

检查 openshift-sdn 命名空间中与失败的 OpenShift Container Platform SDN pod 相关的日志：

$ oc logs <sdn_pod> -n openshift-sdn

确定集群网络配置状态。查看集群的网络配置是否存在：

$ oc get network.config.openshift.io cluster -o yaml

如果安装程序无法创建网络配置，请再次生成 Kubernetes 清单并查看消息输出：

$ ./openshift-install create manifests

查看 openshift-network-operator 命名空间中的 pod 状态，以确定 Cluster Network Operator（CNO）是否在运行：

$ oc get pods -n openshift-network-operator

从 openshift-network-operator 命名空间中收集网络 Operator pod 日志：

$ oc logs pod/<network_operator_pod_name> -n openshift-network-operator

引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。使用 oc 检索日志：

$ oc adm node-logs --role=master -u kubelet

如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

注意

$ oc adm node-logs --role=master -u crio

如果 API 无法正常工作，使用 SSH 来查看日志：

$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

从 control plane 节点上的 /var/log/ 下的特定子目录收集日志。获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 control plane 节点上的 /var/log/openshift-apiserver/ 中的文件：

$ oc adm node-logs --role=master --path=openshift-apiserver

检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

$ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

使用 SSH 查看 control plane 节点容器日志。列出容器：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a

使用 crictl 检索容器日志：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

如果您遇到 control plane 节点配置问题，请验证 MCO、MCO 端点和 DNS 记录是否正常工作。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

$ curl https://api-int.<cluster_name>:22623/config/master

如果端点不响应，请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。对定义的 MCO 端点名称运行 DNS 查找：

$ dig api-int.<cluster_name> @<dns_server>

在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

$ dig -x <load_balancer_mco_ip_address> @<dns_server>

验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

$ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

检查证书的有效性：

$ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

7.1.9. 解决 etcd 安装问题

如果在安装过程中遇到 etcd 问题，您可以检查 etcd pod 状态并收集 etcd pod 日志。您还可以验证 etcd DNS 记录并检查 control plane 节点上的 DNS 可用性（也称为 master 节点）。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。您有 control plane 节点的完全限定域名。检查 etcd pod 的状态。查看 openshift-etcd 命名空间中的 pod 状态：

$ oc get pods -n openshift-etcd

查看 openshift-etcd-operator 命名空间中的 pod 状态：

$ oc get pods -n openshift-etcd-operator

如果以上命令中列出的任何 pod 没有显示 Running 或 Completed 状态，请为 pod 收集诊断信息。检查 pod 的事件：

$ oc describe pod/<pod_name> -n <namespace>

检查 pod 的日志：

$ oc logs pod/<pod_name> -n <namespace>

如果 pod 有多个容器，以上命令会创建一个错误并在错误消息中提供容器名称。检查每个容器的日志：

$ oc logs pod/<pod_name> -c <container_name> -n <namespace>

如果 API 无法正常工作，请使用 SSH 来查看每个 control plane 节点上的 etcd pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。列出每个 control plane 节点上的 etcd pod：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-

对于没有显示 Ready 状态的 pod，详细检查 pod 状态。将 <pod_id> 替换为上一命令输出中列出的 pod ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>

列出与 pod 相关的容器：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

对于没有显示 Ready 状态的容器，请详细检查容器状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

检查任何未显示 Ready 状态的容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

注意

7.1.10. 调查 control plane 节点 kubelet 和 API 服务器问题

要在安装过程中调查 control plane 节点（也称为 master 节点）kubelet 和 API 服务器问题，请检查 DNS、DHCP 和负载均衡器功能。另外，请确认证书没有过期。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。您有 control plane 节点的完全限定域名。验证 API 服务器的 DNS 记录是否将 control plane 节点上的 kubelet 定向到 https://api-int.<cluster_name>.<base_domain>:6443 。确保记录引用负载均衡器。确保负载均衡器的端口 6443 定义引用每个 control plane 节点。检查 DHCP 是否提供了唯一的 control plane 节点主机名。检查每个 control plane 节点上的 kubelet.service journald 单元日志。使用 oc 检索日志：

$ oc adm node-logs --role=master -u kubelet

如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

注意

$ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

7.1.11. 调查 worker 节点安装问题

如果遇到 worker 节点安装问题，可以查看 worker 节点的状态。收集 kubelet.service 、 crio.service journald 单元日志和 worker 节点容器日志，以检查 worker 节点代理、CRI-O 容器运行时和 pod 的情况。另外，还可以检查 Ignition 文件和 Machine API Operator 是否正常工作。如果 worker 节点安装后配置失败，检查 Machine Config Operator（MCO）和 DNS 是否正常工作。您还可以验证 bootstrap、master 和 worker 节点之间的系统时钟是否同步，并验证证书。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您需要有到主机的 SSH 访问权限。您有 bootstrap 和 worker 节点的完全限定域名。如果使用 HTTP 服务器托管 Ignition 配置文件，则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。如果可以访问 worker 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。验证 Ignition 文件配置。如果您使用 HTTP 服务器托管 Ignition 配置文件。验证 worker 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

$ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

1

-I

选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回


                 200 OK

状态。如果没有，该命令会返回


                 404 file not found

。要验证 worker 节点是否收到 Ignition 文件，请查询 HTTP 主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

$ grep -is 'worker.ign' /var/log/httpd/access_log

如果收到 worker Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。查看 worker 节点的控制台，以确定机制是否正确注入 worker 节点 Ignition 文件。检查 worker 节点分配的存储设备是否可用。验证 worker 节点是否已从 DHCP 服务器分配了一个 IP 地址。确定 worker 节点状态。查询节点状态：

$ oc get nodes

获取没有显示 Ready 状态的 worker 节点的详细节点描述：

$ oc describe node <worker_node>

注意

如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令。与 control plane 节点（也称为 master 节点）不同，worker 节点使用 Machine API Operator 部署和扩展。检查 Machine API Operator 的状态。查看 Machine API Operator pod 状态：

$ oc get pods -n openshift-machine-api

如果 Machine API Operator pod 没有处于 Ready 状态，请详细列出 pod 的事件：

$ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

检查 machine-api-operator 容器日志。容器在 machine-api-operator pod 中运行：

$ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

同时检查 kube-rbac-proxy 容器日志。容器也会在 machine-api-operator pod 中运行：

$ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

引导后，监控 worker 节点上的 kubelet.service journald 单元日志。这可让您了解 worker 节点代理活动。使用 oc 检索日志：

$ oc adm node-logs --role=worker -u kubelet

如果 API 无法正常工作，使用 SSH 来查看日志。将 <worker-node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

注意

$ oc adm node-logs --role=worker -u crio

如果 API 无法正常工作，使用 SSH 来查看日志：

$ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

从 worker 节点上的 /var/log/ 下的特定子目录收集日志。获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 worker 节点上 /var/log/sssd/ 中的文件：

$ oc adm node-logs --role=worker --path=sssd

检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 worker 节点的 /var/log/sssd/audit.log 内容：

$ oc adm node-logs --role=worker --path=sssd/sssd.log

如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例显示 /var/log/sssd/sssd.log 的尾部信息：

$ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

使用 SSH 查看 worker 节点容器日志。列出容器：

$ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

使用 crictl 检索容器日志：

$ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

如果您遇到 worker 节点配置问题，检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

$ curl https://api-int.<cluster_name>:22623/config/worker

$ dig api-int.<cluster_name> @<dns_server>

在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

$ dig -x <load_balancer_mco_ip_address> @<dns_server>

验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

$ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

$ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

检查证书的有效性：

$ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

7.1.12. 安装后查询 Operator 状态

您可以在安装结束时检查 Operator 状态。检索不可用的 Operator 的诊断数据。检查所有列为 Pending 或具有错误状态的 Operator pod 的日志。验证有问题的 pod 所使用的基础镜像。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。检查安装结束时，是否所有集群 Operator 都可用。

$ oc get clusteroperators

验证所有所需的证书签名请求（CSR）是否已批准。有些节点可能无法变为 Ready 状态，且有些集群 Operator 可能无法使用（如果待处理的 CSR）。检查 CSR 的状态，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端和服务器请求：

$ oc get csr

输出示例

NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 1 csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending 2 csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending 客户端请求 CSR。服务器请求 CSR。在本例中，两台机器加入了集群。您可能会在列表中看到更多已批准的 CSR。如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准初始 CSR 后，集群的 kube-controller-manager 会自动批准后续的节点客户端 CSR。对于在未启用机器 API 的平台中运行的集群，如裸机和其他用户置备的基础架构，必须采用一种方法自动批准 kubelet 提供证书请求（CSR）。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。要单独批准，请对每个有效的 CSR 运行以下命令：

$ oc adm certificate approve <csr_name> 1

1

<csr_name> 是当前 CSR 列表中 CSR 的名称。要批准所有待处理的 CSR，请运行以下命令：

$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

查看 Operator 事件：

$ oc describe clusteroperator <operator_name>

查看 Operator 命名空间中的 Operator pod 状态：

$ oc get pods -n <operator_namespace>

获取没有处于 Running 状态的 pod 的详细描述：

$ oc describe pod/<operator_pod_name> -n <operator_namespace>

检查 pod 日志：

$ oc logs pod/<operator_pod_name> -n <operator_namespace>

遇到与 pod 基础镜像相关的问题时，请查看基础镜像状态。获取有问题的 pod 使用的基础镜像的详情：

$ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>

列出基础镜像发行信息：

$ oc adm release info <image_path>:<tag> --commits

7.1.13. 从失败安装中收集日志

如果您为安装程序提供了 SSH 密钥，则可以收集有关失败安装的数据。与从正在运行的集群收集日志相比，您可以使用其他命令收集失败安装的日志。如果必须从正在运行的集群中收集日志，请使用 oc adm must-gather 命令。在 bootstrap 过程完成前，OpenShift Container Platform 安装会失败。bootstrap 节点正在运行，并可通过 SSH 访问。 ssh-agent 进程在您的计算机上处于活跃状态，并且为 ssh-agent 进程和安装程序提供了相同的 SSH 密钥。如果尝试在您置备的基础架构上安装集群，则必须具有 bootstrap 和 control plane 节点（也称为 master 节点）的完全限定域名。生成从 bootstrap 和 control plane 机器获取安装日志的命令：如果您使用安装程序置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

$ ./openshift-install gather bootstrap --dir <installation_directory> 1

1


                 installation_directory

是您在运行时指定的目录


                 。/openshift-install create cluster

。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。对于安装程序置备的基础架构，安装程序会保存有关集群的信息，因此您不用指定主机名或 IP 地址。如果您使用您置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

$ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
    --bootstrap <bootstrap_address> \ 2
    --master <master_1_address> \ 3
    --master <master_2_address> \ 4
    --master <master_3_address>" 5

1

对于


                     installation_directory

，请指定您在运行时指定的同一目录


                     。/openshift-install create cluster

。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。


                     <bootstrap_address>

是集群 bootstrap 机器的完全限定域名或 IP 地址。

3 4 5

对于集群中的每个 control plane 或 master 机器，将


                     <master_*_address>

替换为其完全限定域名或 IP 地址。默认集群包含三台 control plane 机器。如所示，列出所有 control plane 机器，无论您的集群使用了多少个。

INFO Pulling debug logs from the bootstrap machine
INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

如果需要创建关安装失败的红帽支持问题单，请在问题单中附上压缩日志。

7.1.14. 其他资源

如需了解更多与 OpenShift Container Platform 安装类型和流程相关的详细信息，请参阅安装过程。

7.2. 验证节点健康状况

7.2.1. 查看节点状态、资源使用量和配置

查看集群节点健康状况、资源消耗统计和节点日志。另外，在单个节点上查询 kubelet 状态。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。列出集群中所有节点的名称、状态和角色：

$ oc get nodes

总结集群中每个节点的 CPU 和内存使用情况：

$ oc adm top nodes

总结特定节点的 CPU 和内存使用情况：

$ oc adm top node my-node

7.2.2. 在节点上查询 kubelet 状态

您可以查看集群节点健康状况、资源消耗统计和节点日志。另外，您还可以在单个节点上查询 kubelet 状态。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。 kubelet 通过每个节点上的 systemd 服务来管理。通过在 debug pod 中查询 kubelet systemd 服务来查看 kubelet 的状态。为节点启动 debug pod:

$ oc debug node/my-node

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。检查 kubelet systemd 服务是否在该节点上活跃：

# systemctl is-active kubelet

输出更详细的 kubelet.service 状态概述：

# systemctl status kubelet

7.2.3. 查询集群节点 journal 日志

$ oc adm node-logs --role=master -u kubelet  1

1

根据情况替换


                 kubelet

以查询其他单元日志。从集群节点上


                 /var/log/

下的特定子目录收集日志。获取


                 /var/log/

子目录中所含的日志列表。以下示例列出所有 control plane 节点上的


                 /var/log/openshift-apiserver/

中的文件：

$ oc adm node-logs --role=master --path=openshift-apiserver

检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

$ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

注意

7.3. CRI-O 容器运行时问题故障排除

7.3.1. 关于 CRI-O 容器运行时引擎

CRI-O 是 Kubernetes 的原生容器运行时实现，可与操作系统紧密集成来提供高效和优化的 Kubernetes 体验。CRI-O，提供用于运行、停止和重启容器的工具。 CRI-O 容器运行时引擎由在每个 OpenShift Container Platform 集群节点上使用 systemd 服务进行管理。当出现容器运行时问题时，验证每个节点上的 crio systemd 服务的状态。从清单容器运行时问题的节点收集 CRI-O journald 单元日志。

7.3.2. 验证 CRI-O 运行时引擎状态

您可以在每个集群节点上验证 CRI-O 容器运行时引擎状态。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。通过在节点上查询 debug pod 中的 crio systemd 服务来查看 CRI-O 状态。为节点启动 debug pod:

$ oc debug node/my-node

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。检查 crio systemd 服务在该节点上是否活跃：

# systemctl is-active crio

输出更详细的 crio.service 状态概述：

# systemctl status crio.service

7.3.3. 收集 CRI-O journald 单元日志

如果遇到 CRI-O 问题，您可以从节点获取 CRI-O journald 单元日志。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI( oc )。您有 control plane 或 control plane 机器的完全限定域名（也称为 master 机器）。收集 CRI-O journald 单元日志。以下示例从所有 control plane 节点（在集群中）收集日志：

$ oc adm node-logs --role=master -u crio

从特定节点收集 CRI-O journald 单元日志：

$ oc adm node-logs <node_name> -u crio

如果 API 无法正常工作，使用 SSH 来查看日志。将 <node>.<cluster_name>.<base_domain> 替换为适当的值：

$ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

注意

7.3.4. 清理 CRI-O 存储

如果遇到以下问题，您可以手动清除 CRI-O 临时存储：节点无法在任何 pod 上运行，并出现以下错误：

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to mount container XXX: error recreating the missing symlinks: error reading name of symlink for XXX: open /var/lib/containers/storage/overlay/XXX/link: no such file or directory

您无法在工作节点上创建新容器，并出现 “can’t stat lower layer” 错误：

can't stat lower layer ...  because it does not exist.  Going through storage to recreate the missing symlinks.

在集群升级后或尝试重启节点时，您的节点处于


              NotReady

状态。容器运行时实施 (


              crio

) 无法正常工作。您无法使用


              oc debug node/<nodename>

在节点上启动 debug shell，因为容器运行时实例 (


              crio

) 无法正常工作。按照以下步骤完全擦除 CRI-O 存储并解决错误。您可以使用具有


              cluster-admin

角色的用户访问集群。已安装 OpenShift CLI(

oc

)。在节点上使用


              cordon

。这是为了避免在节点处于


              Ready

状态时调度任何工作负载。当您的 Status 部分中存在


              SchedulingDisabled

时代表调度被禁用：

$ oc adm cordon <nodename>

以 cluster-admin 用户身份排空节点：

$ oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data

注意

pod 或 pod 模板的 terminationGracePeriodSeconds 属性控制安全终止的时间。此属性的默认值为 30 秒，但可以根据需要针对每个应用程序进行自定义。如果设置的值大于 90 秒，则 pod 可能会标记为 SIGKILL ，且无法成功终止。当节点返回时，通过 SSH 或控制台连接节点。然后连接到 root 用户：

$ ssh [email protected]
$ sudo -i

手动停止 kubelet：

# systemctl stop kubelet

停止容器和 pod：使用以下命令停止 HostNetwork 中没有的 pod。必须首先删除它们，因为它们依赖于 HostNetwork 中的网络插件 pod。

.. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

停止所有其他 pod：

# crictl rmp -fa

手动停止 crio 服务：

# systemctl stop crio

运行这些命令后，您可以完全擦除临时存储：

# crio wipe -f

启动 crio 和 kubelet 服务：

# systemctl start crio
# systemctl start kubelet

如果 crio 和 kubelet 服务启动，且节点处于 Ready 状态时，代表清理操作已正常工作：

$ oc get nodes

输出示例

NAME				    STATUS	                ROLES    AGE    VERSION
ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.22.0-rc.0+75ee307

将节点标记为可以调度。当状态中不再有


               SchedulingDisabled

时代表启用了调度：

$ oc adm uncordon <nodename>

输出示例

NAME				     STATUS	      ROLES    AGE    VERSION
ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.22.0-rc.0+75ee307

7.4. 操作系统问题故障排除

OpenShift Container Platform 在 RHCOS 上运行。您可以按照以下步骤排除与操作系统相关的问题。

7.4.1. 检查内核崩溃

kdump 服务包括在 kexec-tools 中，它提供了一个崩溃转储机制。您可以使用这个服务保存系统内存内容，以便稍后进行分析。 kdump 服务只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。有关红帽技术预览功能支持范围的详情，请参考 https://access.redhat.com/support/offerings/techpreview/ 。

7.4.1.1. 启用 kdump

RHCOS 附带 kexec-tools ，但需要手动配置才能启用 kdump 。执行以下步骤在 RHCOS 上启用 kdump ：要在第一次内核引导的过程中为崩溃内核保留内存，请输入以下命令提供内核参数：

# rpm-ostree kargs --append='crashkernel=256M'

可选：要通过网络写入崩溃转储，或将其写入其他位置而不是默认的本地 /var/crash 位置，请编辑 /etc/kdump.conf 配置文件。使用 LUKS 时需要网络转储。 kdump 不支持 LUKS 加密设备的本地崩溃转储。有关配置 kdump 服务的详情，请查看 /etc/sysconfig/kdump 、 /etc/kdump.conf 和 kdump.conf 手册页中的注释。有关配置转储目标的详情，请参阅 RHEL kdump 文档。启用 kdump systemd 服务：

# systemctl enable kdump.service

重启系统：

# systemctl reboot

确认


               kdump

已加载了崩溃内核，检查


               kdump.service

已成功启动并退出，


               cat /sys/kernel/kexec_crash_loaded

输出

。

7.4.1.2. 在第 1 天启用 kdump

kdump 服务旨在为每个节点启用调试内核问题。由于启用了 kdump 会增加成本，且这些成本会与启用了 kdump 的额外节点一起积累，因此建议只在需要的节点中启用 kdump 。在每个节点中启用 kdump 的潜在成本包括：因为为崩溃内核保留了内存，所以可用 RAM 较少。内核转储内核时节点不可用。用于存储崩溃转储的额外存储空间。因为 kdump 服务只是一个技术预览，所以它并不是生产环境就绪的。如果您了解启用 kdump 服务所带来的影响，则可以根据具体情况在集群范围内启用 kdump 。虽然当前还不支持特定于具体机器的机器配置，但您可以在第 1 天通过 MachineConfig 对象中的 systemd 单元来执行前面的步骤，并在集群的所有节点上启用 kdump。您可以创建 MachineConfig 对象，并将该对象注入 Ignition 在集群设置过程中使用的清单文件集合中。如需有关如何使用 Ignition 配置的更多信息和示例，请参阅 Installing → Installation configuration 部分中的"自定义节点"。为集群范围配置创建 MachineConfig 对象：创建一个 Butane 配置文件 99-worker-kdump.bu ，用于配置并启用 kdump：

variant: openshift
version: 4.8.0
metadata:
  name: 99-worker-kdump 1
  labels:
    machineconfiguration.openshift.io/role: worker 2
openshift:
  kernel_arguments: 3
    - crashkernel=256M
storage:
  files:
    - path: /etc/kdump.conf 4
      mode: 0644
      overwrite: true
      contents:
        inline: |
          path /var/crash
          core_collector makedumpfile -l --message-level 7 -d 31
    - path: /etc/sysconfig/kdump 5
      mode: 0644
      overwrite: true
      contents:
        inline: |
          KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
          KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never nokaslr novmcoredd hest_disable"
          KEXEC_ARGS="-s"
          KDUMP_IMG="vmlinuz"
systemd:
  units:
    - name: kdump.service
      enabled: true

1 2

在为 control plane 节点创建


                  MachineConfig

对象时，将


                  worker

替换为两个位置的


                  master

。提供内核参数来为崩溃内核保留内存。如果需要，您可以添加其他内核参数。如果要从默认更改


                  /etc/kdump.conf

的内容，请包含此部分并相应地修改


                  inline

子部分。如果要从默认更改


                  /etc/sysconfig/kdump

的内容，请包含此部分并相应地修改


                  inline

子部分。使用 Butane 生成机器配置 YAML 文件


                  99-worker-kdump.yaml

，包含要提供给节点的配置：

$ butane 99-worker-kdump.bu -o 99-worker-kdump.yaml

在集群设置过程中将 YAML 文件放入清单中。您还可以使用 YAML 文件在集群设置后创建此 MachineConfig 对象：

$ oc create -f ./99-worker-kdump.yaml

7.4.1.3. 测试 kdump 配置

有关 kdump 的信息，请参阅 RHEL 文档中的测试 kdump 配置部分。

7.4.1.4. 分析内核转储

有关 kdump 的信息，请参阅 RHEL 文档中的分析内核转储部分。建议您在单独的 RHEL 系统中执行 vmcore 分析。在 RHEL 中设置 kdump Linux 内核文档 kdump kdump.conf(5)- /etc/kdump.conf 配置文件的说明书页，包含可用选项的完整文档 kexec(8)- kexec 软件包的 man page 有关 kexec 和 kdump 的红帽知识库文章

7.4.2. 调试 Ignition 失败

如果无法置备机器，Ignition 会失败，RHCOS 将引导至紧急 shell。使用以下步骤获取调试信息。运行以下命令显示哪个服务单元失败：

$ systemctl --failed

可选：在单个服务单元上运行以下命令查找更多信息：

$ journalctl -u <unit>.service

7.5. 网络问题故障排除

7.5.1. 如何选择网络接口

对于在裸机上安装，或在具有多个网络接口控制器（NIC）的虚拟机中安装时，OpenShift Container Platform 用于与 Kubernetes API 服务器通信的 NIC 由节点引导时 systemd 运行的 nodeip-configuration.service 服务单元决定。该服务会逐个检查节点上的每个网络接口，当第一个配置了可以用于 API 服务器的 IP 地址的子网的网络接口被选择用来进行 OpenShift Container Platform 通讯。在 nodeip-configuration.service 服务确定正确的 NIC 后，该服务会创建 /etc/systemd/system/kubelet.service.d/20-nodenet.conf 文件。 20-nodenet.conf 文件将 KUBELET_NODE_IP 环境变量设置为服务所选的 IP 地址。当 kubelet 服务启动时，它会从 20-nodenet.conf 文件中读取环境变量的值，并将 IP 地址设置为 --node-ip kubelet 命令行参数。因此，kubelet 服务使用所选 IP 地址作为节点 IP 地址。如果在安装后重新配置了硬件或网络， nodeip-configuration.service 服务可能会在重启后选择不同的 NIC。在某些情况下， oc get nodes -o wide 命令的输出中的 INTERNAL-IP 列中可能会看到选择了一个不同的 NIC。如果因为选择了一个不同的 NIC 而导致网络通信中断或配置错误，使用一个策略来覆盖选择的过程以明确设置正确的 IP 地址。以下列表确定了高级步骤和注意事项：创建一个 shell 脚本，以确定用于 OpenShift Container Platform 通信的 IP 地址。让脚本创建一个自定义单元文件，如 /etc/systemd/system/kubelet.service.d/98-nodenet-override.conf 。使用自定义单元文件 98-nodenet-override.conf ，将 KUBELET_NODE_IP 环境变量设置为 IP 地址。不要覆盖 /etc/systemd/system/kubelet.service.d/20-nodenet.conf 文件。指定同一目录路径中的数值较高的文件名，如 98-nodenet-override.conf 。这样做的目标是使自定义单元文件在 20-nodenet.conf 之后运行，并覆盖环境变量的值。使用 shell 脚本创建一个机器配置对象，作为 base64 编码字符串，并使用 Machine Config Operator 将脚本部署到文件系统路径（如 /usr/local/bin/override-node-ip.sh ）的节点。确保 systemctl daemon-reload 在 shell 脚本运行后运行。最简单的方法是在机器配置中指定 ExecStart=systemctl daemon-reload ，如下例所示。

用于覆盖 kubelet 网络接口的机器配置示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
     machineconfiguration.openshift.io/role: worker
  name: 98-nodenet-override
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<encoded_script>
        mode: 0755
        overwrite: true
        path: /usr/local/bin/override-node-ip.sh
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Override node IP detection
          Wants=network-online.target
          Before=kubelet.service
          After=network-online.target
          [Service]
          Type=oneshot
          ExecStart=/usr/local/bin/override-node-ip.sh
          ExecStart=systemctl daemon-reload
          [Install]
          WantedBy=multi-user.target
        enabled: true
        name: nodenet-override.service

7.5.2. Open vSwitch 问题故障排除

若要对一些 Open vSwitch (OVS) 问题进行故障排除，您可能需要配置日志级别以包含更多信息。如果临时修改节点上的日志级别，请注意您可以像以下示例一样从节点上的机器配置守护进程接收日志消息：

E0514 12:47:17.998892    2281 daemon.go:1350] content mismatch for file /etc/systemd/system/ovs-vswitchd.service: [Unit]

为避免与不匹配相关的日志消息，请在完成故障排除后恢复日志级别更改。

7.5.2.1. 临时配置 Open vSwitch 日志级别

对于短期故障排除，您可以临时配置 Open vSwitch (OVS) 日志级别。以下流程不需要重启该节点。另外，每当您重新引导节点时，配置更改都不会保留。执行此步骤更改日志级别后，您可以接收来自机器配置守护进程的日志消息，该守护进程指出 ovs-vswitchd.service 的内容不匹配。要避免日志消息，请重复此步骤，并将日志级别设置为原始值。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。为节点启动 debug pod:

$ oc debug node/<node_name>

将 /host 设置为 debug shell 中的根目录。debug pod 从 pod 中的 /host 中的主机挂载 root 文件系统。将根目录改为 /host ，您可以从主机文件系统中运行二进制文件：

# chroot /host

查看 OVS 模块的当前 syslog 级别：

# ovs-appctl vlog/list

以下示例输出显示了 syslog 设置为 info 的日志级别。

console syslog file ------- ------ ------ backtrace OFF INFO INFO bfd OFF INFO INFO bond OFF INFO INFO bridge OFF INFO INFO bundle OFF INFO INFO bundles OFF INFO INFO cfm OFF INFO INFO collectors OFF INFO INFO command_line OFF INFO INFO connmgr OFF INFO INFO conntrack OFF INFO INFO conntrack_tp OFF INFO INFO coverage OFF INFO INFO ct_dpif OFF INFO INFO daemon OFF INFO INFO daemon_unix OFF INFO INFO dns_resolve OFF INFO INFO dpdk OFF INFO INFO 指定 /etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf 文件中的日志级别：

Restart=always
ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /var/lib/openvswitch'
ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /etc/openvswitch'
ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /run/openvswitch'
ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg
ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg

在前面的示例中，日志级别设置为 dbg。修改最后两行，将 syslog:<log_level> 设置为 off、emer、err、warn、info 或 dbg。off 日志级别会过滤掉所有日志消息。重启服务：

# systemctl daemon-reload

# systemctl restart ovs-vswitchd

7.5.2.2. 永久配置 Open vSwitch 日志级别

对于对 Open vSwitch (OVS) 日志级别的长期更改，您可以永久更改日志级别。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。使用类似以下示例的 MachineConfig 对象创建一个文件，如 99-change-ovs-loglevel.yaml ：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master  1
  name: 99-change-ovs-loglevel
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - dropins:
        - contents: |
            [Service]
              ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg  2
              ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg
          name: 20-ovs-vswitchd-restart.conf
        name: ovs-vswitchd.service

1

执行此步骤以配置 control plane 节点后，重复这个过程，并将角色设置为


                  worker

以配置 worker 节点。设置


                  syslog:<log_level>

值。日志级别为

off

、


                  emer

、

err

、


                  warn

、


                  info

或

dbg

。将值设置为

off

会过滤掉所有日志消息。应用机器配置：

$ oc apply -f 99-change-ovs-loglevel.yaml

其他资源

了解 Machine Config Operator 检查机器配置池状态

7.5.2.3. 显示 Open vSwitch 日志

使用以下步骤显示 Open vSwitch (OVS) 日志。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。运行以下任一命令：使用来自集群外的 oc 命令显示日志：

$ oc adm node-logs <node_name> -u ovs-vswitchd

登录到集群中的节点后显示日志：

# journalctl -b -f -u ovs-vswitchd.service

登录节点的一种方法是使用 oc debug node/<node_name> 命令。

7.6. Troubleshooting Operator 的问题

Operator 是一种打包、部署和管理 OpenShift Container Platform 应用程序的方法。它可以被看作是软件厂商的工程团队的扩展，可以在 OpenShift Container Platform 监控软件的运行情况，并根据软件的当前状态实时做出决策。Operator 被设计为用来无缝地处理升级过程，并对出现的错误自动进行响应，而且不会采取“捷径”（如跳过软件备份过程来节省时间）。 OpenShift Container Platform 4.8 包括了一组默认的 Operator，它们是集群正常工作所需的。这些默认 Operator 由 Cluster Version Operator（CVO）管理。作为集群管理员，您可使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的应用程序 Operator。然后，您可将 Operator 订阅至一个或多个命名空间，供集群上的开发人员使用。应用程序 Operator 由 Operator Lifecycle Manager（OLM）进行管理。如果遇到 Operator 问题，请验证 Operator 订阅状态。检查集群中的 Operator pod 健康状况，并收集 Operator 日志以进行诊断。

7.6.1. operator 订阅状况类型

订阅可报告以下状况类型：

状况描述

CatalogSourcesUnhealthy 用于解析的一个或多个目录源不健康。 InstallPlanMissing 缺少订阅的安装计划。 InstallPlanPending 订阅的安装计划正在安装中。 InstallPlanFailed 订阅的安装计划失败。默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator（CVO）管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。

7.6.2. 使用 CLI 查看 Operator 订阅状态

您可以使用 CLI 查看 Operator 订阅状态。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。列出 Operator 订阅：

$ oc get subs -n <operator_namespace>

使用 oc describe 命令检查 Subscription 资源：

$ oc describe sub <subscription_name> -n <operator_namespace>

在命令输出中，找到 Operator 订阅状况类型的 Conditions 部分。在以下示例中， CatalogSourcesUnhealthy 条件类型具有 false 状态，因为所有可用目录源都健康：

Conditions:
   Last Transition Time:  2019-07-29T13:42:57Z
   Message:               all available catalogsources are healthy
   Reason:                AllCatalogSourcesHealthy
   Status:                False
   Type:                  CatalogSourcesUnhealthy

默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator（CVO）管理，它们没有


                    Subscription

对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有


                    Subscription

对象。

7.6.3. 使用 CLI 查看 Operator 目录源状态

您可以使用 CLI 查看 Operator 目录源的状态。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。列出命名空间中的目录源。例如，您可以检查 openshift-marketplace 命名空间，该命名空间用于集群范围的目录源：

$ oc get catalogsources -n openshift-marketplace

输出示例

NAME                  DISPLAY               TYPE   PUBLISHER   AGE
certified-operators   Certified Operators   grpc   Red Hat     55m
community-operators   Community Operators   grpc   Red Hat     55m
example-catalog       Example Catalog       grpc   Example Org 2m25s
redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
redhat-operators      Red Hat Operators     grpc   Red Hat     55m

使用


                    oc describe

命令获取有关目录源的详情和状态：

$ oc describe catalogsource example-catalog -n openshift-marketplace

输出示例

Name:         example-catalog
Namespace:    openshift-marketplace
Status:
  Connection State:
    Address:              example-catalog.openshift-marketplace.svc:50051
    Last Connect:         2021-09-09T17:07:35Z
    Last Observed State:  TRANSIENT_FAILURE
  Registry Service:
    Created At:         2021-09-09T17:05:45Z
    Port:               50051
    Protocol:           grpc
    Service Name:       example-catalog
    Service Namespace:  openshift-marketplace

在上例的输出中，最后观察到的状态是


                     TRANSIENT_FAILURE

。此状态表示目录源建立连接时出现问题。列出创建目录源的命名空间中的 pod：

$ oc get pods -n openshift-marketplace

输出示例

NAME                                    READY   STATUS             RESTARTS   AGE
certified-operators-cv9nn               1/1     Running            0          36m
community-operators-6v8lp               1/1     Running            0          36m
marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
redhat-marketplace-57p8c                1/1     Running            0          36m
redhat-operators-smxx8                  1/1     Running            0          36m

在命名空间中创建目录源时，会在该命名空间中为目录源创建一个 pod。在前面的示例中，


                      example-catalog-bwt8z

pod 的状态是


                      ImagePullBackOff

。此状态表示拉取目录源的索引镜像存在问题。使用


                      oc describe

命令检查 pod 以获取更多详细信息：

$ oc describe pod example-catalog-bwt8z -n openshift-marketplace

输出示例

Name:         example-catalog-bwt8z
Namespace:    openshift-marketplace
Priority:     0
Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
  Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
  Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
  Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
  Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
  Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

在前面的示例输出中，错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如，索引镜像可能存储在需要登录凭证的 registry 中。 Operator Lifecycle Manager 概念和资源 → Catalog 源 gRPC 文档：连接状态从私有 registry 访问 Operator 的镜像

7.6.4. 查询 Operator pod 状态

您可以列出集群中的 Operator pod 及其状态。您还可以收集详细的 Operator pod 概述。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。列出集群中运行的 Operator。输出包括 Operator 版本、可用性和运行时间信息：

$ oc get clusteroperators

列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：

$ oc get pod -n <operator_namespace>

输出详细的 Operator pod 概述：

$ oc describe pod <operator_pod_name> -n <operator_namespace>

如果 Operator 问题特定于某个节点，则在该节点上查询 Operator 容器状态。为节点启动 debug pod：

$ oc debug node/my-node

# chroot /host

注意

运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。列出节点容器的详细信息，包括状态和关联的 pod ID:

# crictl ps

列出节点上特定 Operator 容器的信息。以下示例列出了 network-operator 容器的信息：

# crictl ps --name network-operator

退出 debug shell。

7.6.5. 收集 Operator 日志

如果遇到 Operator 问题，您可以从 Operator pod 日志中收集详细诊断信息。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI( oc )。您有 control plane 或 control plane 机器的完全限定域名（也称为 master 机器）。列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：

$ oc get pods -n <operator_namespace>

检查 Operator pod 的日志：

$ oc logs pod/<pod_name> -n <operator_namespace>

如果 Operator pod 具有多个容器，则上述命令将会产生一个错误，其中包含每个容器的名称。从独立容器查询日志：

$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>

如果 API 无法正常工作，请使用 SSH 来查看每个 control plane 节点上的 Operator pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。列出每个 control plane 节点上的 pod：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods

对于任何未显示 Ready 状态的 Operator pod，详细检查 Pod 的状态。将 <operator_pod_id> 替换为上一命令输出中列出的 Operator pod ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>

列出与 Operator pod 相关的容器：

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

对于任何未显示 Ready 状态的 Operator 容器，请详细检查容器的状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

检查任何未显示 Ready 状态的 Operator 容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

注意

7.6.6. 禁用 Machine Config Operator 自动重新引导

当 Machine Config Operator（MCO）进行配置更改时，Red Hat Enterprise Linux CoreOS（RHCOS）必须重启才能使更改生效。无论配置更改是自动还是手动的，RHCOS 节点都会自动重启，除非它已被暂停。以下修改不会触发节点重新引导：当 MCO 检测到以下任何更改时，它会在不排空或重启节点的情况下应用更新：在机器配置的 spec.config.passwd.users.sshAuthorizedKeys 参数中更改 SSH 密钥。在 openshift-config 命名空间中更改全局 pull secret 或 pull secret。 Kubernetes API Server Operator 自动轮转 /etc/kubernetes/kubelet-ca.crt 证书颁发机构（CA）。当 MCO 检测到对 /etc/containers/registries.conf 文件的更改时，如添加或编辑 ImageDigestMirrorSet 或 ImageTagMirrorSet 对象，它会排空对应的节点，应用更改并取消记录节点。节点排空不会发生以下更改：增加了一个 registry，带有为每个镜像（mirror）设置了 pull-from-mirror = "digest-only" 参数。增加了一个镜像（mirror），带有在一个 registry 中设置的 pull-from-mirror = "digest-only" 参数。在 unqualified-search-registries 列表中添加项目。为了避免不必要的中断，您可以修改机器配置池（MCP）以防止在 Operator 更改机器配置后自动重启。暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果在 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动续订证书时，MCP 会暂停，但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug 、 oc logs 、 oc exec 和 oc attach 。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。新 CA 证书会在自安装日期起的 292 天生成，并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转，请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。

7.6.6.1. 使用控制台禁用 Machine Config Operator 自动重新引导

为了避免对 Machine Config Operator（MCO）所做的更改造成不必要的中断，您可以使用 OpenShift Container Platform Web 控制台修改机器配置池（MCP），以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果在 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动续订证书时，MCP 会暂停，但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug 、 oc logs 、 oc exec 和 oc attach 。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。新 CA 证书会在自安装日期起的 292 天生成，并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转，请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。您可以使用具有 cluster-admin 角色的用户访问集群。要暂停或取消暂停自动 MCO 更新重新引导：暂停自动引导过程：以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。点 Compute → MachineConfigPools 。在 MachineConfigPools 页面中，点击 master 或 worker ，具体取决于您要暂停重新引导的节点。在 master 或 worker 页面中，点 YAML 。在 YAML 中，将 spec.paused 字段更新为 true 。

MachineConfigPool 对象示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
spec:
  paused: true 1

将


                     spec.paused

字段更新为


                     true

以暂停重新引导。要验证 MCP 是否已暂停，请返回到 MachineConfigPools 页面。在 MachineConfigPools 页面中，您修改的 MCP 报告了 Paused 列中为 True 。如果 MCP 在暂停时有待处理的变化， Updated 列为 False ， Updating 为 False 。当 Updated 为 True 且 Updating 为 False 时，代表没有待处理的更改。如果有尚未进行的更改（ Updated 和 Updating 字段都是 False ）,建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程，以应用上一次重启后排队的更改。取消暂停自动引导过程：以具有


                     cluster-admin

角色的用户身份登录到 OpenShift Container Platform web 控制台。点 Compute → MachineConfigPools 。在 MachineConfigPools 页面中，点击 master 或 worker ，具体取决于您要暂停重新引导的节点。在 master 或 worker 页面中，点 YAML 。在 YAML 中，将


                     spec.paused

字段更新为


                     false

。

MachineConfigPool 对象示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
spec:
  paused: false 1

将


                      spec.paused

字段更新为


                      false

以允许重启。通过取消暂停 MCP，MCO 应用所有暂停的更改，根据需要重启 Red Hat Enterprise Linux CoreOS（RHCOS）。要验证 MCP 是否已暂停，请返回到 MachineConfigPools 页面。在 MachineConfigPools 页面中，您修改的 MCP 报告 Paused 列为 False 。如果 MCP 正在应用任何待处理的更改， Updated 列为 False ， Updating 列为 True 。当 Updated 为 True 且 Updating 为 False 时，不会再进行任何更改。

7.6.6.2. 使用 CLI 禁用 Machine Config Operator 自动重新引导

为了避免对 Machine Config Operator（MCO）所做的更改造成不必要的中断，您可以使用 OpenShift CLI（oc）来修改机器配置池（MCP），以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果在 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动续订证书时，MCP 会暂停，但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug 、 oc logs 、 oc exec 和 oc attach 。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。新 CA 证书会在自安装日期起的 292 天生成，并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转，请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。要暂停或取消暂停自动 MCO 更新重新引导：暂停自动引导过程：更新 MachineConfigPool 自定义资源，将 spec.paused 字段设置为 true 。

Control plane（master）节点

$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master

Worker 节点

$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker

验证 MCP 是否已暂停：

Control plane（master）节点

$ oc get machineconfigpool/master --template='{{.spec.paused}}'

Worker 节点

$ oc get machineconfigpool/worker --template='{{.spec.paused}}'


                      spec.paused

字段为


                      true

，MCP 暂停。确定 MCP 是否有待处理的更改：

# oc get machineconfigpool

输出示例

NAME     CONFIG                                             UPDATED   UPDATING
master   rendered-master-33cf0a1254318755d7b48002c597bf91   True      False
worker   rendered-worker-e405a5bdb0db1295acea08bcca33fa60   False     False

如果 UPDATED 列是 False ， UPDATING 为 False ，则有待处理的更改。当 UPDATED 为 True 且 UPDATING 为 False 时，没有待处理的更改。在上例中，worker 节点有待处理的变化。control plane 节点（也称为 master 节点）没有任何待处理的更改。如果有尚未进行的更改（ Updated 和 Updating 字段都是 False ）,建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程，以应用上一次重启后排队的更改。取消暂停自动引导过程：更新


                       MachineConfigPool

自定义资源，将


                       spec.paused

字段设置为


                       false

。

Control plane（master）节点

$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master

Worker 节点

$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker

通过取消暂停 MCP，MCO 应用所有暂停的更改，根据需要重启 Red Hat Enterprise Linux CoreOS（RHCOS）。验证 MCP 是否已取消暂停：

Control plane（master）节点

$ oc get machineconfigpool/master --template='{{.spec.paused}}'

Worker 节点

$ oc get machineconfigpool/worker --template='{{.spec.paused}}'

false


                         spec.paused

字段为


                         false

，MCP 被取消暂停。确定 MCP 是否有待处理的更改：

$ oc get machineconfigpool

输出示例

NAME     CONFIG                                   UPDATED  UPDATING
master   rendered-master-546383f80705bd5aeaba93   True     False
worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False    True

如果 MCP 正在应用任何待处理的更改， UPDATED 列为 False ， UPDATING 列为 True 。当 UPDATED 为 True 且 UPDATING 为 False 时，没有进一步的更改。在上例中，MCO 正在更新 worker 节点。

7.6.7. 刷新失败的订阅

在 Operator Lifecycle Manager（OLM）中，如果您订阅的是引用网络中无法访问的镜像的 Operator，您可以在 openshift-marketplace 命名空间中找到带有以下错误的作业：

ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host

因此，订阅会处于这个失败状态，Operator 无法安装或升级。您可以通过删除订阅、集群服务版本（CSV）及其他相关对象来刷新失败的订阅。重新创建订阅后，OLM 会重新安装 Operator 的正确版本。您有一个失败的订阅，无法拉取不能访问的捆绑包镜像。已确认可以访问正确的捆绑包镜像。从安装 Operator 的命名空间中获取


                   Subscription

和


                   ClusterServiceVersion

对象的名称：

$ oc get sub,csv -n <namespace>

输出示例

NAME                                                       PACKAGE                  SOURCE             CHANNEL
subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

删除订阅：

$ oc delete subscription <subscription_name> -n <namespace>

删除集群服务版本：

$ oc delete csv <csv_name> -n <namespace>

在 openshift-marketplace 命名空间中获取所有失败的作业的名称和相关配置映射：

$ oc get job,configmap -n openshift-marketplace

输出示例

NAME                                                                        COMPLETIONS   DURATION   AGE
job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
NAME                                                                        DATA   AGE
configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

删除作业：

$ oc delete job <job_name> -n openshift-marketplace

这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。删除配置映射：

$ oc delete configmap <configmap_name> -n openshift-marketplace

在 Web 控制台中使用 OperatorHub 重新安装 Operator。检查是否已成功重新安装 Operator:

$ oc get sub,csv,installplan -n <namespace>

7.7. 检查 pod 问题

OpenShift Container Platform 利用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器。pod 是可在 OpenShift Container Platform 4.8 上定义、部署和管理的最小计算单元。在定义了 pod 后，它将分配到节点上运行，直到容器退出，或直到它被删除为止。根据策略和退出代码，Pod 可在退出或保留后删除，以便访问其日志。首先要检查 pod 出现问题时 pod 的状态。如果发生 pod 故障，请观察 pod 的错误状态以识别特定镜像、容器或 pod 网络问题。根据错误状态集中诊断数据收集。查看 pod 事件消息以及 pod 和容器日志信息。通过访问命令行中运行的 pod，或根据 Pod 的部署配置启动具有 root 访问权限的调试 pod 来动态诊断问题。

7.7.1. 了解 pod 错误状态

pod 失败返回显式错误状态，可在 oc get pods 输出的 status 字段中观察到。Pod 错误状态会涵盖镜像、容器和容器网络相关的故障。下表提供了 pod 错误状态及其描述列表。

表 7.2. Pod 错误状态
Pod 错误状态	描述
`ErrImagePull` 通用镜像检索错误。 `ErrImagePullBackOff` 镜像检索失败。 `ErrInvalidImageName` 指定镜像名称无效。 `ErrImageInspect` 镜像检查没有成功。 `ErrImageNeverPull` `PullPolicy` 设置为 `NeverPullImage` ，目标镜像没有本地存在。 `ErrRegistryUnavailable` 当尝试从 registry 检索镜像时，会出现 HTTP 错误。 `ErrContainerNotFound` 指定容器在声明的 pod 中不存在或未由 kubelet 管理。 `ErrRunInitContainer` 容器初始化失败。 `ErrRunContainer` pod 的容器都没有成功启动。 `ErrKillContainer` 没有 pod 的容器被成功终止。 `ErrCrashLoopBackOff` 容器已终止。kubelet 将不会试图重启它。 `ErrVerifyNonRoot` 容器或镜像尝试使用 root 权限运行。 `ErrCreatePodSandbox` Pod 沙盒创建没有成功。 `ErrConfigPodSandbox` Pod 沙盒配置没有获得。 `ErrKillPodSandbox` pod 沙箱没有成功停止。 `ErrSetupNetwork` 网络初始化失败。 `ErrTeardownNetwork` 网络终止失败。

7.7.2. 检查 pod 状态

您可以查询 pod 状态和错误状态。您还可以查询 pod 的相关部署配置，并查看基础镜像的可用性。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。已安装了 skopeo 。切换到项目：

$ oc project <project_name>

列出在命名空间中运行的 pod，以及 pod 状态、错误状态、重启和年龄：

$ oc get pods

确定命名空间是否由部署配置管理：

$ oc status

如果命名空间由部署配置管理，输出包括部署配置名称和基础镜像引用。检查以上命令输出中引用的基础镜像：

$ skopeo inspect docker://<image_reference>

如果基础镜像引用不正确，请更新部署配置中的引用：

$ oc edit deployment/my-deployment

当部署配置退出时，配置将自动重新部署。在部署过程中的 Watch pod 的状态，以确定这个问题是否已解决：

$ oc get pods -w

检查命名空间中的事件，以了解与 pod 失败相关的诊断信息：

$ oc get events

7.7.3. 检查 pod 和容器日志

您可以检查 pod 和容器日志，以查看与显式 pod 失败相关的警告和错误消息。根据策略和退出代码，pod 和容器日志在 pod 终止后仍然可用。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。查询特定 pod 的日志：

$ oc logs <pod_name>

查询 pod 中特定容器的日志：

$ oc logs <pod_name> -c <container_name>

由前面的 oc logs 命令所获得的日志由发送到 pod 或容器中的 stdout 的信息组成。检查 pod 中的 /var/log/ 中包含的日志。列出 pod 中 /var/log 中所含的日志文件和子目录：

$ oc exec <pod_name> ls -alh /var/log

查询 pod 中 /var/log 中所含的特定日志文件：

$ oc exec <pod_name> cat /var/log/<path_to_log>

列出特定容器内 /var/log 中含有的日志文件和子目录：

$ oc exec <pod_name> -c <container_name> ls /var/log

查询特定容器中的 /var/log 中所含的特定日志文件：

$ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>

7.7.4. 访问运行的 pod

您可以通过在 pod 中打开 shell，或通过端口转发获取网络访问，来动态查看正在运行的 pod。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。切换到包含您要访问的 pod 的项目。这是必要的，因为 oc rsh 命令不支持使用 -n 选项指定命名空间：

$ oc project <namespace>

启动到 pod 的远程 shell:

$ oc rsh <pod_name>  1

1

如果 pod 有多个容器，除非使用


                         -c <container_name>

指定了一个容器，否则


                         oc rsh

会默认使用第一个容器。启动至 pod 中的特定容器中的一个远程 shell ：

$ oc rsh -c <container_name> pod/<pod_name>

创建一个端口转发会话到 pod 上的端口：

$ oc port-forward <pod_name> <host_port>:<pod_port>  1

1: 输入 Ctrl+C 来取消端口转发会话。

7.7.5. 启动具有 root 访问权限的 debug pod

您可以基于一个有问题的 pod 部署或部署配置，启动具有根访问权限的 debug pod。pod 用户通常使用非 root 权限运行，但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用：您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。根据一个部署启动具有 root 访问权限的 debug pod。获取项目部署名称：

$ oc get deployment -n <project_name>

根据部署启动带有 root 权限的 debug pod:

$ oc debug deployment/my-deployment --as-root -n <project_name>

根据部署配置启动具有 root 访问权限的 debug pod。获取项目的部署配置名称：

$ oc get deploymentconfigs -n <project_name>

根据部署配置，使用 root 权限启动 debug pod:

$ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>

注意

您可以将 -- <command> 附加到前面的 oc debug 命令中，以便在 debug pod 中运行单个命令，而不是运行交互式 shell。

7.7.6. 将文件复制到 pod 和容器，或从 pod 和容器中复制

您可以将文件复制到 pod 或从 pod 复制，以测试配置更改或收集诊断信息。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。将文件复制到 pod:

$ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1

1

如果没有指定

-c

选项，则会选择 pod 中的第一个容器。从 pod 复制文件：

$ oc cp <pod_name>:/<path>  -c <container_name><local_path>  1

1: 如果没有指定 -c 选项，则会选择 pod 中的第一个容器。要使 oc cp 正常工作，容器内必须有 tar 。

7.8. 对 Source-to-Image 进行故障排除

7.8.1. Source-to-Image 故障排除策略

Source-to-Image (S2I) 是一种用于构建可重复生成的 Docker 格式容器镜像的工具。它通过将应用程序源代码注入容器镜像，并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像（构建器）和构建的源。要确定 S2I 进程中的故障发生位置，您可以观察与以下 S2I 阶段相关的 pod 状态： 在构建配置阶段 ，构建 pod 用于从基础镜像和应用程序源代码创建应用程序容器镜像。 在部署配置阶段 ，部署 pod 用于从构建配置阶段构建的应用程序容器镜像中部署应用程序 pod。部署 pod 还会部署其他资源，如服务和路由。部署配置在构建配置成功后开始。 在部署 pod 启动应用程序 pod 后 ，应用程序故障可能会在运行的应用程序 pod 中发生。例如，即使应用程序 pod 处于 Running 状态，应用程序的行为也可能不会如预期。在这种情况下，您可以访问正在运行的应用程序 pod，以调查 pod 中的应用程序故障。当对 S2I 问题进行故障排除时，请按照这个策略操作：监控构建、部署和应用程序 pod 状态确定发生问题 S2I 进程阶段查看与失败阶段对应的日志

7.8.2. 收集 Source-to-Image 诊断数据

S2I 工具按顺序运行构建 pod 和部署 pod。部署 pod 负责根据构建阶段创建的应用程序容器镜像部署应用程序 pod。观察构建、部署和应用程序 pod 状态，以确定 S2I 进程中的故障发生位置。然后，重点收集诊断数据。您可以使用具有 cluster-admin 角色的用户访问集群。 API 服务仍然可以正常工作。已安装 OpenShift CLI（ oc ）。在整个 S2I 过程中监控 pod 状态，以确定在哪个阶段发生故障：

$ oc get pods -w  1

1

使用

-w

来监控 pod 是否有变化，直到您使用


                        Ctrl+C

退出命令。检查 pod 失败的日志以找出错误。 如果构建 pod 失败 ，请检查构建 pod 的日志：

$ oc logs -f pod/<application_name>-<build_number>-build

注意

另外，您可以使用 oc logs -f bc/<application_name> 来查看构建配置的日志。构建配置的日志包括来自构建 pod 的日志。 如果部署 pod 失败 ，请查看部署 pod 的日志：

$ oc logs -f pod/<application_name>-<build_number>-deploy

注意

另外，您可以使用 oc logs -f bc/<application_name> 来查看部署配置的日志。此操作会从部署 pod 输出日志，直到部署 pod 成功完成为止。如果在部署 pod 完成后运行，命令会输出来自应用程序 pod 的日志。部署 pod 完成后，仍可通过运行 oc logs -f pod/<application_name>-<build_number>-deploy 来访问其日志。 如果应用程序 pod 失败，或者应用程序没有如预期在正在运行的应用程序 pod 中发生 ，请查看应用程序 pod 的日志：

$ oc logs -f pod/<application_name>-<build_number>-<random_string>

7.8.3. 收集应用程序诊断数据以调查应用程序失败

应用程序故障可在运行的应用程序 pod 中发生。在这些情况下，您可以使用以下策略检索诊断信息：检查与应用程序 pod 相关的事件。查看应用程序 pod 的日志，包括不是由 OpenShift Logging 框架收集的特定应用程序日志文件。以互动方式测试应用程序功能，并在应用程序容器中运行诊断工具。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。列出与特定应用程序 pod 相关的事件。以下示例检索名为 my-app-1-akdlg 的应用程序 pod 的事件:

$ oc describe pod/my-app-1-akdlg

检查应用程序 pod 的日志：

$ oc logs -f pod/my-app-1-akdlg

在正在运行的应用程序 pod 中查询特定日志。发送到 stdout 的日志由 OpenShift Logging 框架收集，并包含在上一命令的输出中。以下查询只适用于没有发送到 stdout 的日志。如果应用程序日志可以在 pod 内不需要 root 权限的情况下就可以进行访问，则按如下方式处理日志文件：

$ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

如果需要 root 访问权限才能查看应用程序日志，您可以启动具有 root 权限的 debug 容器，然后从容器内查看日志文件。从项目的 DeploymentConfig 对象启动 debug 容器。pod 用户通常使用非 root 权限运行，但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用：

$ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

注意

如果您运行不使用 -- <command> 的 oc debug dc/<deployment_configuration> --as-root ，则可以获得 debug pod 内带有 root 权限的一个互动式 shell 。以互动方式测试应用程序功能,并在带有互动 shell 的应用程序容器中运行诊断工具。在应用程序容器上启动一个交互式 shell:

$ oc exec -it my-app-1-akdlg /bin/bash

在 shell 中以互动方式测试应用程序功能。例如，您可以运行容器的入口点命令并观察结果。然后，在更新源代码并通过 S2I 进程重建应用程序容器前，直接从命令行测试更改。运行容器中的诊断二进制文件。运行一些诊断二进制文件需要 root 权限。在这些情况下，您可以通过运行


                     oc debug dc/<deployment_configuration> --as-root

，根据有问题的 pod 的


                     DeploymentConfig

对象启动一个带有 root 访问权限的 debug pod。然后，您可以从 debug pod 中以 root 用户身份运行诊断二进制文件。如果容器中没有诊断二进制文件，您可以使用


                     nsenter

在容器的命名空间中运行主机的诊断二进制文件。以下实例在一个容器的命名空间中运行


                     ip ad

，使用主机的

ip

二进制代码。在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为


                     <node_name>-debug

的 debug pod:

$ oc debug node/my-cluster-node

# chroot /host

注意

# crictl ps

确定容器的进程 ID。在本例中，目标容器 ID 是 7fe32346b120 :

# crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

在容器命名空间中运行 ip ad ，使用主机的 ip 二进制代码。本例使用 31150 作为容器的进程 ID。 nsenter 命令输入目标进程的命名空间并在命名空间中运行命令。因为本例中的目标进程是一个容器的进程 ID，所以 ip ad 命令在主机的容器命名空间中运行：

# nsenter -n -t 31150 -- ip ad

注意

只有在使用特权容器（如 debug 节点）时，才能在容器的命名空间中运行主机的诊断二进制代码。

7.8.4. 其他资源

如需有关 S2I 构建策略的更多详情，请参阅 Source-to-Image（S2I）构建。

7.9. 存储问题故障排除

7.9.1. 解决多附件错误

当节点崩溃或立即关闭时,预期会从节点卸载附加的 ReadWriteOnce(RWO)卷,以便被调度到另一节点上的 pod 使用。但是,不可能在新节点中挂载,因为失败的节点无法卸载附加的卷。报告了一个 multi-attach 错误：

Unable to attach or mount volumes: unmounted volumes=[sso-mysql-pvol], unattached volumes=[sso-mysql-pvol default-token-x4rzc]: timed out waiting for the condition
Multi-Attach error for volume "pvc-8837384d-69d7-40b2-b2e6-5df86943eef9" Volume is already used by pod(s) sso-mysql-1-ns6b4

要解决 multi-attach 问题,请使用以下解决方案之一：使用 RWX 卷启用多个附件。对于大多数存储解决方案,您可以使用 ReadWriteMany(RWX)卷以防止多附加错误。使用 RWO 卷时,恢复或删除故障节点。对于不支持 RWX 的存储,如 VMware vSphere,必须改为使用 RWO 卷。但是, RWO 卷无法挂载到多个节点上。如果您遇到带有 RWO 卷的多附件错误消息，请强制在关闭或崩溃的节点上删除 pod，以避免关键工作负载中的数据丢失，例如在附加动态持久性卷时。

$ oc delete pod <old_pod> --force=true --grace-period=0

该命令会在 6 分钟后删除处于关闭或崩溃的节点上的卷。

7.10. Windows 容器工作负载问题故障排除

7.10.1. 没有安装 Windows Machine Config Operator

如果已完成了安装 Windows Machine Config Operator（WMCO）的过程，但 Operator 一直处于 InstallWaiting 阶段，问题可能是由网络问题造成的。 WMCO 要求使用 OVN-Kubernetes 配置 OpenShift Container Platform 集群和混合网络。WMCO 在没有混合网络的情况下无法完成安装过程。这是管理多个操作系统（OS）和 OS 变体的节点所必需的。这必须在集群安装过程中完成。如需更多信息，请参阅配置混合网络。

7.10.2. 检查为什么 Windows 机器没有成为计算节点

Windows 机器没有成为计算节点的原因有很多。调查此问题的最佳方法是收集 Windows Machine Config Operator（WMCO）日志。已使用 Operator Lifecycle Manager（OLM）安装 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。运行以下命令来收集 WMCO 日志：

$ oc logs -f deployment/windows-machine-config-operator -n openshift-windows-machine-config-operator

7.10.3. 访问 Windows 节点

Windows 节点无法使用 oc debug node 命令访问 ; 命令需要在该节点上运行特权 pod，但 Windows 还不支持这个 pod。可以使用 SSH 或 Remote Desktop Protocol（RDP）访问 Windows 节点。两种方法都需要一个 SSH 堡垒。

7.10.3.1. 使用 SSH 访问 Windows 节点

您可以使用 SSH 访问 Windows 节点。已使用 Operator Lifecycle Manager（OLM）安装了 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。您已将 cloud-private-key secret 中使用的密钥以及创建集群时使用的密钥添加到 ssh-agent。为安全起见，请记住在使用后从 ssh-agent 中删除密钥。已使用 ssh-bastion pod 连接到 Windows 节点。运行以下命令来访问 Windows 节点：

$ ssh -t -o StrictHostKeyChecking=no -o ProxyCommand='ssh -A -o StrictHostKeyChecking=no \
    -o ServerAliveInterval=30 -W %h:%p core@$(oc get service --all-namespaces -l run=ssh-bastion \
    -o go-template="{{ with (index (index .items 0).status.loadBalancer.ingress 0) }}{{ or .hostname .ip }}{{end}}")' <username>@<windows_node_internal_ip> 1 2

1: 指定云供应商用户名，如 Amazon Web Services(AWS)的 Administrator 或 Microsoft Azure 的 capi 。指定节点的内部 IP 地址，可通过运行以下命令来发现该地址：

$ oc get nodes <node_name> -o jsonpath={.status.addresses[?\(@.type==\"InternalIP\"\)].address}

7.10.3.2. 使用 RDP 访问 Windows 节点

您可以使用 Remote Desktop Protocol（RDP）访问 Windows 节点。已使用 Operator Lifecycle Manager（OLM）安装 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。您已将 cloud-private-key secret 中使用的密钥以及创建集群时使用的密钥添加到 ssh-agent。为安全起见，请记住在使用后从 ssh-agent 中删除密钥。已使用 ssh-bastion pod 连接到 Windows 节点。运行以下命令设定 SSH tunnel：

$ ssh -L 2020:<windows_node_internal_ip>:3389 \ 1
    core@$(oc get service --all-namespaces -l run=ssh-bastion -o go-template="{{ with (index (index .items 0).status.loadBalancer.ingress 0) }}{{ or .hostname .ip }}{{end}}")

1: 指定节点的内部 IP 地址，可通过运行以下命令来发现该地址：

$ oc get nodes <node_name> -o jsonpath={.status.addresses[?\(@.type==\"InternalIP\"\)].address}

在生成的 shell 中 SSH 到 Windows 节点，并运行以下命令为用户创建密码：

C:\> net user <username> * 1

1: 指定云供应商用户名，如 AWS 的 Administrator 或 Azure 的 capi 。现在您可以使用 RDP 客户端在 localhost:2020 远程访问 Windows 节点。

7.10.4. 为 Windows 容器收集 Kubernetes 节点日志

Windows 容器日志记录与 Linux 容器日志记录不同，Windows 工作负载的 Kubernetes 节点日志默认流传输至 C:\var\logs 目录。因此，您必须从该目录中收集 Windows 节点日志。已使用 Operator Lifecycle Manager（OLM）安装 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。要在 C:\var\logs 中的所有目录中查看日志，请运行以下命令：

$ oc adm node-logs -l kubernetes.io/os=windows --path= \
    /ip-10-0-138-252.us-east-2.compute.internal containers \
    /ip-10-0-138-252.us-east-2.compute.internal hybrid-overlay \
    /ip-10-0-138-252.us-east-2.compute.internal kube-proxy \
    /ip-10-0-138-252.us-east-2.compute.internal kubelet \
    /ip-10-0-138-252.us-east-2.compute.internal pods

您现在可以使用同样的命令列出目录中的文件并查看单个日志文件。例如，要查看 kubelet 日志，请运行以下命令：

$ oc adm node-logs -l kubernetes.io/os=windows --path=/kubelet/kubelet.log

7.10.5. 收集 Windows 应用程序事件日志

kubelet logs 端点上的 Get-WinEvent shim 可用于从 Windows 机器收集应用程序事件日志。已使用 Operator Lifecycle Manager（OLM）安装 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。要查看所有应用程序日志记录到 Windows 机器上的事件日志的日志，请运行：

$ oc adm node-logs -l kubernetes.io/os=windows --path=journal

使用 oc adm must-gather 收集日志时执行同样的命令。还可以通过使用 -u 标志指定相应服务来收集来自事件日志的其它 Windows 应用程序日志。例如，您可以运行以下命令来收集 docker runtime 服务的日志：

$ oc adm node-logs -l kubernetes.io/os=windows --path=journal -u docker

7.10.6. 为 Windows 容器收集 Docker 日志

Windows Docker 服务不会将日志流传输到 stdout，而是记录到 Windows 的事件日志中。您可以查看 Docker 事件日志，以调查您认为由 Windows Docker 服务造成的问题。已使用 Operator Lifecycle Manager（OLM）安装 Windows Machine Config Operator（WMCO）。您已创建了 Windows 机器集。 SSH 到 Windows 节点并输入 PowerShell:

C:\> powershell

运行以下命令来查看 Docker 日志：

C:\> Get-EventLog -LogName Application -Source Docker

7.10.7. 其他资源

Windows 容器的故障排除排除主机和容器镜像不匹配的问题用于 Windows 故障排除的 Docker Windows 中的常见 Kubernetes 问题

7.11. 调查监控问题

OpenShift Container Platform 包括一个预配置、预安装和自我更新的监控堆栈，用于监控核心平台组件。在 OpenShift Container Platform 4.8 中，集群管理员可以选择性地为用户定义的项目启用监控。如果您自己的指标不可用，或者 Prometheus 消耗了大量磁盘空间，则可按照以下步骤操作。

7.11.1. 检查为什么用户定义的指标不可用

通过 ServiceMonitor 资源，您可以确定如何使用用户定义的项目中的服务公开的指标。如果您创建了 ServiceMonitor 资源，但无法在 Metrics UI 中看到任何对应的指标，请按该流程中所述的步骤操作。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI（ oc ）。您已为用户定义的工作负载启用并配置了监控。您已创建了 user-workload-monitoring-config ConfigMap 对象。您已创建了 ServiceMonitor 资源。在服务和 ServiceMonitor 资源配置中 检查对应的标签是否匹配 。获取服务中定义的标签。以下示例在 ns1 项目中查询 prometheus-example-app 服务：

$ oc -n ns1 get service prometheus-example-app -o yaml

输出示例

  labels:
    app: prometheus-example-app

检查


                     ServiceMonitor

资源配置中的


                     matchLabels

app

标签是否与上一步中的标签输出匹配：

$ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

输出示例

spec:
  endpoints:
  - interval: 30s
    port: web
    scheme: http
  selector:
    matchLabels:
      app: prometheus-example-app

您可以作为具有项目查看权限的开发者检查服务和


                      ServiceMonitor

资源标签。在


                      openshift-user-workload-monitoring

项目中 检查 Prometheus Operator 的日志 。列出


                      openshift-user-workload-monitoring

项目中的 Pod：

$ oc -n openshift-user-workload-monitoring get pods

输出示例

NAME                                   READY   STATUS    RESTARTS   AGE
prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
prometheus-user-workload-0             5/5     Running   1          132m
prometheus-user-workload-1             5/5     Running   1          132m
thanos-ruler-user-workload-0           3/3     Running   0          132m
thanos-ruler-user-workload-1           3/3     Running   0          132m

从


                       prometheus-operator

Pod 中的


                       prometheus-operator

容器获取日志。在以下示例中，Pod 名为


                       prometheus-operator-776fcbbd56-2nbfm

：

$ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

如果服务监控器出现问题，日志可能包含类似本例的错误：

level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

直接在 Prometheus UI 中 查看项目的目标状态 。建立端口转发到 openshift-user-workload-monitoring 项目中的 Prometheus 实例：

$ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090

在 Web 浏览器中打开 http://localhost:9090/targets ，并在 Prometheus UI 中直接查看项目的目标状态。检查与目标相关的错误消息。在


                       openshift-user-workload-monitoring

项目中 为 Prometheus Operator 配置 debug 级别的日志记录 。在


                       openshift-user-workload-monitoring

项目中编辑


                       user-workload-monitoring-config


                       ConfigMap

对象：

$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

在 data/config.yaml 下为 prometheusOperator 添加 logLevel: debug ，将日志级别设置为 debug ：

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheusOperator:
      logLevel: debug

保存文件以使改变生效。在应用日志级别更改时， openshift-user-workload-monitoring 项目中的 prometheus-operator 会自动重启。确认 debug 日志级别已应用到 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署：

$ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

输出示例

        - --log-level=debug

Debug 级别日志记录将显示 Prometheus Operator 发出的所有调用。检查


                        prometheus-operator

Pod 是否正在运行：

$ oc -n openshift-user-workload-monitoring get pods

注意

如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值，则 prometheus-operator Pod 可能无法成功重启。查看 debug 日志，以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。创建用户定义的工作负载监控配置映射如需有关如何创建 ServiceMonitor 或 PodMonitor 的详细信息，请参阅指定如何监控服务

7.11.2. 确定为什么 Prometheus 消耗大量磁盘空间

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如， customer_id 属性不绑定，因为它有无限多个可能的值。每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能，并消耗大量磁盘空间。当 Prometheus 消耗大量磁盘时，您可以使用以下方法： 检查正在收集的提取示例数量 。 检查 Prometheus UI 中的时间序列数据库（TSDB）状态 以了解有关哪些标签创建最多时间序列的更多信息。这需要集群管理员特权。要 减少创建的唯一时间序列数量 ，您可以减少分配给用户定义的指标的未绑定属性数量。使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。 对可在用户定义的项目中提取的示例数量实施限制 。这需要集群管理员特权。您可以使用具有 cluster-admin 角色的用户访问集群。已安装 OpenShift CLI( oc )。在 Administrator 视角中，导航到 Monitoring → Metrics 。在 Expression 字段中运行以下 Prometheus Query Language (PromQL) 查询。这会返回具有最高提取示例数的十个指标：

topk(10,count by (job)({__name__=~".+"}))

如果指标的提取示例数大于预期，请检查分配给指标的未绑定标签值数量。 如果指标与用户定义的项目相关 ，请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。 如果指标与 OpenShift Container Platform 核心项目相关 ，请在红帽客户门户网站上创建一个红帽支持问题单。检查 Prometheus UI 中的 TSDB 状态。在 Administrator 视角中，导航至 Networking → Routes 。选择 Project 列表中的 openshift-monitoring 项目。选择 prometheus-k8s 行中的 URL 来打开 Prometheus UI 的登录页面。选择 Log in with OpenShift 来使用您的 OpenShift Container Platform 凭证进行登录。在 Prometheus UI 中，进入到 Status → TSDB Status 。如需有关如何设置提取示例限制和创建相关警报规则的详细信息，请参阅为用户定义的项目设置提取示例限制

7.12. 诊断 OpenShift CLI（ `oc` ）问题

7.12.1. 了解 OpenShift CLI（ `oc` ）日志级别

借助 OpenShift CLI（ oc ），您可以从终端创建应用程序并管理 OpenShift Container Platform 项目。如果出现特定于 oc 命令的问题，将 oc 日志级别提高为输出 API 请求、API 响应以及命令生成的 curl 请求详情。这提供了特定的 oc 命令的底层操作信息，以帮助您了解故障的本质。 oc 日志级别范围从 1 到 10。下表提供了 oc 日志级别列表及其描述。

表 7.3. OpenShift CLI（oc）日志级别
日志级别	描述
1 到 5 没有额外的日志记录到 stderr。为 stderr 记录 API 请求。将 API 请求和标头记录到 stderr。记录 API 请求、标头和正文，以及 API 响应标头和正文到 stderr。记录日志 API 请求、标头和正文、API 响应标头和正文，以及 `curl` 请求到 stderr。记录日志 API 请求、标头和正文、API 响应标头和正文，以及 `curl` 请求到 stderr。记录的信息会更详细。

7.12.2. 指定 OpenShift CLI（ `oc` ）日志级别

您可以通过提高命令的日志级别来调查 OpenShift CLI（ oc ）问题。安装 OpenShift CLI ( oc ) 。在运行 oc 命令时指定 oc 日志级别：

$ oc <options> --loglevel <log_level>

OpenShift Container Platform 用户的当前会话令牌通常包含在记录的 curl 请求中。您还可以手动获取当前用户的会话令牌，以便在测试 oc 命令的底层进程的各个方面时使用：

$ oc whoami -t

法律通告

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

支持

获取 OpenShift Container Platform 支持

第 1 章 支持概述

1.1. 获得支持

1.2. 远程健康监控问题

1.3. 收集有关集群的数据

1.4. 故障排除问题

第 2 章 管理集群资源

2.1. 与集群资源交互

第 3 章 获取支持

3.1. 获取支持

3.2. 关于红帽知识库

3.3. 搜索红帽知识库

3.4. 提交支持问题单

3.5. 其他资源

第 4 章 通过连接集群进行远程健康监控

4.1. 关于远程健康监控

4.1.1. 关于 Telemetry

4.1.1.1. Telemetry 收集的信息

4.1.2. 关于 Insights Operator

4.1.2.1. Insights Operator 收集的信息

4.1.3. 了解 Telemetry 和 Insights Operator 数据流

4.1.4. 有关如何使用远程健康监控数据的更多详情

4.2. 显示远程健康监控收集的数据

4.2.1. 显示 Telemetry 收集的数据

4.2.2. 显示 Insights Operator 收集的数据

4.3. 不使用远程健康报告功能

4.3.1. 禁用远程健康报告的后果

4.3.2. 修改全局集群 pull secret，以禁用远程健康报告

4.3.3. 更新全局集群 pull secret

4.4. 使用 Insights 发现集群中的问题

4.4.1. 关于 OpenShift Container Platform 的 Red Hat Insights Advisor

4.4.2. 了解 Insights Advisor 建议

4.4.3. 显示集群中的潜在问题

4.4.4. 显示所有 Insights Advisor 建议

4.4.5. 禁用 Insights Advisor 建议

4.4.6. 启用之前禁用的 Insights Advisor 建议

4.4.7. 在 web 控制台中显示 Insights 状态

4.5. 使用 Insights Operator

4.5.1. 下载 Insights Operator 存档

4.5.2. 查看 Insights Operator 收集持续时间

4.6. 在受限网络中使用远程健康报告

4.6.1. 运行 Insights Operator 收集操作

4.6.2. 上传 Insights Operator 存档

4.6.3. 启用 Insights Operator 数据模糊处理

第 5 章 收集集群数据

5.1. 关于 must-gather 工具

5.1.1. 为红帽支持收集您的集群数据

5.1.2. 收集有关特定功能的数据

5.1.3. 收集审计日志

5.2. 获取集群 ID

5.3. 关于 sosreport

5.4. 为 OpenShift Container Platform 集群节点生成 sosreport 归档

5.5. 查询 bootstrap 节点日志

5.6. 查询集群节点 journal 日志

5.7. 从 OpenShift Container Platform 节点或容器收集网络追踪（trace）

5.8. 为红帽支持提供诊断数据

5.9. 关于 toolbox

将软件包安装到 toolbox 容器

使用 toolbox 启动备用镜像

第 6 章 集群规格总结

6.1. 通过 clusterversion 总结集群规格

第 7 章 故障排除

7.1. 安装故障排除

7.1.1. 确定安装问题在哪里发生

7.1.2. 用户置备的基础架构安装注意事项

7.1.3. 在 OpenShift Container Platform 安装前检查负载均衡器配置

7.1.4. 指定 OpenShift Container Platform 安装程序日志级别

7.1.5. openshift-install 命令问题故障排除

7.1.6. 监控安装进度

7.1.7. 收集 bootstrap 节点诊断数据

7.1.8. 调查 control plane 节点安装问题

7.1.9. 解决 etcd 安装问题

7.1.10. 调查 control plane 节点 kubelet 和 API 服务器问题

7.1.11. 调查 worker 节点安装问题

7.1.12. 安装后查询 Operator 状态

7.1.13. 从失败安装中收集日志

7.1.14. 其他资源

7.2. 验证节点健康状况

7.2.1. 查看节点状态、资源使用量和配置

第 1 章支持概述

第 2 章管理集群资源

第 3 章获取支持

第 4 章通过连接集群进行远程健康监控

第 5 章收集集群数据

5.9. 关于 `toolbox`

将软件包安装到 `toolbox` 容器

使用 `toolbox` 启动备用镜像

第 6 章集群规格总结

6.1. 通过 `clusterversion` 总结集群规格

第 7 章故障排除

7.12. 诊断 OpenShift CLI（ `oc` ）问题

7.12.1. 了解 OpenShift CLI（ `oc` ）日志级别

7.12.2. 指定 OpenShift CLI（ `oc` ）日志级别