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

支持

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS 支持。

Red Hat OpenShift Documentation Team

摘要

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

第 1 章 支持概述
复制链接

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

1.1. 获得支持
复制链接

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

1.2. 远程健康监控问题
复制链接

远程健康监控问题 ：Red Hat OpenShift Service on AWS 会收集有关集群的遥测和配置数据，并使用 Telemeter Client 和 Insights Operator 向红帽报告。红帽使用此数据了解并解决 连接的集群中的问题。Red Hat OpenShift Service on AWS 会使用以下方法收集数据并监控健康状况：

  • Telemetry ：遥测客户端收集并每 4 分 30 秒将标值上传至红帽。红帽将此数据用于：

    • 监控集群。
    • 推出 Red Hat OpenShift Service on AWS 升级。
    • 改进升级体验。

  • Insights Operator ：默认情况下，Red Hat OpenShift Service on AWS 安装并启用 Insights Operator，每两小时报告配置和组件故障状态。Insights Operator 有助于：

    • 主动识别潜在的集群问题。
    • 在 Red Hat OpenShift Cluster Manager 中提供解决方案和预防性操作。

您可以查看遥测信息。

1.3. 收集有关集群的数据
复制链接

收集有关集群的数据 ：红帽建议在打开支持问题单时收集您的调试信息。这有助于红帽支持执行根本原因分析。集群管理员可以使用以下方法收集有关集群的数据：

  • must-gather 工具 ：使用 must-gather 工具来收集有关集群的信息并调试问题。
  • sosreport ：使用 sosreport 工具收集配置详情、系统信息和诊断数据用于调试目的。
  • 集群 ID ：在向红帽支持提供信息时，获取集群的唯一标识符。
  • 集群节点 journal 日志 ：收集 journald 单元日志和独立集群节点上的 /var/log 中的日志，以排除与节点相关的问题。
  • 网络追踪 ：从特定 Red Hat OpenShift Service on AWS 集群或容器提供给红帽支持提供网络数据包追踪，以帮助排除与网络相关的问题。

1.4. 故障排除问题
复制链接

集群管理员可以监控并排除以下 Red Hat OpenShift Service on AWS 组件问题：

  • 节点问题 ：集群管理员可以通过查看节点的状态、资源使用量和配置来验证和排除节点相关问题。您可以查询以下内容：

    • 节点上的 kubelet 状态。
    • 集群节点日志.

  • 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 消耗大量磁盘空间。

第 2 章 管理集群资源
复制链接

您可以在 Red Hat OpenShift Service on AWS 中应用全局配置选项。Operator 在集群中应用这些配置设置。

2.1. 与集群资源交互
复制链接

您可以使用 Red Hat OpenShift Service on AWS 中的 OpenShift CLI (oc)工具与集群资源交互。运行 oc api-resources 命令后看到的集群资源可以被编辑。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 您可以访问 web 控制台或已安装了 oc CLI 工具。

流程

  1. 要查看应用了哪些配置 Operator，请运行以下命令： 

    $ oc api-resources -o name | grep config.openshift.io
    Copy to Clipboard Toggle word wrap

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

    $ oc explain <resource_name>.config.openshift.io
    Copy to Clipboard Toggle word wrap

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

    $ oc get <resource_name>.config -o yaml
    Copy to Clipboard Toggle word wrap

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

    $ oc edit <resource_name>.config -o yaml
    Copy to Clipboard Toggle word wrap

第 3 章 批准的访问
复制链接

Red Hat Site Reliability Engineering (SRE)通常不需要升级对系统的访问，作为管理和支持 Red Hat OpenShift Service on AWS 集群的一部分。提升访问提供了 cluster-admin 角色的访问级别。如需更多信息，请参阅 集群角色。

如果 SRE 需要升级对系统的访问，您可以使用 Approved Access 界面 审核和批准 对这些系统的访问。

升级对 Red Hat OpenShift Service on AWS 集群上的集群的访问请求，由 SRE 创建对应的云帐户，以响应客户发起的支持票据，或者响应 SRE 收到的警报作为标准事件响应过程的一部分。

当启用了 Approved Access 且 SRE 创建访问 请求时，集群所有者 会收到电子邮件通知，通知他们新的访问请求。电子邮件通知包含一个链接，允许集群所有者快速批准或拒绝访问请求。您必须及时响应，否则 Red Hat OpenShift Service on AWS 对 SLA 有风险。

  • 如果客户要求其他用户不是集群所有者才能接收电子邮件，他们可以 添加通知集群联系人。
  • 待处理的访问请求位于集群列表或特定集群的 Access Requests 选项卡中。
注意

拒绝访问请求要求您完成 Justification 字段。在这种情况下，SRE 无法直接对与事件相关的资源进行操作。客户仍然可以使用 客户支持 来帮助调查和解决问题。

默认情况下，Red Hat OpenShift Service on AWS Approved Access 不会被启用。要为 Red Hat OpenShift Service on AWS 集群启用 批准访问，您应该创建一个支持问题单。

流程

  1. 登录到红帽客户门户网站的 客户支持 页面。
  2. 点 Get support。

  3. 在 客户支持 页面的 Cases 选项卡中：

    1. 可选：根据需要更改预先填充的帐户和所有者详情。
    2. 选择 Configuration 类别，再单击 Continue。

  4. 输入以下信息：

    1. 在 Product 字段中，选择 Red Hat OpenShift Service on AWS Hosted control plane。
    2. 在 Problem 语句 字段中，输入 Enable ROSA Access Protection。
    3. 单击 查看更多选项。
  5. 从下拉列表中选择 OpenShift Cluster ID。

  6. 以以下形式填写剩余的必填字段：

    1. 您遇到什么情况？您期望发生什么情况？

      1. 填写 批准访问。

    2. 对业务的影响价值。

      1. 填写 批准访问。
    3. 点 Continue。
  7. 选择 Severity 为 4 (Low)，然后单击 Continue。
  8. 预览问题单详情，点 Submit。

3.2. 查看电子邮件通知的访问请求
复制链接

当 Red Hat Site Reliability Engineering (SRE)请求访问其集群时，集群所有者会收到电子邮件通知，其中包含一个链接来查看混合云控制台中的请求。

流程

  1. 点击电子邮件中的链接为您提供混合云控制台。

  2. 在 Access Request Details 对话框中，单击 Decision 下的 Approve 或 Deny。

    注意

    拒绝访问请求要求您完成 Justification 字段。在这种情况下，SRE 无法直接对与事件相关的资源进行操作。客户仍然可以使用 客户支持 来帮助调查和解决问题。

  3. 点击 Save。

3.3. 从 Hybrid Cloud 控制台查看访问请求
复制链接

从 Hybrid Cloud Console 查看对 Red Hat OpenShift Service on AWS 集群的访问请求。

流程

  1. 导航到 OpenShift Cluster Manager，再选择 Cluster List。
  2. 点集群名称查看 Access Request。
  3. 选择 Access Requests 选项卡，以列出所有 状态。
  4. 在 Actions for Pending 状态下选择 Open。

  5. 在 Access Request Details 对话框中，单击 Decision 下的 Approve 或 Deny。

    注意

    拒绝访问请求要求您完成 Justification 字段。在这种情况下，SRE 无法直接对与事件相关的资源进行操作。客户仍然可以使用 客户支持 来帮助调查和解决问题。

  6. 点击 Save。

第 4 章 获取支持
复制链接

4.1. 获取支持
复制链接

如果您在执行本文档所述的某个流程或 Red Hat OpenShift Service on AWS 时遇到问题，请访问 红帽客户门户网站。

通过红帽客户门户网站：

  • 搜索或者浏览红帽知识库，了解与红帽产品相关的文章和解决方案。
  • 提交问题单给红帽支持。
  • 访问其他产品文档。

要识别集群中的问题，您可以在 OpenShift Cluster Manager 中使用 Insights。Insights 提供了问题的详细信息，并在有可用的情况下，提供了如何解决问题的信息。

如果您对本文档有任何改进建议，或发现了任何错误，请为相关文档组件提交 JIRA 问题。请提供具体详情，如章节名称和 Red Hat OpenShift Service on AWS 版本。

4.2. 关于红帽知识库
复制链接

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

4.3. 搜索红帽知识库
复制链接

如果出现 Red Hat OpenShift Service on AWS 问题，您可以先进行搜索，以确定红帽知识库中是否已存在相关的解决方案。

先决条件

  • 您有红帽客户门户网站帐户。

流程

  1. 登录到 红帽客户门户网站。
  2. 点 Search。

  3. 在搜索字段中，输入与问题相关的关键字和字符串，包括：

    • Red Hat OpenShift Service on AWS 组件（如 etcd）
    • 相关步骤（比如 安装）
    • 警告、错误消息和其他与输出与特定的问题相关
  4. 点 Enter 键。
  5. 可选： 选择 Red Hat OpenShift Service on AWS 产品过滤器。
  6. 可选： 选择 Documentation 内容类型过滤器。

4.4. 提交支持问题单
复制链接

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您可以访问 Red Hat OpenShift Cluster Manager。

流程

  1. 登录到红帽客户门户网站的客户支持 页面。
  2. 点 Get support。

  3. 在 客户支持 页面的 Cases 选项卡中：

    1. 可选：根据需要更改预先填充的帐户和所有者详情。
    2. 为您的问题选择适当的类别，如 Bug 或 Defect，然后点 Continue。

  4. 输入以下信息：

    1. 在 Summary 字段中，输入简要但描述性问题概述，以及有关所经历的症状的详细信息，以及您的预期。
    2. 从 Product 下拉菜单中选择 Red Hat OpenShift Service on AWS。
  5. 查看推荐的红帽知识库解决方案列表，它们可能会与您要报告的问题相关。如果建议的文章没有解决这个问题，请点 Continue。
  6. 查看更新的推荐红帽知识库解决方案列表，它们可能会与您要报告的问题相关。这个列表的范围会缩小，因为您在创建问题单的过程中提供了更多信息。如果建议的文章没有解决这个问题，请点 Continue。
  7. 请确保提供的帐户信息是正确的，如果需要，请相应调整。

  8. 检查自动填充的 Red Hat OpenShift Service on AWS 集群 ID 是否正确。如果不正确，请手动提供集群 ID。

    • 使用 Red Hat OpenShift Service on AWS Web 控制台手动获得集群 ID：

      1. 进入到 Home → Overview。
      2. 该值包括在 Details 中的 Cluster ID 项中。

    • 另外，也可以通过 Red Hat OpenShift Service on AWS Web 控制台直接创建新的支持问题单，并自动填充集群 ID。

      1. 从工具栏导航至 （？）help → Open Support Case。
      2. Cluster ID 的值会被自动填充 。

    • 要使用 OpenShift CLI（oc）获取集群 ID，请运行以下命令： 

      $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
      Copy to Clipboard Toggle word wrap

  9. 完成以下提示的问题，点 Continue:

    • 您遇到什么情况？您期望发生什么情况？
    • 对业务的影响价值。
    • 您在哪里遇到此行为？什么环境？
    • 此行为何时发生？发生频率？重复发生？是否只在特定时间发生？
  10. 上传相关的诊断数据文件并点击 Continue。
  11. 输入相关问题单管理详情，点 Continue。
  12. 预览问题单详情，点 Submit。

第 5 章 通过连接集群进行远程健康监控
复制链接

5.1. 关于远程健康监控
复制链接

Red Hat OpenShift Service on AWS 会收集有关集群的遥测和配置数据，并使用 Telemeter Client 和 Insights Operator 向红帽报告。提供给红帽的数据可实现本文档概述的好处。

通过 Telemetry 和 Insights Operator 向红帽报告数据的集群被称为连接的集群 (connected cluster)。

Telemetry 是红帽用来描述 Red Hat OpenShift Service on AWS Telemeter 客户端向红帽发送的信息的术语。轻量级属性从连接的集群发送到红帽，以便启用订阅管理自动化、监控集群的健康状态、提供支持以及改进客户体验。

Insights Operator 收集 Red Hat OpenShift Service on AWS 配置数据并将其发送到红帽。这些数据用于生成有关集群可能潜在存在的问题的分析报告。这些 insights 通过 OpenShift Cluster Manager 与集群管理员进行交流。

本文档中提供了有关这两个工具的更多信息。

Telemetry 和 Insights Operator 的优点

Telemetry 和 Insights Operator 为最终用户提供以下优点：

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

在 Red Hat OpenShift Service on AWS 上，远程健康报告总是启用。您不能选择不使用它。

5.1.1. 关于 Telemetry
复制链接

Telemetry 会向红帽发送一组精选的集群监控指标子集。Telemeter 客户端每四分三十秒获取一次指标值，并将数据上传到红帽。本文档中描述了这些指标。

红帽使用这一数据流来实时监控集群，必要时将对影响客户的问题做出反应。它还允许红帽向客户推出 Red Hat OpenShift Service on AWS 升级，以便最大程度降低服务影响，持续改进升级体验。

这类调试信息将提供给红帽支持和工程团队，其访问限制等同于访问通过问题单报告的数据。红帽利用所有连接集群信息来帮助改进 Red Hat OpenShift Service on AWS，并更直观地使用。

5.1.1.1. Telemetry 收集的信息
复制链接

Telemetry 收集以下信息：

5.1.1.1.1. 系统信息
复制链接
  • 版本信息，包括 Red Hat OpenShift Service on AWS 集群版本并安装了用来决定更新版本可用性的更新详情
  • 更新信息，包括每个集群可用的更新数、用于更新的频道和镜像存储库、更新进度信息以及更新中发生的错误数
  • 安装期间生成的唯一随机标识符
  • 帮助红帽支持为客户提供有用支持的配置详情，包括云基础架构级别的节点配置、主机名、IP 地址、Kubernetes pod 名称、命名空间和服务
  • 在集群中安装的 Red Hat OpenShift Service on AWS 框架组件及其状况和状态
  • 为降级 Operator 列出为 "related objects" 的所有命名空间的事件
  • 有关降级软件的信息
  • 有关证书的有效性的信息
  • 部署 Red Hat OpenShift Service on AWS 的供应商平台的名称以及数据中心位置
5.1.1.1.2. 大小信息
复制链接
  • 有关集群、机器类型和机器的大小信息，包括 CPU 内核数和每个机器所使用的 RAM 量
  • etcd 成员数和存储在 etcd 集群中的对象数量
  • 根据构建策略类型进行应用构建数量
5.1.1.1.3. 使用信息
复制链接
  • 有关组件、功能和扩展的使用情况信息
  • 有关技术预览和不受支持配置的使用详情

Telemetry 不会收集任何身份识别的信息，如用户名或密码。红帽不会收集个人信息。如果红帽发现个人信息被意外地收到，红帽会删除这些信息。有关红帽隐私实践的更多信息，请参考红帽隐私声明。

5.1.1.2. 用户 Telemetry
复制链接

红帽从浏览器收集匿名用户数据。这种匿名数据包括启用了遥测功能的所有集群的用户的页面、功能和资源类型。

其他注意事项：

  • 用户事件被，作为一个 SHA-1 哈希。
  • 用户的 IP 地址保存为 0.0.0.0。
  • 用户名和 IP 地址永远不会保存为单独的值。

5.1.2. 关于 Insights Operator
复制链接

Insights Operator 会定期收集配置和组件故障状态信息，默每两小时向红帽报告这些数据。这些信息可让红帽评估配置，它提供了比 Telemetry 报告更深入的数据。

Red Hat OpenShift Service on AWS 用户可以在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中显示每个集群的报告。如果发现了任何问题，Insights 会提供更详细的信息，并在可能的情况下提供如何解决相关问题的步骤。

Insights Operator 不会收集任何身份识别信息，如用户名、密码或证书。如需有关 Red Hat Insights 数据收集和控制的信息，请参阅 Red Hat Insights 数据和应用程序安全性。

红帽使用所有连接的集群信息以实现：

  • 识别潜在的集群问题，并在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中提供解决方案和防止操作
  • 通过为产品和支持团队提供聚合和重要信息来改进 Red Hat OpenShift Service on AWS
  • 使 Red Hat OpenShift Service on AWS 更直观
5.1.2.1. Insights Operator 收集的信息
复制链接

Insights Operator 收集以下信息：

  • 有关集群及其组件的常规信息，以识别特定于 Red Hat OpenShift Service on AWS 版本和环境的问题。
  • 集群的配置文件（如镜像 registry 配置）来确定设置参数不正确的设置和问题。
  • 集群组件中发生的错误。
  • 运行更新的进度信息，以及任何组件升级的状态。
  • 有关部署 Red Hat OpenShift Service on AWS 的平台以及集群所在区域的详情
  • 集群工作负载信息转换为离散的安全哈希算法(SHA)值，这可让红帽评估工作负载以了解安全性和版本漏洞，而不会暴露敏感详情。
  • 有关操作系统和运行时环境的工作负载信息，包括运行时类型、名称和版本。通过这些数据，红帽可以更好地了解您在 AWS 容器上使用 Red Hat OpenShift Service，以便我们主动帮助您做出投资决策来驱动最佳利用率。
  • 如果 Operator 报告了一个问题，则会收集 openshift channel 和 kube [1] 项目中的 Red Hat OpenShift Service on AWS 核心 pod 的信息。这包括状态、资源、安全上下文、卷信息等。

5.1.3. 了解 Telemetry 和 Insights Operator 数据流
复制链接

Telemeter Client 从 Prometheus API 收集所选的时间序列数据。时间序列数据每 4 分 30 秒上传到 api.openshift.com 进行处理。

Insights Operator 从 Kubernetes API 和 Prometheus API 中收集所选的数据并进行存档。该归档每两小时上传到 OpenShift Cluster Manager 进行处理。Insights Operator 还从 OpenShift Cluster Manager 下载最新的 Insights 分析。这用于填充 Red Hat OpenShift Service on AWS Web 控制台的 Overview 页面中的 Insights 状态 弹出窗口。

所有与红帽的通信都使用传输层安全（TLS）和 mutual 证书验证通过加密频道进行。所有数据在传输及非活跃的情况下都会被加密。

对处理客户数据的系统是通过多因素验证和严格的授权控制来控制的。访问权限的设置是基于需要的，仅限于针对需要的操作。

telemetry 和 Insights Operator 数据流

Telemetry and Insights Operator data flow

Telemetry 收集的信息和Insights Operator 收集的信息中提供了与启用健康检查健康相关的数据收集的信息。

如本文档前面部分所述，红帽会收集您使用红帽产品的数据，如提供支持和升级、优化性能或配置、减小服务影响、识别和补救威胁、故障排除、改进提供和用户体验、响应问题、根据情况提供账单目的。

集合保护

红帽采用一些技术和机构措施来保护遥测数据和配置数据。

共享

红帽可以在红帽内部通过 Telemetry 和 Insights Operator 共享收集的数据，以提升您的用户体验。红帽可能会以汇总的方式与业务合作伙伴共享遥测和配置数据，该表格可帮助合作伙伴更好地了解其业务及其客户对红帽产品的使用，或者确保成功整合这些合作伙伴支持的产品。

第三方

红帽可能会与某些第三方合作，协助收集、分析和存储遥测和配置数据。

5.2. 显示远程健康监控收集的数据
复制链接

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

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

5.2.1. 显示 Telemetry 收集的数据
复制链接

您可以查看 Telemetry 收集的集群和组件的时间序列数据。

前提条件

  • 已安装 OpenShift Container Platform CLI (oc)。
  • 您可以使用具有 dedicated-admin 角色的用户访问集群。

流程

  1. 登录到集群。
  2. 运行以下命令，它会查询集群的 Prometheus 服务并返回由 Telemetry 收集的完整时间序列数据集合：
注意

以下示例包含特定于 AWS 上的 Red Hat OpenShift Service 的一些值。 

$ curl -G -k -H "Authorization: Bearer $(oc whoami -t)" \
https://$(oc get route prometheus-k8s-federate -n \
openshift-monitoring -o jsonpath="{.spec.host}")/federate \
--data-urlencode 'match[]={__name__=~"cluster:usage:.*"}' \
--data-urlencode 'match[]={__name__="count:up0"}' \
--data-urlencode 'match[]={__name__="count:up1"}' \
--data-urlencode 'match[]={__name__="cluster_version"}' \
--data-urlencode 'match[]={__name__="cluster_version_available_updates"}' \
--data-urlencode 'match[]={__name__="cluster_version_capability"}' \
--data-urlencode 'match[]={__name__="cluster_operator_up"}' \
--data-urlencode 'match[]={__name__="cluster_operator_conditions"}' \
--data-urlencode 'match[]={__name__="cluster_version_payload"}' \
--data-urlencode 'match[]={__name__="cluster_installer"}' \
--data-urlencode 'match[]={__name__="cluster_infrastructure_provider"}' \
--data-urlencode 'match[]={__name__="cluster_feature_set"}' \
--data-urlencode 'match[]={__name__="instance:etcd_object_counts:sum"}' \
--data-urlencode 'match[]={__name__="ALERTS",alertstate="firing"}' \
--data-urlencode 'match[]={__name__="code:apiserver_request_total:rate:sum"}' \
--data-urlencode 'match[]={__name__="cluster:capacity_cpu_cores:sum"}' \
--data-urlencode 'match[]={__name__="cluster:capacity_memory_bytes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="cluster:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="openshift:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="openshift:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="workload:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="workload:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:virt_platform_nodes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:node_instance_type_count:sum"}' \
--data-urlencode 'match[]={__name__="cnv:vmi_status_running:count"}' \
--data-urlencode 'match[]={__name__="cluster:vmi_request_cpu_cores:sum"}' \
--data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_cores:sum"}' \
--data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_sockets:sum"}' \
--data-urlencode 'match[]={__name__="subscription_sync_total"}' \
--data-urlencode 'match[]={__name__="olm_resolution_duration_seconds"}' \
--data-urlencode 'match[]={__name__="csv_succeeded"}' \
--data-urlencode 'match[]={__name__="csv_abnormal"}' \
--data-urlencode 'match[]={__name__="cluster:kube_persistentvolumeclaim_resource_requests_storage_bytes:provisioner:sum"}' \
--data-urlencode 'match[]={__name__="cluster:kubelet_volume_stats_used_bytes:provisioner:sum"}' \
--data-urlencode 'match[]={__name__="ceph_cluster_total_bytes"}' \
--data-urlencode 'match[]={__name__="ceph_cluster_total_used_raw_bytes"}' \
--data-urlencode 'match[]={__name__="ceph_health_status"}' \
--data-urlencode 'match[]={__name__="odf_system_raw_capacity_total_bytes"}' \
--data-urlencode 'match[]={__name__="odf_system_raw_capacity_used_bytes"}' \
--data-urlencode 'match[]={__name__="odf_system_health_status"}' \
--data-urlencode 'match[]={__name__="job:ceph_osd_metadata:count"}' \
--data-urlencode 'match[]={__name__="job:kube_pv:count"}' \
--data-urlencode 'match[]={__name__="job:odf_system_pvs:count"}' \
--data-urlencode 'match[]={__name__="job:ceph_pools_iops:total"}' \
--data-urlencode 'match[]={__name__="job:ceph_pools_iops_bytes:total"}' \
--data-urlencode 'match[]={__name__="job:ceph_versions_running:count"}' \
--data-urlencode 'match[]={__name__="job:noobaa_total_unhealthy_buckets:sum"}' \
--data-urlencode 'match[]={__name__="job:noobaa_bucket_count:sum"}' \
--data-urlencode 'match[]={__name__="job:noobaa_total_object_count:sum"}' \
--data-urlencode 'match[]={__name__="odf_system_bucket_count", system_type="OCS", system_vendor="Red Hat"}' \
--data-urlencode 'match[]={__name__="odf_system_objects_total", system_type="OCS", system_vendor="Red Hat"}' \
--data-urlencode 'match[]={__name__="noobaa_accounts_num"}' \
--data-urlencode 'match[]={__name__="noobaa_total_usage"}' \
--data-urlencode 'match[]={__name__="console_url"}' \
--data-urlencode 'match[]={__name__="cluster:ovnkube_master_egress_routing_via_host:max"}' \
--data-urlencode 'match[]={__name__="cluster:network_attachment_definition_instances:max"}' \
--data-urlencode 'match[]={__name__="cluster:network_attachment_definition_enabled_instance_up:max"}' \
--data-urlencode 'match[]={__name__="cluster:ingress_controller_aws_nlb_active:sum"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:min"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:max"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:avg"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:median"}' \
--data-urlencode 'match[]={__name__="cluster:openshift_route_info:tls_termination:sum"}' \
--data-urlencode 'match[]={__name__="insightsclient_request_send_total"}' \
--data-urlencode 'match[]={__name__="cam_app_workload_migrations"}' \
--data-urlencode 'match[]={__name__="cluster:apiserver_current_inflight_requests:sum:max_over_time:2m"}' \
--data-urlencode 'match[]={__name__="cluster:alertmanager_integrations:max"}' \
--data-urlencode 'match[]={__name__="cluster:telemetry_selected_series:count"}' \
--data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_series:sum"}' \
--data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_samples_appended_total:sum"}' \
--data-urlencode 'match[]={__name__="monitoring:container_memory_working_set_bytes:sum"}' \
--data-urlencode 'match[]={__name__="namespace_job:scrape_series_added:topk3_sum1h"}' \
--data-urlencode 'match[]={__name__="namespace_job:scrape_samples_post_metric_relabeling:topk3"}' \
--data-urlencode 'match[]={__name__="monitoring:haproxy_server_http_responses_total:sum"}' \
--data-urlencode 'match[]={__name__="rhmi_status"}' \
--data-urlencode 'match[]={__name__="status:upgrading:version:rhoam_state:max"}' \
--data-urlencode 'match[]={__name__="state:rhoam_critical_alerts:max"}' \
--data-urlencode 'match[]={__name__="state:rhoam_warning_alerts:max"}' \
--data-urlencode 'match[]={__name__="rhoam_7d_slo_percentile:max"}' \
--data-urlencode 'match[]={__name__="rhoam_7d_slo_remaining_error_budget:max"}' \
--data-urlencode 'match[]={__name__="cluster_legacy_scheduler_policy"}' \
--data-urlencode 'match[]={__name__="cluster_master_schedulable"}' \
--data-urlencode 'match[]={__name__="che_workspace_status"}' \
--data-urlencode 'match[]={__name__="che_workspace_started_total"}' \
--data-urlencode 'match[]={__name__="che_workspace_failure_total"}' \
--data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_sum"}' \
--data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_count"}' \
--data-urlencode 'match[]={__name__="cco_credentials_mode"}' \
--data-urlencode 'match[]={__name__="cluster:kube_persistentvolume_plugin_type_counts:sum"}' \
--data-urlencode 'match[]={__name__="visual_web_terminal_sessions_total"}' \
--data-urlencode 'match[]={__name__="acm_managed_cluster_info"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_vcenter_info:sum"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_esxi_version_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_node_hw_version_total:sum"}' \
--data-urlencode 'match[]={__name__="openshift:build_by_strategy:sum"}' \
--data-urlencode 'match[]={__name__="rhods_aggregate_availability"}' \
--data-urlencode 'match[]={__name__="rhods_total_users"}' \
--data-urlencode 'match[]={__name__="instance:etcd_disk_wal_fsync_duration_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_bytes:sum"}' \
--data-urlencode 'match[]={__name__="instance:etcd_network_peer_round_trip_time_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_use_in_bytes:sum"}' \
--data-urlencode 'match[]={__name__="instance:etcd_disk_backend_commit_duration_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_storage_types"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_strategies"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_agent_strategies"}' \
--data-urlencode 'match[]={__name__="appsvcs:cores_by_product:sum"}' \
--data-urlencode 'match[]={__name__="nto_custom_profiles:count"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_configmap"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_secret"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_mount_failures_total"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_mount_requests_total"}' \
--data-urlencode 'match[]={__name__="cluster:velero_backup_total:max"}' \
--data-urlencode 'match[]={__name__="cluster:velero_restore_total:max"}' \
--data-urlencode 'match[]={__name__="eo_es_storage_info"}' \
--data-urlencode 'match[]={__name__="eo_es_redundancy_policy_info"}' \
--data-urlencode 'match[]={__name__="eo_es_defined_delete_namespaces_total"}' \
--data-urlencode 'match[]={__name__="eo_es_misconfigured_memory_resources_info"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_data_nodes_total:max"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_documents_created_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_documents_deleted_total:sum"}' \
--data-urlencode 'match[]={__name__="pod:eo_es_shards_total:max"}' \
--data-urlencode 'match[]={__name__="eo_es_cluster_management_state_info"}' \
--data-urlencode 'match[]={__name__="imageregistry:imagestreamtags_count:sum"}' \
--data-urlencode 'match[]={__name__="imageregistry:operations_count:sum"}' \
--data-urlencode 'match[]={__name__="log_logging_info"}' \
--data-urlencode 'match[]={__name__="log_collector_error_count_total"}' \
--data-urlencode 'match[]={__name__="log_forwarder_pipeline_info"}' \
--data-urlencode 'match[]={__name__="log_forwarder_input_info"}' \
--data-urlencode 'match[]={__name__="log_forwarder_output_info"}' \
--data-urlencode 'match[]={__name__="cluster:log_collected_bytes_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:log_logged_bytes_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:kata_monitor_running_shim_count:sum"}' \
--data-urlencode 'match[]={__name__="platform:hypershift_hostedclusters:max"}' \
--data-urlencode 'match[]={__name__="platform:hypershift_nodepools:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_bucket_claims:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_buckets_claims:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_resources:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_namespace_resources:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_buckets:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_namespace_buckets:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_accounts:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_usage:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_system_health_status:max"}' \
--data-urlencode 'match[]={__name__="ocs_advanced_feature_usage"}' \
--data-urlencode 'match[]={__name__="os_image_url_override:sum"}' \
--data-urlencode 'match[]={__name__="openshift:openshift_network_operator_ipsec_state:info"}'
Copy to Clipboard Toggle word wrap

5.3. 使用 Insights 发现集群中的问题
复制链接

Insights 会重复分析 Insights Operator 发送的数据，其中包括来自 Deployment Validation Operator (DVO) 的工作负载建议。Red Hat OpenShift Service on AWS 用户可以在 Red Hat Hybrid Cloud Console 上显示 Insights Advisor 服务的结果。

您可以使用 Insights 公告服务来评估和监控 Red Hat OpenShift Service on AWS 集群的健康状态。无论您是关注单个集群还是整个基础架构，都必须了解公开集群基础架构对服务可用性、容错、性能或安全性的影响。

如果集群安装了 Deployment Validation Operator (DVO)，请突出配置可能会导致集群健康问题的工作负载。

Insights 分析的结果包括在 Red Hat Hybrid Cloud Console 上的 Insights 公告服务中。在 Red Hat Hybrid Cloud 控制台中，您可以执行以下操作：

  • 查看受特定建议影响的集群和工作负载。
  • 使用可靠的过滤功能，将结果优化为这些建议。
  • 了解更多有关单独建议、了解它们存在的风险的详细信息，并针对您的单个集群量身定制解决方案。
  • 与其他利益相关者分享结果。

其他资源

5.3.2. 了解 Insights Advisor 建议
复制链接

Insights 公告服务捆绑包有关各种集群状态和组件配置的信息，它们可能会对集群和工作负载的服务可用性、容错、性能或安全性造成负面影响。这些信息集在 Insights 公告服务中称为建议。集群的建议包括以下信息：

  • Name： 有关建议的简要描述
  • Added: 在建议发布到 Insights Advisor 服务归档时
  • Category: 问题是否有可能对服务可用性、容错、性能或安全性造成负面影响
  • Total risk: 通过会对您的集群或工作负载造成负面影响的可能性派生的值，如果已发生，对操作的影响
  • Clusters：检测到建议的集群列表
  • Description：这个问题的简要概要，包括它对您的集群的影响

5.3.3. 显示集群中的潜在问题
复制链接

本节论述了如何在 OpenShift Cluster Manager 上的 Insights Advisor 中显示 Insights 报告。

请注意，Insights 会重复分析您的集群并显示最新结果。这些结果可能会改变，如您解决了一个问题，或发现了一个新问题时。

先决条件

流程

  1. 进入 OpenShift Cluster Manager 上的 Advisor → Recommendations。

    根据具体的结果，Insights 公告服务会显示以下之一：

    • 如果 Insights 没有发现任何问题，则不会找到匹配的建议。
    • Insights 检测到的问题列表，按风险分组（低、中、重要和严重）。
    • No clusters yet，如果 Insights 还没有分析集群。这个分析会在集群安装、注册并连接到互联网后立即开始。

  2. 如果显示任何问题，请点击条目前面的 > 图标以了解更多详情。

    根据具体问题，详细信息还可以包含来自红帽有关此问题的更多信息的链接。

5.3.4. 显示所有 Insights 公告服务建议
复制链接

默认情况下，Recommendations 视图仅显示集群中检测到的建议。但是，您可以查看公告服务存档中的所有建议。

先决条件

流程

  1. 进入 OpenShift Cluster Manager 上的 Advisor → Recommendations。

  2. 点 Clusters Impacted 和 Status 过滤器旁边的 X 图标。

    现在，您可以浏览集群的所有潜在建议。

5.3.5. Advisor 建议过滤器
复制链接

Insights 公告服务可能会返回大量建议。要专注于最重要的建议，您可以将过滤器应用到 Advisor 建议 列表，以排除低优先级的建议。

默认情况下，过滤器被设置为只显示启用的建议，这些建议影响一个或多个集群。要查看 Insights 库中所有的建议或禁用的建议，您可以自定义过滤器。

要应用过滤器，请选择过滤器类型，然后根据下拉列表中可用的选项设置其值。您可以将多个过滤器应用到建议列表中。

您可以设置以下过滤器类型：

  • Name ：按名称搜索建议。
  • Total risk: 从 Critical, Important, Moderate, 和 Low 中选择一个或多个值，代表对集群的负面影响的可能性和严重程度。
  • Impact: 从 Critical, High, Medium, 和 Low 中选择一个或多个值，代表对集群操作的连续性影响。
  • Likelihood: 从Critical, High, Medium, 和 Low 中选择一个或多个值，代表当建议出现隐患时对集群有负面影响的可能性。
  • Category: 根据您所关注的方面，从 Service Availability, Performance, Fault Tolerance, Security, 和 Best Practice 中选择一个或多个类别。
  • Status ：点单选按钮显示启用的建议（默认）、禁用建议或所有建议。
  • Clusters impacted: 设置过滤器以显示当前影响一个或多个集群的建议、没有影响的建议或所有建议。
  • Risk of change: 从 High、Moderate、low 和 Very low 中选择一个或多个值，表示解析的实现可能对集群操作带来的风险。
5.3.5.1. 过滤 Insights 公告服务建议
复制链接

作为 Red Hat OpenShift Service on AWS 集群管理器，您可以过滤建议显示在建议列表中。通过应用过滤器，您可以减少报告的建议数量，并专注于高优先级的建议。

以下流程演示了如何设置和删除 Category 过滤器，但该流程也适用于其他过滤器类型。

先决条件

登陆到 Hybrid Cloud 控制台中的 OpenShift Cluster Manager。

流程

  1. 进入 OpenShift > Advisor > Recommendations。
  2. 在 main, filter-type 下拉列表中，选择 Category 过滤器类型。
  3. 展开 filter-value 下拉列表，再选中您要查看的每个推荐类别旁边的复选框。清除不必要的类别的复选框。
  4. 可选：添加额外的过滤器来进一步重新定义列表。

列表中仅显示所选类别的建议。

验证

  • 应用过滤器后，您可以查看更新的推荐列表。应用的过滤器会在默认过滤器旁边添加。
5.3.5.2. 从 Insights 公告服务建议中删除过滤
复制链接

您可以将多个过滤器应用到建议列表中。准备就绪后，您可以单独删除它们或完全重置它们。

单独删除过滤器

  • 点每个过滤器旁边的 X 图标，包括默认过滤器，以分别删除它们。

删除所有非默认过滤器

  • 点 Reset filters 只删除您应用的过滤器，保留默认过滤器。

5.3.6. 禁用 Insights 公告服务建议
复制链接

您可以禁用影响集群的具体建议，以便它们不再出现在报告中。可以禁用单个集群或所有集群的建议。

注意

禁用对所有集群的建议也适用于所有集群。

先决条件

流程

  1. 进入 OpenShift Cluster Manager 上的 Advisor → Recommendations。
  2. 可选： 根据需要使用 Clusters Impacted 和 Status 过滤器。

  3. 使用以下方法之一禁用警报：

    • 禁用警报：

      1. 点击该警报的 Options 菜单 kebab ，然后点 Disable recommendations。
      2. 输入说明并单击 保存。

    • 要在禁用警报前查看受此警报影响的集群：

      1. 点要禁用的建议名称。您会被定向到单一推荐页面。
      2. 查看 Affected clusters 部分中的集群列表。
      3. 点 Actions → Disable recommendations 禁用所有集群的警报。
      4. 输入说明并单击 保存。

5.3.7. 启用之前禁用的 Insights 公告服务建议
复制链接

当所有集群都禁用了一个建议时，您不会在 Insights 公告服务中看到该建议。您可以更改此行为。

先决条件

流程

  1. 进入 OpenShift Cluster Manager 上的 Advisor → Recommendations。

  2. 过滤在禁用的建议上显示的建议：

    1. 在 Status 下拉菜单中选择 Status。
    2. 在 Filter by status 下拉菜单中选择 Disabled。
    3. 可选：清除 Clusters impacted 过滤器。
  3. 找到启用的建议。
  4. 点 Options 菜单 kebab ，然后点 Enable recommendations。

5.3.8. 关于工作负载的 Insights 公告服务建议
复制链接

您可以使用 Red Hat Insights for OpenShift 公告服务查看和管理影响您的集群和工作负载的建议信息。公告服务利用部署验证功能，帮助 OpenShift 集群管理员查看部署策略的所有运行时违反情况。您可以在 Red Hat Hybrid Cloud Console 上的 OpenShift > Advisor > Workloads 中查看工作负载的建议。如需更多信息，请参阅这些其他资源：

5.3.9. 在 web 控制台中显示 Insights 状态
复制链接

Insights 会重复分析您的集群，您可以在 Red Hat OpenShift Service on AWS web 控制台中显示已识别的集群潜在问题的状态。此状态显示不同类别中的问题数量，以及 OpenShift Cluster Manager 报告的链接。

先决条件

  • 集群在 OpenShift Cluster Manager 中注册。
  • 启用了远程健康报告（这是默认设置）。
  • 登录到 Red Hat OpenShift Service on AWS 的 Web 控制台。

流程

  1. 在 Red Hat OpenShift Service on AWS Web 控制台中进入 Home → Overview。

  2. 点 Status 卡上的 Insights。

    弹出窗口列出了按风险分组的潜在问题。点击独立类别或查看 Insights Advisor 中的所有建议，以显示更多详情。

5.4. 使用 Insights Operator
复制链接

Insights Operator 会定期收集配置和组件故障状态信息，默每两小时向红帽报告这些数据。这些信息可让红帽评估配置，它提供了比 Telemetry 报告更深入的数据。Red Hat OpenShift Service on AWS 用户可以在 Red Hat Hybrid Cloud Console 上的 Insights Advisor 服务中显示报告。

5.4.1. 了解 Insights Operator 警报
复制链接

Insights Operator 通过 Prometheus 监控系统向 Alertmanager 声明警报。您可以使用以下方法之一在 Red Hat OpenShift Service on AWS Web 控制台的 Alerting UI 中查看这些警报：

  • 在 Administrator 视角中，点 Observe → Alerting。
  • 在 Developer 视角中，点 Observe → <project_name> → Alerts 标签页。

目前，Insights Operator 在满足条件时发送以下警报：

Expand
表 5.1. Insights Operator 警报
警报描述

InsightsDisabled

Insights Operator 被禁用。

SimpleContentAccessNotAvailable

Red Hat Subscription Management 中不启用简单的内容访问。

InsightsRecommendationActive

Insights 具有集群的活跃建议。

5.4.2. 模糊处理 Deployment Validation Operator 数据
复制链接

默认情况下，当您安装 Deployment Validation Operator (DVO)时，资源的名称和唯一标识符(UID)包含在 AWS 上由 Insights Operator 捕获和处理的数据中。如果您是集群管理员，您可以将 Insights Operator 配置为模糊处理 Deployment Validation Operator (DVO)中的数据。例如，您可以在发送给红帽的归档文件中模糊处理工作负载名称。

要模糊处理资源名称，您必须在 insights-config ConfigMap 对象中手动设置 obfuscation 属性，使其包含 workload_names 值，如以下步骤中所述。

先决条件

  • 启用了远程健康报告（这是默认设置）。
  • 使用 "cluster-admin" 角色登录到 Red Hat OpenShift Service on AWS web 控制台。
  • insights-config ConfigMap 对象存在于 openshift-insights 命名空间中。
  • 集群被自我管理，并安装了 Deployment Validation Operator。

流程

  1. 进入 Workloads → ConfigMaps 并选择 Project: openshift-insights。
  2. 点 insights-config ConfigMap 对象打开它。
  3. 点 Actions 并选择 Edit ConfigMap。
  4. 点 YAML 视图 单选按钮。

  5. 在文件中，使用 workload_names 值设置 obfuscation 属性。 

    apiVersion: v1
kind: ConfigMap
# ...
data:
  config.yaml: |
    dataReporting:
      obfuscation:
        - workload_names
# ...
    Copy to Clipboard Toggle word wrap
  6. 点击 Save。insights-config config-map 详情页面将打开。
  7. 验证 config.yaml obfuscation 属性的值是否已设置为 - workload_names。

第 6 章 收集集群数据
复制链接

在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。

建议您提供：

6.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-rhel9:v4.19.3
    Copy to Clipboard Toggle word wrap

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

      例如： 

      $ oc adm must-gather -- /usr/bin/gather_audit_logs
      Copy to Clipboard Toggle word wrap
      注意
      • 作为默认信息集合的一部分，不会收集审计日志来减小文件的大小。
      • 在 Windows 操作系统上，安装 cwRsync 客户端，并添加到 PATH 变量中，以便与 oc rsync 命令一起使用。

当您运行 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
...
Copy to Clipboard Toggle word wrap

另外，您可以使用 --run-namespace 选项在特定命名空间中运行 oc adm must-gather 命令。

例如： 

$ oc adm must-gather --run-namespace <namespace> \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.19.3
Copy to Clipboard Toggle word wrap

6.1.1. 为红帽支持收集您的集群数据
复制链接

您可使用 oc adm must-gather CLI 命令收集有关您的集群的调试信息。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 安装了 Red Hat OpenShift Service on AWS CLI (oc)。

流程

  1. 进入要存储 must-gather 数据的目录。

    注意

    如果集群在断开连接的环境中，则需要执行额外的步骤。如果您镜像的容器镜像仓库有一个信任的 CA，您必须首先将这个信任的 CA 添加到集群中。对于在断开连接的环境中的所有集群，您必须导入默认的 must-gather 镜像作为镜像流。 

    $ oc import-image is/must-gather -n openshift
    Copy to Clipboard Toggle word wrap

  2. 运行 oc adm must-gather 命令： 

    $ oc adm must-gather
    Copy to Clipboard Toggle word wrap
    重要

    如果您位于断开连接的环境中,请使用 --image 标志作为 must-gather 的一部分，指向有效负载镜像。

    注意

    因为这个命令会默认会选择一个随机 control plane 节点，所以 pod 可能会被调度到处于 NotReady 和 SchedulingDisabled 状态的 control plane 节点。

    1. 如果此命令失败，例如，您无法在集群中调度 pod，则使用 oc adm inspect 命令来收集特定资源的信息。

      注意

      请联络红帽支持以获取推荐收集的资源信息。

  3. 从刚刚在您的工作目录中创建的 must-gather 目录创建一个压缩文件。确保为唯一的 must-gather 数据提供日期和集群 ID。有关如何查找集群 ID 的更多信息，请参阅 如何在 OpenShift 集群上找到 cluster-id 或名称。例如，在使用 Linux 操作系统的计算机上运行以下命令： 

    $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir>
    1
    Copy to Clipboard Toggle word wrap
    1
    将 <must_gather_local_dir > 替换为实际目录名称。
  4. 在红帽客户门户网站的客户支持页面中，将压缩文件附加到您的支持问题单中。

6.1.2. must-gather 标记
复制链接

下表中列出的标记可用于 oc adm must-gather 命令。

Expand
表 6.1. oc adm must-gather的 Red Hat OpenShift Service on AWS 标记
标记示例命令描述

--all-images

oc adm must-gather --all-images=false

为集群中带有 operators.openshift.io/must-gather-image 注解的所有 Operator 使用默认镜像收集 must-gather 数据。

--dest-dir

oc adm must-gather --dest-dir='<directory_name>'

在写入收集的数据的本地机器上设置一个特定的目录。

--host-network

oc adm must-gather --host-network=false

运行 must-gather pod 作为 hostNetwork: true。如果特定命令和镜像需要捕获主机级数据，则相关内容。

--image

oc adm must-gather --image=[<plugin_image>]

指定要运行的 must-gather 插件镜像。如果没有指定，则使用 Red Hat OpenShift Service on AWS 的默认 must-gather 镜像。

--image-stream

oc adm must-gather --image-stream=[<image_stream>]

使用一个命名空间或 name:tag 值指定一个'<image_stream>'，其中包含要运行的 must-gather 插件镜像。

--node-name

oc adm must-gather --node-name='<node>'

设置要使用的特定节点。如果没有指定，则默认使用随机 master。

--node-selector

oc adm must-gather --node-selector='<node_selector_name>'

设置要使用的特定节点选择器。仅在指定命令和镜像时需要同时捕获一组集群节点上的数据时才相关。

--run-namespace

oc adm must-gather --run-namespace='<namespace>'

must-gather pod 应在其中运行的一个现有的特权命名空间。如果没有指定，会生成一个临时命名空间。

--since

oc adm must-gather --since=<time>

仅返回比指定持续时间更新的日志。默认为所有日志。为了支持这个功能，推荐使用插件，但这并不是必须的。只能使用 since-time 或 since 之一。

--since-time

oc adm must-gather --since-time='<date_and_time>'

仅在特定日期和时间后返回日志，以(RFC3339)格式表示。默认为所有日志。为了支持这个功能，推荐使用插件，但这并不是必须的。只能使用 since-time 或 since 之一。

--source-dir

oc adm must-gather --source-dir='/<directory_name>/'

指定您要从其中复制收集的数据的 pod 中的一个特定目录。

--timeout

oc adm must-gather --timeout='<time>'

在超时前收集数据的时间长度，以秒、分钟或小时表示，如 3s、5m 或 2h。指定的时间必须大于零。如果没有指定，则默认为 10 分钟。

--volume-percentage

oc adm must-gather --volume-percentage=<percent>

指定可用于 must-gather 的 pod 分配卷的最大百分比。如果超过这个限制，must-gather 会停止收集，但仍复制收集的数据。如果没有指定，则默认为 30%。

6.1.3. 收集有关特定功能的数据
复制链接

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

Expand
表 6.2. 支持的 must-gather 镜像
Image用途

registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.19.3

OpenShift Virtualization 的数据收集。

registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8

OpenShift Serverless 的数据收集。

registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:<installed_version_service_mesh>

Red Hat OpenShift Service Mesh 的数据收集。

registry.redhat.io/multicluster-engine/must-gather-rhel8

托管 control plane 的数据收集。

registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v<installed_version_migration_toolkit>

MTC 的数据收集。

registry.redhat.io/odf4/odf-must-gather-rhel9:v<installed_version_ODF>

Red Hat OpenShift Data Foundation 的数据收集。

registry.redhat.io/openshift-logging/cluster-logging-rhel9-operator:v<installed_version_logging>

用于日志记录的数据收集。

quay.io/netobserv/must-gather

Network Observability Operator 的数据收集。

registry.redhat.io/openshift4/ose-local-storage-mustgather-rhel9:v<installed_version_LSO>

Local Storage Operator 的数据收集。

registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel8:v<installed_version_sandboxed_containers>

OpenShift 沙盒容器的数据收集。

registry.redhat.io/workload-availability/node-healthcheck-must-gather-rhel8:v<installed_version_NHC>

Red Hat Workload Availability Operator 的数据收集，包括 Self Node Remediation (SNR) Operator、Fence Agents Remediation (FAR) Operator、Machine Deletion Remediation (MDR) Operator、Node Health Check (NHC) Operator 和 Node Maintenance Operator (NMO)。

如果您的 NHC Operator 版本早于 0.9.0，请使用此镜像。

如需更多信息，请参阅 修复、隔离和维护 (Red Hat OpenShift)中特定 Operator 的"收集数据"部分。

registry.redhat.io/workload-availability/node-healthcheck-must-gather-rhel9:v<installed_version_NHC>

Red Hat Workload Availability Operator 的数据收集，包括 Self Node Remediation (SNR) Operator、Fence Agents Remediation (FAR) Operator、Machine Deletion Remediation (MDR) Operator、Node Health Check (NHC) Operator 和 Node Maintenance Operator (NMO)。

如果您的 NHC Operator 版本为 0.9.0. 或更高版本，请使用此镜像。

如需更多信息，请参阅 修复、隔离和维护 (Red Hat OpenShift)中特定 Operator 的"收集数据"部分。

registry.redhat.io/numaresources/numaresources-must-gather-rhel9:v<installed-version-nro>

NUMA Resources Operator (NRO) 的数据收集。

registry.redhat.io/openshift4/ptp-must-gather-rhel8:v<installed-version-ptp>

PTP Operator 的数据收集。

registry.redhat.io/openshift-gitops-1/must-gather-rhel8:v<installed_version_GitOps>

Red Hat OpenShift GitOps 的数据收集。

registry.redhat.io/openshift4/ose-secrets-store-csi-mustgather-rhel9:v<installed_version_secret_store>

Secret Store CSI Driver Operator 的数据收集。

registry.redhat.io/lvms4/lvms-must-gather-rhel9:v<installed_version_LVMS>

LVM Operator 的数据收集。

registry.redhat.io/compliance/openshift-compliance-must-gather-rhel8:<digest-version>

Compliance Operator 的数据收集。

注意

要确定 Red Hat OpenShift Service on AWS 组件镜像的最新版本，请参阅红帽客户门户网站中的 OpenShift Operator 生命周期 网页。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 安装了 Red Hat OpenShift Service on AWS CLI (oc)。

流程

  1. 进入存储 must-gather 数据的目录。

  2. 使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。

    注意
    • 要收集除特定功能数据外的默认 must-gather 数据，请添加 --image-stream=openshift/must-gather 参数。
    • 有关收集有关自定义 Metrics Autoscaler 的数据的详情，请参考下面的附加资源部分。

    例如，使用以下命令可收集默认集群数据和 OpenShift Virtualization 特定信息： 

    $ oc adm must-gather \
  --image-stream=openshift/must-gather \
    1 
    
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.19.3
    2
    Copy to Clipboard Toggle word wrap
    1
    默认 Red Hat OpenShift Service on AWS must-gather 镜像
    2
    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}')
    Copy to Clipboard Toggle word wrap

    例 6.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
      ├── ...
    Copy to Clipboard Toggle word wrap

  3. 使用一个或多个 --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
    Copy to Clipboard Toggle word wrap
    1
    默认 Red Hat OpenShift Service on AWS must-gather 镜像
    2
    KubeVirt 的 must-gather 镜像

  4. 从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。确保为唯一的 must-gather 数据提供日期和集群 ID。有关如何查找集群 ID 的更多信息，请参阅如何在 OpenShift 集群上找到 cluster-id 或名称。例如，在使用 Linux 操作系统的计算机上运行以下命令： 

    $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir>
    1
    Copy to Clipboard Toggle word wrap
    1
    将 <must_gather_local_dir> 替换为实际目录名称。
  5. 在红帽客户门户网站的客户支持页面中，将压缩文件附加到您的支持问题单中。

6.1.4. 收集网络日志
复制链接

您可以在集群中的所有节点上收集网络日志。

流程

  1. 使用 -- gather_network_logs 运行 oc adm must-gather 命令： 

    $ oc adm must-gather -- gather_network_logs
    Copy to Clipboard Toggle word wrap
    注意

    默认情况下，must-gather 工具从集群中的所有节点收集 OVN nbdb 和 sbdb 数据库。添加 -- gather_network_logs 选项，使其包含包含 OVN nbdb 数据库的 OVN-Kubernetes 事务的额外日志。

  2. 从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。确保为唯一的 must-gather 数据提供日期和集群 ID。有关如何查找集群 ID 的更多信息，请参阅如何在 OpenShift 集群上找到 cluster-id 或名称。例如，在使用 Linux 操作系统的计算机上运行以下命令： 

    $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir>
    1
    Copy to Clipboard Toggle word wrap
    1
    将 <must_gather_local_dir> 替换为实际目录名称。
  3. 在红帽客户门户网站的客户支持页面中，将压缩文件附加到您的支持问题单中。

6.1.5. 更改 must-gather 存储限制
复制链接

当使用 oc adm must-gather 命令收集数据时，信息的默认最大存储是容器的存储容量的 30%。达到 30% 限值后，容器被终止，收集过程将停止。收集到的信息会下载到您的本地存储中。要再次运行 must-gather 命令，您需要一个具有更多存储容量的容器，或者调整最大卷百分比。

如果容器达到存储限制，则生成类似以下示例的错误消息。

输出示例

Disk usage exceeds the volume percentage of 30% for mounted directory. Exiting...
Copy to Clipboard Toggle word wrap

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI (oc)。

流程

  • 使用 volume-percentage 标志运行 oc adm must-gather 命令。新值不能超过 100。 

    $ oc adm must-gather --volume-percentage <storage_percentage>
    Copy to Clipboard Toggle word wrap

6.2. 获取集群 ID
复制链接

在向红帽支持提供信息时，提供集群的唯一标识符会很有帮助。您可以使用 Red Hat OpenShift Service on AWS Web 控制台自动填充集群 ID。您还可以使用 web 控制台或 OpenShift CLI（oc）手工获取集群 ID。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您可以访问 Web 控制台或安装了 OpenShift CLI (oc)。

流程

  • 使用 web 控制台手动获取集群 ID：

    1. 进入到 Home → Overview。
    2. 该值包括在 Details 中的 Cluster ID 项中。

  • 要使用 OpenShift CLI（oc）获取集群 ID，请运行以下命令： 

    $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
    Copy to Clipboard Toggle word wrap

6.3. 查询集群节点 journal 日志
复制链接

您可以在独立集群节点的 /var/log 中收集 journald 单元日志和其他日志。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  • 查询 Red Hat OpenShift Service on AWS 集群节点上的 kubelet journald 单元日志。以下示例仅查询 worker 节点： 

    $ oc adm node-logs --role=worker -u kubelet
    1
    Copy to Clipboard Toggle word wrap
    1
    根据情况替换 kubelet 以查询其他单元日志。

6.4. 网络追踪方法
复制链接

收集网络追踪（以数据包捕获记录的形式）可以帮助红帽支持对网络问题进行故障排除。

Red Hat OpenShift Service on AWS 支持两种方式执行网络追踪。查看下表并选择符合您的需要的方法。

Expand
表 6.3. 支持的收集网络追踪方法
方法优点和功能

收集主机网络追踪

您可以在一个或多个节点上同时指定的时间执行数据包捕获。在满足指定持续时间时，数据包捕获文件将从节点传输到客户端机器。

您可以排除特定操作触发网络通信问题的原因。运行数据包捕获，执行触发此问题的操作，并使用日志诊断问题。

从 Red Hat OpenShift Service on AWS 节点或容器收集网络追踪

您可以在一个节点或一个容器中执行数据包捕获。您可以以交互方式运行 tcpdump 命令，以便您可以控制数据包捕获的持续时间。

您可以手动启动数据包捕获，触发网络通信问题，然后手动停止数据包捕获。

此方法使用 cat 命令和 shell 重定向将数据包从节点或容器捕获数据复制到客户端计算机上。

6.5. 收集主机网络追踪
复制链接

有时，追踪网络通信并同时捕获多个节点上的数据包简化了与网络相关的问题的故障排除。

您可以使用 oc adm must-gather 命令和 registry.redhat.io/openshift4/network-tools-rhel8 容器镜像的组合来收集来自节点的数据包。分析数据包捕获可帮助您对网络通信问题进行故障排除。

oc adm must-gather 命令用于在特定节点上的 pod 中运行 tcpdump 命令。tcpdump 命令记录 pod 中捕获的数据包。当 tcpdump 命令退出时，oc adm must-gather 命令会用从 pod 捕获的数据包传输到您的客户端机器。

提示

以下流程中的示例命令演示了使用 tcpdump 命令执行数据包捕获。但是，您可以在 --image 参数中指定的容器镜像中运行任何命令，以便同时从多个节点收集故障排除信息。

先决条件

  • 以具有 cluster-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令，在某些节点上运行来自主机网络的数据包捕获： 

    $ oc adm must-gather \
    --dest-dir /tmp/captures \// <.>
    --source-dir '/tmp/tcpdump/' \// <.>
    --image registry.redhat.io/openshift4/network-tools-rhel8:latest \// <.>
    --node-selector 'node-role.kubernetes.io/worker' \// <.>
    --host-network=true \// <.>
    --timeout 30s \// <.>
    -- \
    tcpdump -i any \// <.>
    -w /tmp/tcpdump/%Y-%m-%dT%H:%M:%S.pcap -W 1 -G 300
    Copy to Clipboard Toggle word wrap

    <.> --dest-dir 参数指定 oc adm must-gather 将数据包捕获到相对于客户端机器上 /tmp/captures 的目录中。您可以指定任何可写目录。<.> 当 tcpdump 在 oc adm must-gather 启动时的 debug pod 中运行时，--source-dir 参数指定数据包捕获的临时存储在 pod 上的 /tmp/tcpdump 目录中。<.> The --image 参数指定包含 tcpdump 命令的容器镜像。<.> --node-selector 参数和示例值指定在 pod 上的 /tmp/tcpdump 目录中执行数据包捕获。作为替代方案，您可以指定 --node-name 参数而不是在单个节点上运行数据包捕获。如果省略 --node-selector 和 --node-name 参数，则数据包捕获将在所有节点上执行。<.> --host-network=true 参数是必需的，以便在节点的网络接口上执行数据包捕获。<.> --timeout 参数和值指定运行 debug pod 达到 30 秒。如果没有指定 --timeout 参数和持续时间，则 debug pod 会运行 10 分钟。<.> -i any 参数用于 tcpdump 命令，指定捕获所有网络接口上的数据包。作为替代方案，您可以指定网络接口名称。

  2. 执行访问 Web 应用等操作，在网络追踪捕获数据包时触发网络通信问题。

  3. 查看 oc adm must-gather 从 pod 传送到客户端机器的数据包捕获文件： 

    tmp/captures
├── event-filter.html
├── ip-10-0-192-217-ec2-internal
    1 
    
│   └── registry-redhat-io-openshift4-network-tools-rhel8-sha256-bca...
│       └── 2022-01-13T19:31:31.pcap
├── ip-10-0-201-178-ec2-internal
    2 
    
│   └── registry-redhat-io-openshift4-network-tools-rhel8-sha256-bca...
│       └── 2022-01-13T19:31:30.pcap
├── ip-...
└── timestamp
    Copy to Clipboard Toggle word wrap
    1 2
    数据包捕获保存在可识别主机名、容器和文件名的目录中。如果您没有指定 --node-selector 参数，则主机名的目录级别不存在。

在调查与网络相关的 Red Hat OpenShift Service on AWS 问题时，红帽可能会从 AWS 集群节点上的特定 Red Hat OpenShift Service 或特定容器请求网络数据包追踪。在 Red Hat OpenShift Service on AWS 中捕获网络 trace 的建议方法是通过 debug pod。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已有一个红帽支持问题单 ID。

流程

  1. 获取集群节点列表： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

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

    $ oc debug node/my-cluster-node
    Copy to Clipboard Toggle word wrap

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

    # chroot /host
    Copy to Clipboard Toggle word wrap

  4. 在 chroot 环境控制台中获取节点接口名称： 

    # ip ad
    Copy to Clipboard Toggle word wrap

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

    # toolbox
    Copy to Clipboard Toggle word wrap
    注意

    如果一个已存在的 toolbox pod 已在运行，则 toolbox 命令会输出 'toolbox-' already exists.Trying to start…​.要避免 tcpdump 出现问题，请使用 podman rm toolbox- 删除正在运行的 toolbox 容器，并生成新 toolbox 容器。

  6. 在集群节点中启动 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
    Copy to Clipboard Toggle word wrap
    1
    tcpdump 捕获文件路径在 chroot 环境之外，因为 toolbox 容器会在 /host 中挂载主机的根目录。

  7. 如果节点上的特定容器需要 tcpdump 捕获，请按照以下步骤操作。

    1. 确定目标容器 ID。chroot host 命令先于这一步中的 crictl 命令，因为 toolbox 容器在 /host 中挂载主机的根目录： 

      # chroot /host crictl ps
      Copy to Clipboard Toggle word wrap

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

      # chroot /host crictl inspect --output yaml a7fe32346b120 | grep 'pid' | awk '{print $2}'
      Copy to Clipboard Toggle word wrap

    3. 在容器上启动 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
      1
      Copy to Clipboard Toggle word wrap
      1
      tcpdump 捕获文件路径在 chroot 环境之外，因为 toolbox 容器会在 /host 中挂载主机的根目录。

  8. 使用以下方法之一向红帽支持提供 tcpdump 捕获文件进行分析。

    • 将文件上传到现有红帽支持问题单中。

      1. 运行 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
        Copy to Clipboard Toggle word wrap
        1
        debug 容器将主机的根目录挂载到 /host。在指定用于连接的目标文件时，引用 debug 容器的根目录的绝对路径，包括 /host。
      2. 在红帽客户门户网站的 Customer Support 页面中进入现有的支持问题单。
      3. 选择 Attach files 并按提示上传该文件。

6.7. 为红帽支持提供诊断数据
复制链接

在调查 Red Hat OpenShift Service on AWS 问题时，红帽支持可能会要求您将诊断数据上传到支持问题单中。可以通过红帽客户门户网站将文件上传到支持问题单中。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已有一个红帽支持问题单 ID。

流程

  • 通过红帽客户门户网站将诊断数据上传到现有红帽支持问题单中。

    1. 使用 oc debug node/<node_name > 命令连接 Red Hat OpenShift Service on AWS 节点上的诊断文件，并将输出重定向到文件中。以下示例将 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
      Copy to Clipboard Toggle word wrap
      1
      debug 容器将主机的根目录挂载到 /host。在指定用于连接的目标文件时，引用 debug 容器的根目录的绝对路径，包括 /host。
    2. 在红帽客户门户网站的 Customer Support 页面中进入现有的支持问题单。
    3. 选择 Attach files 并按提示上传该文件。

6.8. 关于 toolbox
复制链接

toolbox 是一个在 Red Hat Enterprise Linux CoreOS (RHCOS)系统上启动容器的工具。该工具主要用于启动包含运行 sosreport 等命令所需的二进制文件和插件的容器。

toolbox 容器的主要目的是收集诊断信息并将其提供给红帽支持。但是，如果需要额外的诊断工具，您可以添加 RPM 软件包或运行标准支持工具镜像的替代镜像。

将软件包安装到 toolbox 容器

默认情况下，运行 toolbox 命令使用 registry.redhat.io/rhel9/support-tools:latest 镜像启动一个容器。该镜像包含最常用的支持工具。如果需要一个不是镜像的一部分的支持工具来收集特定于具体节点的数据，可以安装额外的软件包。

先决条件

  • 已使用 oc debug node/<node_name> 命令访问节点。
  • 您可以使用具有 root 权限的用户访问您的系统。

流程

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

    # chroot /host
    Copy to Clipboard Toggle word wrap

  2. 启动 toolbox 容器： 

    # toolbox
    Copy to Clipboard Toggle word wrap

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

    # dnf install -y <package_name>
    Copy to Clipboard Toggle word wrap
使用 toolbox 启动备用镜像

默认情况下，运行 toolbox 命令使用 registry.redhat.io/rhel9/support-tools:latest 镜像启动一个容器。

注意

您可以通过创建 .toolboxrc 文件并指定要运行的镜像来启动其他镜像。但是，Red Hat OpenShift Service on AWS 4 不支持运行 support-tools 镜像的旧版本，如 registry.redhat.io/rhel8/support-tools:latest。

先决条件

  • 已使用 oc debug node/<node_name> 命令访问节点。
  • 您可以使用具有 root 权限的用户访问您的系统。

流程

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

    # chroot /host
    Copy to Clipboard Toggle word wrap

  2. 可选： 如果您需要使用替代镜像而不是默认镜像，请在 root 用户 ID 的主目录中创建一个 .toolboxrc 文件，并指定镜像元数据： 

    REGISTRY=quay.io
    1 
    
IMAGE=fedora/fedora:latest
    2 
    
TOOLBOX_NAME=toolbox-fedora-latest
    3
    Copy to Clipboard Toggle word wrap
    1
    可选：指定替代容器 registry。
    2
    指定要启动的替代镜像。
    3
    可选：指定 toolbox 容器的替代名称。

  3. 输入以下命令启动 toolbox 容器： 

    # toolbox
    Copy to Clipboard Toggle word wrap
    注意

    如果一个已存在的 toolbox pod 已在运行，则 toolbox 命令会输出 'toolbox-' already exists.Trying to start…​.为了避免 sosreport 插件出现问题，请使用 podman rm toolbox- 删除正在运行的 toolbox 容器，然后生成新的 toolbox 容器。

第 7 章 集群规格总结
复制链接

7.1. 使用集群版本对象总结集群规格
复制链接

您可以通过查询 clusterversion 资源来获取 Red Hat OpenShift Service on AWS 集群规格概述。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 查询集群版本、可用性、运行时间以及常规状态： 

    $ oc get clusterversion
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.8    True        False         8h      Cluster version is 4.13.8
    Copy to Clipboard Toggle word wrap

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

    $ oc describe clusterversion
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:         version
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  config.openshift.io/v1
Kind:         ClusterVersion
# ...
    Image:    quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
    URL:      https://access.redhat.com/errata/RHSA-2023:4456
    Version:  4.13.8
  History:
    Completion Time:    2023-08-17T13:20:21Z
    Image:              quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
    Started Time:       2023-08-17T12:59:45Z
    State:              Completed
    Verified:           false
    Version:            4.13.8
# ...
    Copy to Clipboard Toggle word wrap

第 8 章 故障排除
复制链接

8.1. 查看集群通知
复制链接

当您尝试解决集群的问题时，您的集群通知是很好的信息源。

集群通知是有关集群状态、健康或性能的消息。它们也是 Red Hat Site Reliability Engineering (SRE)与您的集群健康状况沟通并解决集群问题的主要方法。

集群通知提供有关集群健康状况的重要信息。您可以在 Red Hat Hybrid Cloud Console 上的 Cluster history 选项卡中查看发送到集群的通知。

先决条件

  • 已登陆到 Hybrid Cloud 控制台。

流程

  1. 进入到 Hybrid Cloud Console 的 Clusters 页。
  2. 点集群名称进入集群详情页面。

  3. 点 Cluster history 选项卡。

    集群通知会出现在 Cluster history 标题下。

  4. 可选：过滤相关集群通知

    使用过滤器控件隐藏与您无关的集群通知，以便您可以专注于专业知识，或解决严重问题。您可以根据通知描述、严重性级别、通知类型、收到通知以及系统或个人触发通知中的文本过滤通知。

有关在 AWS 集群上安装 Red Hat OpenShift Service 的帮助，请参阅以下部分。

8.2.1. 安装故障排除
复制链接

8.2.1.1. 检查安装或卸载日志
复制链接

显示安装日志：

  • 运行以下命令，使用您的集群名替换 <cluster_name>： 

    $ rosa logs install --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

  • 要监视日志，请包含 --watch 标志： 

    $ rosa logs install --cluster=<cluster_name> --watch
    Copy to Clipboard Toggle word wrap

显示卸载日志：

  • 运行以下命令，使用您的集群名替换 <cluster_name>： 

    $ rosa logs uninstall --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

  • 要监视日志，请包含 --watch 标志： 

    $ rosa logs uninstall --cluster=<cluster_name> --watch
    Copy to Clipboard Toggle word wrap
8.2.1.2. 验证 AWS 帐户和配额
复制链接

运行以下命令，验证您在 AWS 帐户上有可用的配额： 

$ rosa verify quota
Copy to Clipboard Toggle word wrap

AWS 配额根据区域进行更改。确保您为正确的 AWS 区域验证配额。如果需要提高配额，进入 AWS 控制台，并为失败的服务请求配额增加。

8.2.1.3. AWS 通知电子邮件
复制链接

在创建集群时，Red Hat OpenShift Service on AWS 服务在所有支持的区域中创建小实例。此检查可确保使用的 AWS 帐户可以部署到每个支持的区域。

对于不使用所有支持的区域的 AWS 帐户，AWS 可能会发送一个或多个电子邮件确认"Your Request For Access AWS Resources Has Been Validated"。此电子邮件的发送者通常是 aws-verification@amazon.com。

这是预期的行为，因为 Red Hat OpenShift Service on AWS 服务正在验证 AWS 帐户配置。

8.2.2. 验证 Red Hat OpenShift Service on AWS 集群安装
复制链接

如果带有 HCP 集群的 ROSA 处于安装状态超过 30 分钟，且尚未就绪，请确保为所需的集群配置准备 AWS 帐户环境。如果正确为所需的集群配置准备 AWS 帐户环境，请尝试删除并重新创建集群。如果问题仍然存在，请联系支持。

下表列出了 Red Hat OpenShift Service on AWS 安装错误代码，以及您可以做什么来排除这些错误。

Expand
表 8.1. Red Hat OpenShift Service on AWS 安装错误代码
错误代码描述解决方案

OCM3999

未知错误。

检查集群安装日志以了解更多详情，或删除此集群并重试集群安装。如果此问题仍然存在，请通过登录到 客户支持页面联系支持 。

OCM5001

Red Hat OpenShift Service on AWS 集群置备失败。

检查集群安装日志以了解更多详情，或删除此集群并重试集群安装。如果此问题仍然存在，请通过登录到 客户支持页面联系支持 。

OCM5002

超过最多资源标签大小为 25。

检查集群信息，以确定您可以删除指定并重试集群安装的任何不必要的标签。

OCM5003

无法建立 AWS 客户端以置备集群。

您必须在 AWS 帐户上创建几个角色资源，才能创建和管理 Red Hat OpenShift Service on AWS 集群。确保提供的 AWS 凭证正确并重试集群安装。

如需有关 Red Hat OpenShift Service on AWS IAM 角色资源的更多信息，请参阅附加资源部分中的 ROSA IAM 角色资源 。

OCM5004

无法建立跨帐户 AWS 客户端来置备集群。

您必须在 AWS 帐户上创建几个角色资源，才能创建和管理 Red Hat OpenShift Service on AWS 集群。确保提供的 AWS 凭证正确并重试集群安装。

如需有关 Red Hat OpenShift Service on AWS IAM 角色资源的更多信息，请参阅附加资源部分中的 ROSA IAM 角色资源 。

OCM5005

检索为集群定义的 AWS 子网失败。

查看提供的子网 ID 和重试集群安装。

OCM5006

您必须为集群配置私有 AWS 子网。

查看提供的子网 ID 和重试集群安装。

OCM5007

无法为集群创建 AWS STS 先决条件。

验证 account 和 operator 角色是否已创建并正确。如需更多信息，请参阅附加资源部分 中所述的 AWS STS 和使用 HCP 的 ROSA。

OCM5008

提供的集群缺陷不正确。

在使用 flavour 参数并重试集群创建时，验证提供的名称或 ID 是否正确。

OCM5009

集群版本无法找到。

确保配置的版本 ID 与有效的 Red Hat OpenShift Service on AWS 版本匹配。

OCM5010

标记集群的子网失败。

确认 AWS 权限和子网配置正确。您必须至少标记一个专用子网；如果适用，您必须只标记一个公共子网。

OCM5011

由于所选区域中不可用的容量，集群安装失败。

在另一个区域或重试集群安装中尝试集群安装。

在 Red Hat OpenShift Service on AWS 集群中，Red Hat OpenShift Service on AWS OAuth 服务器托管在红帽服务的 AWS 帐户中，而 Web 控制台服务使用集群的 AWS 帐户中的默认入口控制器发布。如果您可以使用 OpenShift CLI (oc)登录集群，但无法访问 Red Hat OpenShift Service on AWS Web 控制台，请验证是否满足以下条件：

  • 控制台工作负载正在运行。
  • 默认入口控制器的负载均衡器处于活跃状态。
  • 您要从已连接到集群的 VPC 网络的机器访问控制台。

当 Red Hat OpenShift Service on AWS 服务帐户中托管的 control plane 就绪时，Red Hat OpenShift Service on AWS 集群会返回就绪状态。集群控制台工作负载部署到集群的 worker 节点上。在 worker 节点加入集群和控制台工作负载正在运行前，Red Hat OpenShift Service on AWS Web 控制台将不可用并可访问。

如果您的 Red Hat OpenShift Service on AWS 集群已就绪，但您无法访问集群的 Red Hat OpenShift Service on AWS Web 控制台，请等待 worker 节点加入集群并重试访问控制台。

您可以登录到 Red Hat OpenShift Service on AWS 集群，或使用 rosa CLI 中的 rosa describe machinepool 命令监视节点。

默认情况下，私有集群的控制台是私有的。在集群安装过程中，由 OpenShift 的 Ingress Operator 管理的默认 Ingress Controller 配置有内部 AWS Network Load Balancer (NLB)。

如果您的私有 Red Hat OpenShift Service on AWS 集群显示 就绪状态，但您无法访问集群的 Red Hat OpenShift Service on AWS Web 控制台，尝试从集群 VPC 中或连接到 VPC 的网络访问集群控制台。

8.3. 网络故障排除
复制链接

本文档论述了如何对网络错误进行故障排除。

在默认入口控制器中使用版本 4 部署 AWS Network Load Balancers (NLB)创建的 Red Hat OpenShift Service on AWS 集群。对于私有 NLB，NLB 的客户端 IP 地址保留可能会导致连接被丢弃，其中源和目标是同一主机。请参阅 AWS 文档中有关如何对网络负载平衡器 进行故障排除的文档。此 IP 地址保留意味着，任何客户工作负载都与路由器 pod 在同一节点上共存，可能无法将流量发送到绑定到入口控制器路由器的专用 NLB。

为了缓解这种影响，客户应将其工作负载重新调度到独立于调度路由器 pod 的节点。另外，客户应依赖内部 pod 和服务网络来访问同一集群中的其他工作负载。

8.4. 验证节点健康状况
复制链接

8.4.1. 查看节点状态、资源使用量和配置
复制链接

查看集群节点健康状况、资源消耗统计和节点日志。另外，在单个节点上查询 kubelet 状态。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  • 列出集群中所有节点的名称、状态和角色： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

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

    $ oc adm top nodes
    Copy to Clipboard Toggle word wrap

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

    $ oc adm top node my-node
    Copy to Clipboard Toggle word wrap

8.5. Troubleshooting Operator 的问题
复制链接

Operator 是一种打包、部署和管理 Red Hat OpenShift Service on AWS 应用程序的方法。它可以被看作是软件厂商的工程团队的扩展，可以在 Red Hat OpenShift Service on AWS 环境中监控，并使用其当前状态实时做出决策。Operator 被设计为用来无缝地处理升级过程，并对出现的错误自动进行响应，而且不会采取“捷径”（如跳过软件备份过程来节省时间）。

Red Hat OpenShift Service on AWS 4 包括了一组默认的 Operator，它们是集群正常工作所需的。这些默认 Operator 由 Cluster Version Operator（CVO）管理。

作为集群管理员，您可以使用 Red Hat OpenShift Service on AWS Web 控制台或 CLI 安装来自 OperatorHub 的应用程序 Operator。然后，您可将 Operator 订阅至一个或多个命名空间，供集群上的开发人员使用。应用程序 Operator 由 Operator Lifecycle Manager（OLM）进行管理。

如果遇到 Operator 问题，请验证 Operator 订阅状态。检查集群中的 Operator pod 健康状况，并收集 Operator 日志以进行诊断。

8.5.1. operator 订阅状况类型
复制链接

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

Expand
表 8.2. 订阅状况类型
状况描述

CatalogSourcesUnhealthy

用于解析的一个或多个目录源不健康。

InstallPlanMissing

缺少订阅的安装计划。

InstallPlanPending

订阅的安装计划正在安装中。

InstallPlanFailed

订阅的安装计划失败。

ResolutionFailed

订阅的依赖项解析失败。

注意

默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。

8.5.2. 使用 CLI 查看 Operator 订阅状态
复制链接

您可以使用 CLI 查看 Operator 订阅状态。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 列出 Operator 订阅： 

    $ oc get subs -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

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

    $ oc describe sub <subscription_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

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

    输出示例

    Name:         cluster-logging
Namespace:    openshift-logging
Labels:       operators.coreos.com/cluster-logging.openshift-logging=
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         Subscription
# ...
Conditions:
   Last Transition Time:  2019-07-29T13:42:57Z
   Message:               all available catalogsources are healthy
   Reason:                AllCatalogSourcesHealthy
   Status:                False
   Type:                  CatalogSourcesUnhealthy
# ...
    Copy to Clipboard Toggle word wrap

注意

默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。

8.5.3. 使用 CLI 查看 Operator 目录源状态
复制链接

您可以使用 CLI 查看 Operator 目录源的状态。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 列出命名空间中的目录源。例如，您可以检查 openshift-marketplace 命名空间，该命名空间用于集群范围的目录源： 

    $ oc get catalogsources -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    输出示例

    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-operators      Red Hat Operators     grpc   Red Hat     55m
    Copy to Clipboard Toggle word wrap

  2. 使用 oc describe 命令获取有关目录源的详情和状态： 

    $ oc describe catalogsource example-catalog -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:         example-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  operatorframework.io/managed-by: marketplace-operator
              target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
# ...
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
# ...
    Copy to Clipboard Toggle word wrap

    在上例的输出中，最后观察到的状态是 TRANSIENT_FAILURE。此状态表示目录源建立连接时出现问题。

  3. 列出创建目录源的命名空间中的 pod： 

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    输出示例

    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-operators-smxx8                  1/1     Running            0          36m
    Copy to Clipboard Toggle word wrap

    在命名空间中创建目录源时，会在该命名空间中为目录源创建一个 pod。在前面的示例中，example-catalog-bwt8z pod 的状态是 ImagePullBackOff。此状态表示拉取目录源的索引镜像存在问题。

  4. 使用 oc describe 命令检查 pod 以获取更多详细信息： 

    $ oc describe pod example-catalog-bwt8z -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    输出示例

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

    在前面的示例输出中，错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如，索引镜像可能存储在需要登录凭证的 registry 中。

8.5.4. 查询 Operator pod 状态
复制链接

您可以列出集群中的 Operator pod 及其状态。您还可以收集详细的 Operator pod 概述。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 列出集群中运行的 Operator。输出包括 Operator 版本、可用性和运行时间信息： 

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

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

    $ oc get pod -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  3. 输出详细的 Operator pod 概述： 

    $ oc describe pod <operator_pod_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

8.6. 检查 pod 问题
复制链接

Red Hat OpenShift Service on AWS 利用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器。pod 是可在 Red Hat OpenShift Service on AWS 4 上定义、部署和管理的最小计算单元。

在定义了 pod 后，它将分配到节点上运行，直到容器退出，或直到它被删除为止。根据策略和退出代码，Pod 可在退出或保留后删除，以便访问其日志。

首先要检查 pod 出现问题时 pod 的状态。如果发生 pod 故障，请观察 pod 的错误状态以识别特定镜像、容器或 pod 网络问题。根据错误状态集中诊断数据收集。查看 pod 事件消息以及 pod 和容器日志信息。通过访问命令行中运行的 pod，或根据 Pod 的部署配置启动具有 root 访问权限的调试 pod 来动态诊断问题。

8.6.1. 了解 pod 错误状态
复制链接

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

下表提供了 pod 错误状态及其描述列表。

Expand
表 8.3. 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

网络终止失败。

8.6.2. 检查 pod 状态
复制链接

您可以查询 pod 状态和错误状态。您还可以查询 pod 的相关部署配置，并查看基础镜像的可用性。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 已安装了 skopeo。

流程

  1. 切换到项目： 

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods
    Copy to Clipboard Toggle word wrap

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

    $ oc status
    Copy to Clipboard Toggle word wrap

    如果命名空间由部署配置管理，输出包括部署配置名称和基础镜像引用。

  4. 检查以上命令输出中引用的基础镜像： 

    $ skopeo inspect docker://<image_reference>
    Copy to Clipboard Toggle word wrap

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

    $ oc edit deployment/my-deployment
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -w
    Copy to Clipboard Toggle word wrap

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

    $ oc get events
    Copy to Clipboard Toggle word wrap

8.6.3. 检查 pod 和容器日志
复制链接

您可以检查 pod 和容器日志，以查看与显式 pod 失败相关的警告和错误消息。根据策略和退出代码，pod 和容器日志在 pod 终止后仍然可用。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 查询特定 pod 的日志： 

    $ oc logs <pod_name>
    Copy to Clipboard Toggle word wrap

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

    $ oc logs <pod_name> -c <container_name>
    Copy to Clipboard Toggle word wrap

    由前面的 oc logs 命令所获得的日志由发送到 pod 或容器中的 stdout 的信息组成。

  3. 检查 pod 中的 /var/log/ 中包含的日志。

    1. 列出 pod 中 /var/log 中所含的日志文件和子目录： 

      $ oc exec <pod_name>  -- ls -alh /var/log
      Copy to Clipboard Toggle word wrap

      输出示例

      total 124K
drwxr-xr-x. 1 root root   33 Aug 11 11:23 .
drwxr-xr-x. 1 root root   28 Sep  6  2022 ..
-rw-rw----. 1 root utmp    0 Jul 10 10:31 btmp
-rw-r--r--. 1 root root  33K Jul 17 10:07 dnf.librepo.log
-rw-r--r--. 1 root root  69K Jul 17 10:07 dnf.log
-rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log
-rw-r--r--. 1 root root  480 Jul 17 10:07 hawkey.log
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 lastlog
drwx------. 2 root root   23 Aug 11 11:14 openshift-apiserver
drwx------. 2 root root    6 Jul 10 10:31 private
drwxr-xr-x. 1 root root   22 Mar  9 08:05 rhsm
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 wtmp
      Copy to Clipboard Toggle word wrap

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

      $ oc exec <pod_name> cat /var/log/<path_to_log>
      Copy to Clipboard Toggle word wrap

      输出示例

      2023-07-10T10:29:38+0000 INFO --- logging initialized ---
2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms
2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories.
2023-07-10T10:29:38+0000 INFO Unable to read consumer identity
2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode.
2023-07-10T10:29:38+0000 INFO
      Copy to Clipboard Toggle word wrap

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

      $ oc exec <pod_name> -c <container_name> ls /var/log
      Copy to Clipboard Toggle word wrap

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

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>
      Copy to Clipboard Toggle word wrap

8.6.4. 访问运行的 pod
复制链接

您可以通过在 pod 中打开 shell，或通过端口转发获取网络访问，来动态查看正在运行的 pod。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 切换到包含您要访问的 pod 的项目。这是必要的，因为 oc rsh 命令不支持使用 -n 选项指定命名空间： 

    $ oc project <namespace>
    Copy to Clipboard Toggle word wrap

  2. 启动到 pod 的远程 shell: 

    $ oc rsh <pod_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    如果 pod 有多个容器，除非使用 -c <container_name> 指定了一个容器，否则 oc rsh 会默认使用第一个容器。

  3. 启动至 pod 中的特定容器中的一个远程 shell ： 

    $ oc rsh -c <container_name> pod/<pod_name>
    Copy to Clipboard Toggle word wrap

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

    $ oc port-forward <pod_name> <host_port>:<pod_port>
    1
    Copy to Clipboard Toggle word wrap
    1
    输入 Ctrl+C 来取消端口转发会话。

8.6.5. 启动具有 root 访问权限的 debug pod
复制链接

您可以基于一个有问题的 pod 部署或部署配置，启动具有根访问权限的 debug pod。pod 用户通常使用非 root 权限运行，但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用：

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 根据一个部署启动具有 root 访问权限的 debug pod。

    1. 获取项目部署名称： 

      $ oc get deployment -n <project_name>
      Copy to Clipboard Toggle word wrap

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

      $ oc debug deployment/my-deployment --as-root -n <project_name>
      Copy to Clipboard Toggle word wrap

  2. 根据部署配置启动具有 root 访问权限的 debug pod。

    1. 获取项目的部署配置名称： 

      $ oc get deploymentconfigs -n <project_name>
      Copy to Clipboard Toggle word wrap

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

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>
      Copy to Clipboard Toggle word wrap
注意

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

您可以将文件复制到 pod 或从 pod 复制，以测试配置更改或收集诊断信息。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 将文件复制到 pod: 

    $ oc cp <local_path> <pod_name>:/<path> -c <container_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    如果没有指定 -c 选项，则会选择 pod 中的第一个容器。

  2. 从 pod 复制文件： 

    $ oc cp <pod_name>:/<path>  -c <container_name> <local_path>
    1
    Copy to Clipboard Toggle word wrap
    1
    如果没有指定 -c 选项，则会选择 pod 中的第一个容器。
    注意

    要使 oc cp 正常工作，容器内必须有 tar。

8.7. 对 Source-to-Image 进行故障排除
复制链接

8.7.1. Source-to-Image 故障排除策略
复制链接

Source-to-Image (S2I) 是一种用于构建可重复生成的 Docker 格式容器镜像的工具。它通过将应用程序源代码注入容器镜像，并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像（构建器）和构建的源。

要确定 S2I 进程中的故障发生位置，您可以观察与以下 S2I 阶段相关的 pod 状态：

  1. 在构建配置阶段，构建 pod 用于从基础镜像和应用程序源代码创建应用程序容器镜像。
  2. 在部署配置阶段，部署 pod 用于从构建配置阶段构建的应用程序容器镜像中部署应用程序 pod。部署 pod 还会部署其他资源，如服务和路由。部署配置在构建配置成功后开始。
  3. 在部署 pod 启动应用程序 pod 后，应用程序故障可能会在运行的应用程序 pod 中发生。例如，即使应用程序 pod 处于 Running 状态，应用程序的行为也可能不会如预期。在这种情况下，您可以访问正在运行的应用程序 pod，以调查 pod 中的应用程序故障。

当对 S2I 问题进行故障排除时，请按照这个策略操作：

  1. 监控构建、部署和应用程序 pod 状态
  2. 确定发生问题 S2I 进程阶段
  3. 查看与失败阶段对应的日志

8.7.2. 收集 Source-to-Image 诊断数据
复制链接

S2I 工具按顺序运行构建 pod 和部署 pod。部署 pod 负责根据构建阶段创建的应用程序容器镜像部署应用程序 pod。观察构建、部署和应用程序 pod 状态，以确定 S2I 进程中的故障发生位置。然后，重点收集诊断数据。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 在整个 S2I 过程中监控 pod 状态，以确定在哪个阶段发生故障： 

    $ oc get pods -w
    1
    Copy to Clipboard Toggle word wrap
    1
    使用 -w 来监控 pod 是否有变化，直到您使用 Ctrl+C 退出命令。

  2. 检查 pod 失败的日志以找出错误。

    • 如果构建 pod 失败，请检查构建 pod 的日志： 

      $ oc logs -f pod/<application_name>-<build_number>-build
      Copy to Clipboard Toggle word wrap
      注意

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

    • 如果部署 pod 失败，请查看部署 pod 的日志： 

      $ oc logs -f pod/<application_name>-<build_number>-deploy
      Copy to Clipboard Toggle word wrap
      注意

      另外，您可以使用 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>
      Copy to Clipboard Toggle word wrap

应用程序故障可在运行的应用程序 pod 中发生。在这些情况下，您可以使用以下策略检索诊断信息：

  • 检查与应用程序 pod 相关的事件。
  • 查看应用程序 pod 的日志，包括不是由 OpenShift Logging 框架收集的特定应用程序日志文件。
  • 以互动方式测试应用程序功能，并在应用程序容器中运行诊断工具。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 列出与特定应用程序 pod 相关的事件。以下示例检索名为 my-app-1-akdlg 的应用程序 pod 的事件: 

    $ oc describe pod/my-app-1-akdlg
    Copy to Clipboard Toggle word wrap

  2. 检查应用程序 pod 的日志： 

    $ oc logs -f pod/my-app-1-akdlg
    Copy to Clipboard Toggle word wrap

  3. 在正在运行的应用程序 pod 中查询特定日志。发送到 stdout 的日志由 OpenShift Logging 框架收集，并包含在上一命令的输出中。以下查询只适用于没有发送到 stdout 的日志。

    1. 如果应用程序日志可以在 pod 内不需要 root 权限的情况下就可以进行访问，则按如下方式处理日志文件： 

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
      Copy to Clipboard Toggle word wrap

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

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log
      Copy to Clipboard Toggle word wrap
      注意

      如果您运行不使用 -- <command> 的oc debug dc/<deployment_configuration> --as-root，则可以获得 debug pod 内带有 root 权限的一个互动式 shell 。

  4. 以互动方式测试应用程序功能,并在带有互动 shell 的应用程序容器中运行诊断工具。

    1. 在应用程序容器上启动一个交互式 shell: 

      $ oc exec -it my-app-1-akdlg /bin/bash
      Copy to Clipboard Toggle word wrap
    2. 在 shell 中以互动方式测试应用程序功能。例如，您可以运行容器的入口点命令并观察结果。然后，在更新源代码并通过 S2I 进程重建应用程序容器前，直接从命令行测试更改。

    3. 运行容器中的诊断二进制文件。

      注意

      运行一些诊断二进制文件需要 root 权限。在这些情况下，您可以通过运行 oc debug dc/<deployment_configuration> --as-root，根据有问题的 pod 的 DeploymentConfig 对象启动一个带有 root 访问权限的 debug pod。然后，您可以从 debug pod 中以 root 用户身份运行诊断二进制文件。

  5. 如果容器中没有诊断二进制文件，您可以使用 nsenter 在容器的命名空间中运行主机的诊断二进制文件。以下实例在一个容器的命名空间中运行 ip ad，使用主机的 ip 二进制代码。

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

      $ oc debug node/my-cluster-node
      Copy to Clipboard Toggle word wrap

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

      # chroot /host
      Copy to Clipboard Toggle word wrap
      注意

      运行 Red Hat Enterprise Linux CoreOS (RHCOS)的 Red Hat OpenShift Service on AWS 4 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。但是，如果 Red Hat OpenShift Service on AWS API 不可用，或者 kubelet 在目标节点上无法正常工作，oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

    3. 确定目标容器 ID: 

      # crictl ps
      Copy to Clipboard Toggle word wrap

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

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'
      Copy to Clipboard Toggle word wrap

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

      # nsenter -n -t 31150 -- ip ad
      Copy to Clipboard Toggle word wrap
      注意

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

8.8. 存储问题故障排除
复制链接

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

流程

要解决 multi-attach 问题,请使用以下解决方案之一：

  • 使用 RWX 卷启用多个附件。

    对于大多数存储解决方案,您可以使用 ReadWriteMany(RWX)卷以防止多附加错误。

  • 使用 RWO 卷时,恢复或删除故障节点。

    对于不支持 RWX 的存储,如 VMware vSphere,必须改为使用 RWO 卷。但是, RWO 卷无法挂载到多个节点上。

    如果您遇到带有 RWO 卷的多附件错误消息，请强制在关闭或崩溃的节点上删除 pod，以避免关键工作负载中的数据丢失，例如在附加动态持久性卷时。 

    $ oc delete pod <old_pod> --force=true --grace-period=0
    Copy to Clipboard Toggle word wrap

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

8.9. 调查监控问题
复制链接

Red Hat OpenShift Service on AWS 包括一个预配置、预安装和自我更新的监控堆栈，用于监控核心平台组件。在 AWS 4 上的 Red Hat OpenShift Service 中，集群管理员可以选择性地为用户定义的项目启用监控。

如果出现问题，请使用这些步骤：

  • 您自己的指标不可用。
  • Prometheus 消耗大量磁盘空间。
  • KubePersistentVolumeFillingUp 警报正在触发 Prometheus。

8.9.1. 调查用户定义的项目指标不可用的原因
复制链接

通过 ServiceMonitor 资源，您可以确定如何使用用户定义的项目中的服务公开的指标。如果您创建了 ServiceMonitor 资源，但无法在 Metrics UI 中看到任何对应的指标，请按该流程中所述的步骤操作。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已为用户定义的项目启用并配置了监控。
  • 您已创建了 ServiceMonitor 资源。

流程

  1. 确保您的项目和资源没有不包括在用户工作负载监控中。以下示例使用 ns1 项目。

    1. 验证项目没有附加 openshift.io/user-monitoring=false 标签： 

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'
      Copy to Clipboard Toggle word wrap
      注意

      用户工作负载项目设置的默认标签为 openshift.io/user-monitoring=true。但是，除非手动应用了该标签，否则标签不可见。

    2. 验证 ServiceMonitor 和 PodMonitor 资源没有附加 openshift.io/user-monitoring=false 标签。以下示例检查 prometheus-example-monitor 服务监控器。 

      $ oc -n ns1 get servicemonitor prometheus-example-monitor --show-labels | grep 'openshift.io/user-monitoring=false'
      Copy to Clipboard Toggle word wrap

    3. 如果附加了标签，请删除该标签：

      从项目中删除该标签的示例

      $ oc label namespace ns1 'openshift.io/user-monitoring-'
      Copy to Clipboard Toggle word wrap

      从资源中删除标签的示例

      $ oc -n ns1 label servicemonitor prometheus-example-monitor 'openshift.io/user-monitoring-'
      Copy to Clipboard Toggle word wrap

      输出示例

      namespace/ns1 unlabeled
      Copy to Clipboard Toggle word wrap

  2. 在服务和 ServiceMonitor 资源配置中，检查对应的标签是否匹配。以下示例使用 prometheus-example-app 服务、prometheus-example-monitor 服务监控和 ns1 项目。

    1. 获取服务中定义的标签。 

      $ oc -n ns1 get service prometheus-example-app -o yaml
      Copy to Clipboard Toggle word wrap

      输出示例

        labels:
    app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

    2. 检查 ServiceMonitor 资源配置中的 matchLabels 定义是否与上一步中的标签输出匹配。 

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      apiVersion: v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - interval: 30s
    port: web
    scheme: http
  selector:
    matchLabels:
      app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

      注意

      您可以作为具有项目查看权限的开发者检查服务和 ServiceMonitor 资源标签。

  3. 在 openshift-user-workload-monitoring 项目中检查 Prometheus Operator 的日志。

    1. 列出 openshift-user-workload-monitoring 项目中的 Pod： 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap

      输出示例

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

    2. 从 prometheus-operator Pod 中的 prometheus-operator 容器获取日志。在以下示例中，Pod 名为 prometheus-operator-776fcbbd56-2nbfm： 

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator
      Copy to Clipboard Toggle word wrap

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

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

  4. 在 Red Hat OpenShift Service on AWS Web 控制台 UI 中的 Metrics 目标 页面中查看您的端点的目标状态。

    1. 登录到 Red Hat OpenShift Service on AWS web 控制台，进入 Observe → Targets。
    2. 在列表中找到指标端点，并在 Status 列中查看目标的状态。
    3. 如果 Status 为 Down，点端点的 URL 查看该指标目标的 Target Details 页面的更多信息。

  5. 在 openshift-user-workload-monitoring 项目中为 Prometheus Operator 配置 debug 级别日志记录。

    1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象： 

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      Copy to Clipboard Toggle word wrap

    2. 在 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
# ...
      Copy to Clipboard Toggle word wrap
    3. 保存文件以使改变生效。受影响的 prometheus-operator Pod 会自动重新部署。

    4. 确认 debug 日志级别已应用到 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署： 

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"
      Copy to Clipboard Toggle word wrap

      输出示例

              - --log-level=debug
      Copy to Clipboard Toggle word wrap

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

    5. 检查 prometheus-operator Pod 是否正在运行： 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap
      注意

      如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值，则 prometheus-operator Pod 可能无法成功重启。

    6. 查看 debug 日志，以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。

8.9.2. 确定为什么 Prometheus 消耗大量磁盘空间
复制链接

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如，customer_id 属性不绑定，因为它有无限多个可能的值。

每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能，并消耗大量磁盘空间。

当 Prometheus 消耗大量磁盘时，您可以使用以下方法：

  • 使用 Prometheus HTTP API 检查时间序列数据库(TSDB)状态，以了解有关哪些标签创建最多时间序列数据的更多信息。这样做需要集群管理员特权。
  • 检查正在收集的提取示例数量。

  • 要减少创建的唯一时间序列数量，您可以减少分配给用户定义的指标的未绑定属性数量

    注意

    使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

  • 对可在用户定义的项目中提取的示例数量实施限制。这需要集群管理员特权。

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 在 Red Hat OpenShift Service on AWS web 控制台中进入 Observe → Metrics。

  2. 在 Expression 字段中输入 Prometheus Query Language (PromQL) 查询。以下示例查询有助于识别可能导致高磁盘空间消耗的高卡性指标：

    • 通过运行以下查询，您可以识别具有最高提取示例数的十个作业： 

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
      Copy to Clipboard Toggle word wrap

    • 通过运行以下查询，您可以通过识别在上一小时内创建了最多时间序列数据的十个作业，从而找出相关的时间序列： 

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
      Copy to Clipboard Toggle word wrap

  3. 如果指标的提取示例数大于预期，请检查分配给指标的未绑定标签值数量：

    • 如果指标与用户定义的项目相关，请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
    • 如果指标与 Red Hat OpenShift Service on AWS 核心项目 有关，请 在红帽客户门户上创建一个红帽支持问题单。

  4. 以 dedicated-admin 身份登录时，按照以下步骤使用 Prometheus HTTP API 查看 TSDB 状态：

    1. 运行以下命令来获取 Prometheus API 路由 URL： 

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath='{.status.ingress[].host}')
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来提取身份验证令牌： 

      $ TOKEN=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap

    3. 运行以下命令，查询 Prometheus 的 TSDB 状态： 

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      Copy to Clipboard Toggle word wrap

      输出示例

      "status": "success","data":{"headStats":{"numSeries":507473,
"numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
"maxTime":1712257935346},"seriesCountByMetricName":
[{"name":"etcd_request_duration_seconds_bucket","value":51840},
{"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
...
      Copy to Clipboard Toggle word wrap

8.10. 诊断 OpenShift CLI（oc）问题
复制链接

8.10.1. 了解 OpenShift CLI（oc）日志级别
复制链接

使用 OpenShift CLI (oc)，您可以从终端创建应用程序并管理 Red Hat OpenShift Service on AWS 项目。

如果出现特定于 oc 命令的问题，将 oc 日志级别提高为输出 API 请求、API 响应以及命令生成的 curl 请求详情。这提供了特定的 oc 命令的底层操作信息，以帮助您了解故障的本质。

oc 日志级别范围从 1 到 10。下表提供了 oc 日志级别列表及其描述。

Expand
表 8.4. OpenShift CLI（oc）日志级别
日志级别描述

1 到 5

没有额外的日志记录到 stderr。

6

为 stderr 记录 API 请求。

7

将 API 请求和标头记录到 stderr。

8

记录 API 请求、标头和正文，以及 API 响应标头和正文到 stderr。

9

记录日志 API 请求、标头和正文、API 响应标头和正文，以及 curl 请求到 stderr。

10

记录日志 API 请求、标头和正文、API 响应标头和正文，以及 curl 请求到 stderr。记录的信息会更详细。

8.10.2. 指定 OpenShift CLI（oc）日志级别
复制链接

您可以通过提高命令的日志级别来调查 OpenShift CLI（oc）问题。

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

先决条件

  • 安装 OpenShift CLI (oc) 。

流程

  • 在运行 oc 命令时指定 oc 日志级别： 

    $ oc <command> --loglevel <log_level>
    Copy to Clipboard Toggle word wrap

    其中：

    <command>
    指定您正在运行的命令。
    <log_level>
    指定要应用到命令的日志级别。

  • 要获取当前用户的会话令牌，请运行以下命令： 

    $ oc whoami -t
    Copy to Clipboard Toggle word wrap

    输出示例

    sha256~RCV3Qcn7H-OEfqCGVI0CvnZ6...
    Copy to Clipboard Toggle word wrap

8.11. 已过期令牌故障排除
复制链接

8.11.1. 过期的离线访问令牌故障排除
复制链接

如果您使用 Red Hat OpenShift Service on AWS (ROSA) CLI、rosa，且 api.openshift.com 离线访问令牌过期，则会出现错误消息。当 sso.redhat.com 无效令牌时会出现这种情况。

输出示例

Can't get tokens ....
Can't get access tokens ....
Copy to Clipboard Toggle word wrap

流程

8.12. IAM 角色故障排除
复制链接

8.12.1. 解决 ocm-roles 和 user-role IAM 资源的问题
复制链接

当尝试使用 Red Hat OpenShift Service on AWS (ROSA) CLI rosa 创建集群时，您可能会收到错误。

输出示例

E: Failed to create cluster: The sts_user_role is not linked to account '1oNl'. Please create a user role and link it to the account.
Copy to Clipboard Toggle word wrap

此错误意味着 user-role IAM 角色没有链接到 AWS 帐户。此错误的最常见原因是红帽机构中的其他用户创建了 ocm-role IAM 角色。需要创建您的 user-role IAM 角色。

注意

在任何用户设置链接到红帽帐户的 ocm-role IAM 资源后，任何希望在该红帽机构中创建集群的后续用户都必须具有 user-role IAM 角色来置备集群。

流程

  • 使用以下命令评估 ocm-role 和 user-role IAM 角色的状态： 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap

    输出示例

    I: Fetching ocm roles
ROLE NAME                           ROLE ARN                                          LINKED  ADMIN
ManagedOpenShift-OCM-Role-1158  arn:aws:iam::2066:role/ManagedOpenShift-OCM-Role-1158   No      No
    Copy to Clipboard Toggle word wrap 

    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    输出示例

    I: Fetching user roles
ROLE NAME                                   ROLE ARN                                        LINKED
ManagedOpenShift-User.osdocs-Role  arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role  Yes
    Copy to Clipboard Toggle word wrap

在这些命令的结果中，您可以创建并链接缺少的 IAM 资源。

8.12.1.1. 创建 ocm-role IAM 角色
复制链接

您可以使用命令行界面(CLI)创建 ocm-role IAM 角色。

前提条件

  • 您有一个 AWS 帐户。
  • 在 OpenShift Cluster Manager 组织中具有红帽机构管理员权限。
  • 您有安装 AWS 范围的角色所需的权限。
  • 您已在安装主机上安装和配置了最新的 ROSA CLI rosa。

流程

  • 要使用基本权限创建 ocm-role IAM 角色，请运行以下命令： 

    $ rosa create ocm-role
    Copy to Clipboard Toggle word wrap

  • 要使用 admin 权限创建 ocm-role IAM 角色，请运行以下命令： 

    $ rosa create ocm-role --admin
    Copy to Clipboard Toggle word wrap

    此命令允许您通过指定特定属性来创建角色。以下示例输出显示选择了"自动模式"，它允许 ROSA CLI (rosa)创建 Operator 角色和策略。如需更多信息，请参阅"集群范围的角色创建"。

输出示例

I: Creating ocm role
? Role prefix: ManagedOpenShift
1 

? Enable admin capabilities for the OCM role (optional): No
2 

? Permissions boundary ARN (optional):
3 

? Role Path (optional):
4 

? Role creation mode: auto
5 

I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes
6 

I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
I: Linking OCM role
? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182
7 

? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes
8 

I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
Copy to Clipboard Toggle word wrap

1
所有创建的 AWS 资源的前缀值。在本例中，ManagedOpenShift 会预先填充所有 AWS 资源。
2
如果您希望此角色具有额外的 admin 权限，请选择。
注意

如果使用 --admin 选项，则不会显示此提示。

3
用于设置权限边界的策略的 Amazon 资源名称 (ARN)。
4
指定用户名的 IAM 路径。
5
选择创建 AWS 角色的方法。使用 auto 时，ROSA CLI 生成并链接角色和策略。在 auto 模式中，您收到一些不同的提示来创建 AWS 角色。
6
auto 方法询问您是否要使用您的前缀创建特定的 ocm-role。
7
确认您要将 IAM 角色与 OpenShift Cluster Manager 关联。
8
将创建的角色与 AWS 组织相关联。
8.12.1.2. 创建 user-role IAM 角色
复制链接

您可以使用命令行界面(CLI)创建 user-role IAM 角色。

前提条件

  • 您有一个 AWS 帐户。
  • 您已在安装主机上安装和配置了最新的 ROSA CLI rosa。

流程

  • 要使用基本权限创建 user-role IAM 角色，请运行以下命令： 

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

    此命令允许您通过指定特定属性来创建角色。以下示例输出显示选择了"自动模式"，它允许 ROSA CLI (rosa)创建 Operator 角色和策略。如需更多信息，请参阅"了解自动和手动部署模式"。

输出示例

I: Creating User role
? Role prefix: ManagedOpenShift
1 

? Permissions boundary ARN (optional):
2 

? Role Path (optional):
3 

? Role creation mode: auto
4 

I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes
5 

I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
I: Linking User role
? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes
6 

I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'
Copy to Clipboard Toggle word wrap

1
所有创建的 AWS 资源的前缀值。在本例中，ManagedOpenShift 会预先填充所有 AWS 资源。
2
用于设置权限边界的策略的 Amazon 资源名称 (ARN)。
3
指定用户名的 IAM 路径。
4
选择创建 AWS 角色的方法。使用 auto 时，ROSA CLI 生成并链接角色和策略。在 auto 模式中，您收到一些不同的提示来创建 AWS 角色。
5
auto 方法询问您是否要使用您的前缀创建特定的 user-role。
6
将创建的角色与 AWS 组织相关联。
8.12.1.3. 将您的 AWS 帐户与 IAM 角色关联
复制链接

您可以使用 ROSA CLI rosa 将 AWS 帐户与现有 IAM 角色关联或连接。

前提条件

  • 您有一个 AWS 帐户。
  • 您有安装 AWS 范围的角色所需的权限。如需更多信息，请参阅本节的"附加资源"。
  • 您已在安装主机上安装和配置了最新的 AWS (aws) 和 ROSA (rosa) CLI。

  • 您已创建了 ocm-role 和 user-role IAM 角色，但还没有将它们链接到 AWS 帐户。您可以运行以下命令来检查您的 IAM 角色是否已链接： 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap 
    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    如果这两个角色的 Linked 列中显示了 Yes，您已将角色链接到 AWS 帐户。

流程

  1. 在 ROSA CLI 中，使用 Amazon 资源名称(ARN)将 ocm-role 资源链接到红帽机构：

    注意

    您必须具有红帽机构管理员权限才能运行 rosa link 命令。将 ocm-role 资源与 AWS 帐户链接后，它会生效，并对机构的所有用户可见。 

    $ rosa link ocm-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    输出示例

    I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'
    Copy to Clipboard Toggle word wrap

  2. 在 ROSA CLI 中，使用 Amazon 资源名称(ARN)将您的 user-role 资源链接到您的红帽用户帐户： 

    $ rosa link user-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    输出示例

    I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'
    Copy to Clipboard Toggle word wrap

8.12.1.4. 将多个 AWS 帐户与红帽机构相关联
复制链接

您可以将多个 AWS 帐户与红帽机构相关联。通过关联多个帐户，您可以从红帽机构在任何关联的 AWS 帐户上创建 Red Hat OpenShift Service on AWS 集群。

使用此功能，您可以根据对业务有意义的特征在不同的 AWS 配置集上创建集群，例如，为每个区域使用一个 AWS 配置集来创建区域密集型环境。

前提条件

  • 您有一个 AWS 帐户。
  • 您可以使用 OpenShift Cluster Manager 创建集群。
  • 您有安装 AWS 范围的角色所需的权限。
  • 您已在安装主机上安装和配置了最新的 AWS (aws) 和 ROSA (rosa) CLI。
  • 您已为 Red Hat OpenShift Service on AWS 创建了 ocm-role 和 user-role IAM 角色。

流程

要关联一个额外的 AWS 帐户，首先在本地 AWS 配置中创建配置集。然后，通过在其他 AWS 帐户中创建 ocm-role、用户帐户角色，将帐户与您的红帽机构相关联。

要在附加区域中创建角色，在运行 rosa create 命令时指定 --profile <aws-profile> 参数，将 <aws_profile> 替换为附加帐户配置集名称：

  • 在创建 OpenShift Cluster Manager 角色时指定 AWS 帐户配置集： 

    $ rosa create --profile <aws_profile> ocm-role
    Copy to Clipboard Toggle word wrap

  • 在创建用户角色时指定 AWS 帐户配置集： 

    $ rosa create --profile <aws_profile> user-role
    Copy to Clipboard Toggle word wrap

  • 在创建帐户角色时指定 AWS 帐户配置集： 

    $ rosa create --profile <aws_profile> account-roles
    Copy to Clipboard Toggle word wrap
注意

如果没有指定配置集，则使用默认 AWS 配置集及其关联的 AWS 区域。

本文档论述了如何对集群部署错误进行故障排除。

8.13.1. 获取失败集群的信息
复制链接

如果集群部署失败，集群将进入"错误"状态。

流程

  • 运行以下命令来获取更多信息： 

    $ rosa describe cluster -c <my_cluster_name> --debug
    Copy to Clipboard Toggle word wrap

8.13.2. 使用 osdCcsAdmin 错误创建集群故障排除
复制链接

如果集群创建操作失败，您可能会收到以下出错信息。

输出示例

Failed to create cluster: Unable to create cluster spec: Failed to get access keys for user 'osdCcsAdmin': NoSuchEntity: The user with name osdCcsAdmin cannot be found.
Copy to Clipboard Toggle word wrap

流程

解决此问题的步骤：

  1. 删除堆栈： 

    $ rosa init --delete
    Copy to Clipboard Toggle word wrap

  2. 重新初始化您的帐户： 

    $ rosa init
    Copy to Clipboard Toggle word wrap

如果您还没有在 AWS 帐户中创建负载均衡器，则 Elastic Load Balancing (ELB) 的服务链接角色可能尚不存在。您可能会收到以下错误： 

Error: Error creating network Load Balancer: AccessDenied: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/ManagedOpenShift-Installer-Role/xxxxxxxxxxxxxxxxxxx is not authorized to perform: iam:CreateServiceLinkedRole on resource: arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
Copy to Clipboard Toggle word wrap

流程

  • 要解决这个问题，请确保您的 AWS 帐户中存在角色。如果没有，使用以下命令创建此角色： 

    aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" || aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
    Copy to Clipboard Toggle word wrap
    注意

    此命令只需要为每个帐户执行一次。

8.13.4. 修复无法删除的集群
复制链接

在某些情况下，如果您尝试删除集群，OpenShift Cluster Manager 中会出现以下错误。 

Error deleting cluster
CLUSTERS-MGMT-400: Failed to delete cluster <hash>: sts_user_role is not linked to your account. sts_ocm_role is linked to your organization <org number> which requires sts_user_role to be linked to your Red Hat account <account ID>.Please create a user role and link it to the account: User Account <account ID> is not authorized to perform STS cluster operations

Operation ID: b0572d6e-fe54-499b-8c97-46bf6890011c
Copy to Clipboard Toggle word wrap

如果您尝试从 CLI 删除集群，则会出现以下错误。 

E: Failed to delete cluster <hash>: sts_user_role is not linked to your account. sts_ocm_role is linked to your organization <org_number> which requires sts_user_role to be linked to your Red Hat account <account_id>.Please create a user role and link it to the account: User Account <account ID> is not authorized to perform STS cluster operations
Copy to Clipboard Toggle word wrap

当 user-role 被取消链接或删除，会发生此错误。

流程

  1. 运行以下命令来创建 user-role IAM 资源： 

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

  2. 在可以看到创建的角色后，您可以删除集群。以下确认，角色已创建并被链接： 

    I: Successfully linked role ARN <user role ARN> with account <account ID>
    Copy to Clipboard Toggle word wrap

Legal Notice
复制链接

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat