17.2. 故障排除和维护电信核心 CNF 集群
17.2.1. 故障排除和维护电信核心 CNF 集群
排除故障和维护是每周的任务，如果您没有工具来达到您的目标，无论您要更新组件或调查问题，都可能会是一个挑战。挑战的一部分是知道在哪里以及如何搜索工具和答案。
要维护并排除需要高带宽网络吞吐量的裸机环境，请参阅以下步骤。
此故障排除信息不是配置 OpenShift Container Platform 或开发 Cloud-native Network Function (CNF)应用程序的参考。
有关为电信开发 CNF 应用程序的详情，请参考 红帽 Kubernetes 的最佳实践。
17.2.1.1. 云原生网络功能
如果您要将 OpenShift Container Platform 用于电信 Cloud-native Network Function (CNF)应用程序，请学习 CNFs 可帮助您了解您可能遇到的问题。
要了解有关 CNF 及其演进的更多信息，请参阅 VNF 和 CNF，其区别是什么？
17.2.1.2. 获得支持
如果您在执行一个流程时遇到问题，请访问红帽客户门户。在客户门户网站中，您可以以各种方式找到帮助：
- 搜索或浏览红帽知识库，了解有关红帽产品的文章和解决方案。
- 向红帽支持提交支持问题单。
- 访问其他产品文档。
要识别部署的问题，您可以使用调试工具或检查部署的健康状况端点。在对部署进行调试或获取健康信息后，您可以在解决方案或提交支持票据中搜索红帽知识库。
17.2.1.2.1. 关于红帽知识库
红帽知识库提供丰富的内容以帮助您最大程度地利用红帽的产品和技术。红帽知识库包括文章、产品文档和视频，概述了安装、配置和使用红帽产品的最佳实践。另外，您还可以搜索已知问题的解决方案，其提供简洁的根原因描述和补救措施。
17.2.1.2.2. 搜索红帽知识库
如果出现 OpenShift Container Platform 问题，您可以先进行搜索，以确定红帽知识库中是否已存在相关的解决方案。
先决条件
- 您有红帽客户门户网站帐户。
流程
- 登录到 红帽客户门户网站。
- 点 Search。
在搜索字段中，输入与问题相关的关键字和字符串，包括：
- OpenShift Container Platform 组件（如 etcd）
- 相关步骤（比如 安装）
- 警告、错误消息和其他与输出与特定的问题相关
- 点 Enter 键。
- 可选： 选择 OpenShift Container Platform 产品过滤器。
- 可选： 选择 Documentation 内容类型过滤器。
17.2.1.2.3. 提交支持问题单
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。 - 您有红帽客户门户网站帐户。
- 您有红帽标准订阅或高级订阅。
流程
- 登录到红帽客户门户网站的客户支持 页面。
- 点 Get support。
在 客户支持 页面的 Cases 选项卡中：
- 可选：根据需要更改预先填充的帐户和所有者详情。
- 为您的问题选择适当的类别，如 Bug 或 Defect，然后点 Continue。
输入以下信息：
- 在 Summary 字段中，输入简要但描述性问题概述，以及有关所经历的症状的详细信息，以及您的预期。
- 从 Product 下拉菜单中选择 OpenShift Container Platform。
- 从 Version 下拉菜单中选择 4.17。
- 查看推荐的红帽知识库解决方案列表，它们可能会与您要报告的问题相关。如果建议的文章没有解决这个问题，请点 Continue。
- 查看更新的推荐红帽知识库解决方案列表，它们可能会与您要报告的问题相关。这个列表的范围会缩小，因为您在创建问题单的过程中提供了更多信息。如果建议的文章没有解决这个问题，请点 Continue。
- 请确保提供的帐户信息是正确的，如果需要，请相应调整。
检查自动填充的 OpenShift Container Platform 集群 ID 是否正确。如果不正确，请手动提供集群 ID。
使用 OpenShift Container Platform Web 控制台手动获得集群 ID：
-
进入到 Home
Overview。 - 该值包括在 Details 中的 Cluster ID 项中。
-
进入到 Home
另外，也可以通过 OpenShift Container Platform Web 控制台直接创建新的支持问题单，并自动填充集群 ID。
-
从工具栏导航至 （？）help
Open Support Case。 - Cluster ID 的值会被自动填充 。
-
从工具栏导航至 （？）help
要使用 OpenShift CLI（
oc）获取集群 ID，请运行以下命令：$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
完成以下提示的问题，点 Continue:
- 您遇到什么情况？您期望发生什么情况？
- 对业务的影响价值。
- 您在哪里遇到此行为？什么环境？
- 此行为何时发生？发生频率？重复发生？是否只在特定时间发生？
-
上传相关的诊断数据文件并点击 Continue。建议您将使用
oc adm must-gather命令收集的数据作为起点，并提供这个命令没有收集的与您的具体问题相关的其他数据。 - 输入相关问题单管理详情，点 Continue。
- 预览问题单详情，点 Submit。
17.2.2. 常规故障排除
遇到问题时，第一步是找到问题发生的特定区域。要缩小潜在的问题区域，请完成一个或多个任务：
- 查询集群
- 检查 pod 日志
- 调试 pod
- 检查事件
17.2.2.1. 查询集群
获取有关集群的信息，以便更准确地找到潜在的问题。
流程
运行以下命令来切换到项目：
$ oc project <project_name>
运行以下命令，在该命名空间中查询集群版本、集群 Operator 和节点：
$ oc get clusterversion,clusteroperator,node
输出示例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.16.11 True False 62d Cluster version is 4.16.11 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/authentication 4.16.11 True False False 62d clusteroperator.config.openshift.io/baremetal 4.16.11 True False False 62d clusteroperator.config.openshift.io/cloud-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/cloud-credential 4.16.11 True False False 62d clusteroperator.config.openshift.io/cluster-autoscaler 4.16.11 True False False 62d clusteroperator.config.openshift.io/config-operator 4.16.11 True False False 62d clusteroperator.config.openshift.io/console 4.16.11 True False False 62d clusteroperator.config.openshift.io/control-plane-machine-set 4.16.11 True False False 62d clusteroperator.config.openshift.io/csi-snapshot-controller 4.16.11 True False False 62d clusteroperator.config.openshift.io/dns 4.16.11 True False False 62d clusteroperator.config.openshift.io/etcd 4.16.11 True False False 62d clusteroperator.config.openshift.io/image-registry 4.16.11 True False False 55d clusteroperator.config.openshift.io/ingress 4.16.11 True False False 62d clusteroperator.config.openshift.io/insights 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-apiserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-scheduler 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-storage-version-migrator 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-api 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-approver 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-config 4.16.11 True False False 62d clusteroperator.config.openshift.io/marketplace 4.16.11 True False False 62d clusteroperator.config.openshift.io/monitoring 4.16.11 True False False 62d clusteroperator.config.openshift.io/network 4.16.11 True False False 62d clusteroperator.config.openshift.io/node-tuning 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-apiserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-samples 4.16.11 True False False 35d clusteroperator.config.openshift.io/operator-lifecycle-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.16.11 True False False 62d clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/service-ca 4.16.11 True False False 62d clusteroperator.config.openshift.io/storage 4.16.11 True False False 62d NAME STATUS ROLES AGE VERSION node/ctrl-plane-0 Ready control-plane,master,worker 62d v1.29.7 node/ctrl-plane-1 Ready control-plane,master,worker 62d v1.29.7 node/ctrl-plane-2 Ready control-plane,master,worker 62d v1.29.7
如需更多信息，请参阅 "oc get" 和 "Reviewing pod status"。
17.2.2.2. 检查 pod 日志
从 pod 中获取日志，以便您可以查看日志的问题。
流程
运行以下命令列出 pod：
$ oc get pod
输出示例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
运行以下命令检查 pod 日志文件：
$ oc logs -n <namespace> busybox-1
如需更多信息，请参阅"oc logs"、"Logging"和"检查 pod 和容器日志"。
其他资源
17.2.2.3. 描述 pod
描述 pod 会为您提供有关该 pod 的信息，以帮助进行故障排除。Events 部分提供有关 pod 和其中的容器的详细信息。
流程
运行以下命令来描述 pod：
$ oc describe pod -n <namespace> busybox-1
输出示例
Name: busybox-1 Namespace: busy Priority: 0 Service Account: default Node: worker-3/192.168.0.0 Start Time: Mon, 27 Nov 2023 14:41:25 -0500 Labels: app=busybox pod-template-hash=<hash> Annotations: k8s.ovn.org/pod-networks: … Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Pulled 41m (x170 over 7d1h) kubelet Container image "quay.io/quay/busybox:latest" already present on machine Normal Created 41m (x170 over 7d1h) kubelet Created container busybox Normal Started 41m (x170 over 7d1h) kubelet Started container busybox
如需更多信息，请参阅"oc describe"。
其他资源
17.2.2.4. 查看事件
您可以查看给定命名空间中的事件以查找潜在的问题。
流程
运行以下命令，检查命名空间中的事件：
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp" 1- 1
- 添加
--sort-by=".metadata.creationTimestamp"标志会将最新的事件放在输出的末尾。
可选：如果指定命名空间中的事件没有提供足够信息，请运行以下命令将查询扩展到所有命名空间：
$ oc get events -A --sort-by=".metadata.creationTimestamp" 1- 1
--sort-by=".metadata.creationTimestamp"标志将最新的事件放在输出的末尾。
要过滤集群中所有事件的结果，您可以使用
grep命令。例如，如果您查找错误，则错误可能会出现在输出的两个不同部分中：TYPE或MESSAGE部分。使用grep命令，您可以搜索关键字，如错误或失败。例如，通过运行以下命令搜索包含
warning或error的信息：$ oc get events -A | grep -Ei "warning|error"
输出示例
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE openshift 59s Warning FailedMount pod/openshift-1 MountVolume.SetUp failed for volume "v4-0-config-user-idp-0-file-data" : references non-existent secret key: test
可选： 要清理事件并只查看周期性事件，您可以通过运行以下命令来删除相关命名空间中的事件：
$ oc delete events -n <namespace> --all
如需更多信息，请参阅"监视集群事件"。
其他资源
17.2.2.5. 连接到 pod
您可以使用 oc rsh 命令直接连接到当前运行的 pod，该命令为您提供了该 pod 上的 shell。
在运行低延迟应用程序的 pod 中，运行 oc rsh 命令时可能会出现延迟问题。只有在无法使用 oc debug 命令连接到节点时，才使用 oc rsh 命令。
流程
运行以下命令来连接到您的 pod：
$ oc rsh -n <namespace> busybox-1
如需更多信息，请参阅"oc rsh"和"访问运行的 pod"。
17.2.2.6. 调试 pod
在某些情况下，您不想直接与生产环境中的 pod 交互。
为了避免干扰正在运行的流量，您可以使用作为原始 pod 副本的二级 pod。二级 pod 使用与原始 pod 相同的组件，但没有运行流量。
流程
运行以下命令列出 pod：
$ oc get pod
输出示例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
运行以下命令来调试 pod：
$ oc debug -n <namespace> busybox-1
输出示例
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
如果您没有看到 shell 提示符，请按 Enter 键。
如需更多信息，请参阅"oc debug"和"启动具有 root 访问权限的 debug pod"。
17.2.2.7. 在 pod 上运行命令
如果要在不直接登录 pod 的情况下在 pod 上运行命令或一组命令，您可以使用 oc exec -it 命令。您可以快速与 pod 交互，以获取 pod 的进程或输出信息。常见的用例是在脚本内运行 oc exec -it 命令，以在副本集或部署中的多个 pod 上运行相同的命令。
在运行低延迟应用程序的 pod 中，oc exec 命令可能会导致延迟问题。
流程
要在 pod 上运行命令而无需登录它，请运行以下命令：
$ oc exec -it <pod> -- <command>
如需更多信息，请参阅"oc exec"和"在容器中执行远程命令"。
其他资源
17.2.3. 集群维护
在电信网络中，您必须更关注某些配置，因为裸机部署的性质。您可以通过完成这些任务来更有效地进行故障排除：
- 监控失败的硬件组件或失败的硬件组件
- 定期检查集群 Operator 的状态
对于硬件监控，请联系您的硬件厂商以查找适合您的硬件的日志工具。
17.2.3.1. 检查集群 Operator
定期检查集群 Operator 的状态，以便在早期发现问题。
流程
运行以下命令，检查集群 Operator 的状态：
$ oc get co
17.2.3.2. 监视失败的 pod
要减少故障排除时间，请定期监控集群中的失败 pod。
流程
要监视失败的 pod，请运行以下命令：
$ oc get po -A | grep -Eiv 'complete|running'
17.2.4. 安全性
实施可靠的集群安全配置文件对于构建弹性电信网络非常重要。
17.2.4.1. 身份验证
确定集群中的身份提供程序。有关支持的身份提供程序的更多信息，请参阅 身份验证和授权 中的"支持身份提供程序"。
了解配置了哪些提供程序后，您可以检查 openshift-authentication 命名空间，以确定是否存在潜在的问题。
流程
运行以下命令，检查
openshift-authentication命名空间中的事件：$ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
运行以下命令，检查
openshift-authentication命名空间中的 pod：$ oc get pod -n openshift-authentication
可选：如果需要更多信息，请运行以下命令来检查其中一个正在运行的 pod 的日志：
$ oc logs -n openshift-authentication <pod_name>
其他资源
17.2.5. 证书维护
持续集群身份验证需要证书维护。作为集群管理员，您必须手动续订某些证书，而其他证书则由集群自动续订。
了解 OpenShift Container Platform 中的证书以及如何使用以下资源维护它们：
17.2.5.1. 管理员手动管理的证书
以下证书必须由集群管理员续订：
- 代理证书
- API 服务器的用户置备的证书
17.2.5.1.1. 管理代理证书
通过代理证书，用户可以指定在平台组件创建出口连接时使用的一个或多个自定义证书颁发机构(CA)证书。
某些 CA 设置过期日期，您可能需要每两年续订这些证书。
如果您最初没有设置请求的证书，您可以以多种方式确定证书过期。大多数云原生网络功能(CNF)使用没有特别设计用于基于浏览器的连接的证书。因此，您需要从部署的 ConfigMap 对象拉取证书。
流程
要获得过期日期，请针对证书文件运行以下命令：
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
有关确定代理证书和何时更新代理证书的更多信息，请参阅 安全性和合规性 中的"代理证书"。
其他资源
17.2.5.1.2. 用户置备的 API 服务器证书
客户端可通过 api.<cluster_name>.<base_domain> 访问集群外部的 API 服务器。您可能希望客户端使用不同主机名访问 API 服务器，无需向客户端发布集群管理的证书颁发机构 (CA) 证书。您必须设置自定义默认证书，供 API 服务器在提供内容时使用。
如需更多信息，请参阅 安全和合规性中的"为 API 服务器用户提供的证书"
其他资源
17.2.5.2. 由集群管理的证书
只有在日志中检测到问题时，才需要检查集群管理的证书。以下证书由集群自动管理：
- 服务 CA 证书
- 节点证书
- Bootstrap 证书
- etcd 证书
- olm 证书
- Machine Config Operator 证书
- 监控和集群日志记录 Operator 组件证书
- Control plane 证书
- 入口证书（Ingress certificate）
其他资源
17.2.5.2.1. 由 etcd 管理的证书
etcd 证书用于 etcd 成员对等点和加密客户端流量之间的加密通信。证书会在集群中自动更新，提供所有节点和所有服务间的通信是最新的。因此，如果您的集群可能会在特定时间段内丢失组件之间的通信，这与 etcd 证书生命周期结束时，建议提前续订证书。例如，由于节点在不同时间重新引导，升级期间可能会丢失通信。
您可以运行以下命令来手动续订 etcd 证书：
$ for each in $(oc get secret -n openshift-etcd | grep "kubernetes.io/tls" | grep -e \ "etcd-peer\|etcd-serving" | awk '{print $1}'); do oc get secret $each -n openshift-etcd -o \ jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -noout -enddate; done
有关更新 etcd 证书的更多信息，请参阅 在 OpenShift 4 中检查 etcd 证书过期。有关 etcd 证书的更多信息，请参阅 安全和合规性 中的"etcd 证书"。
其他资源
17.2.5.2.2. 节点证书
节点证书是自签名证书，这意味着它们由集群签名，它们源自由 bootstrap 过程生成的内部证书颁发机构(CA)。
安装集群后，集群会自动更新节点证书。
如需更多信息，请参阅 安全和合规性 中的"节点证书"。
其他资源
17.2.5.2.3. 服务 CA 证书
service-ca 是一个 Operator，在部署 OpenShift Container Platform 集群时创建自签名证书颁发机构(CA)。这允许用户在其部署中添加证书，而无需手动创建证书。服务 CA 证书是自签名证书。
如需更多信息，请参阅 安全和合规性 中的"服务 CA 证书"。
其他资源
17.2.6. Machine Config Operator
Machine Config Operator 为集群管理员提供有用的信息，并控制直接在裸机主机上运行的信息。
Machine Config Operator 区分集群中的不同节点组，允许 control plane 节点和 worker 节点使用不同的配置运行。这些节点组运行 worker 或应用程序 pod，它们称为 MachineConfigPool (mcp)组。同一机器配置适用于所有节点，或仅在集群的一个 MCP 上应用。
有关如何在电信核心集群中应用 MCP 的更多信息，请参阅更新 前将 MachineConfigPool 标签应用到节点。
如需有关 Machine Config Operator 的更多信息，请参阅 Machine Config Operator。
17.2.6.1. Machine Config Operator 的目的
Machine Config Operator (MCO)管理并应用 Red Hat Enterprise Linux CoreOS (RHCOS)和容器运行时的配置和更新，包括内核和 kubelet 之间的所有配置和更新。管理 RHCOS 非常重要，因为大多数电信公司在裸机硬件上运行，并使用某种硬件加速器或内核修改。手动将机器配置应用到 RHCOS 可能会导致问题，因为 MCO 监控每个节点及其应用的内容。
您必须考虑这些次要组件，以及 MCO 如何能够帮助您有效地管理集群。
您必须使用 MCO 在 worker 或 control plane 节点上执行所有更改。不要手动更改 RHCOS 或节点文件。
17.2.6.2. 同时应用多个机器配置文件
当您需要为集群中的一组节点（也称为机器配置池(MCP)）更改机器配置时，有时必须使用几个不同的机器配置文件应用更改。节点需要重启才能应用机器配置文件。将每个机器配置文件应用到集群后，所有节点都会重启受机器配置文件影响的所有节点。
要防止节点为每个机器配置文件重启，您可以通过暂停新机器配置文件更新的每个 MCP 来同时应用所有更改。
流程
运行以下命令来暂停受影响的 MCP：
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'将所有机器配置更改应用到集群后，运行以下命令：
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
这允许 MCP 中的节点重新引导到新配置中。
17.2.7. 裸机节点维护
您可以连接到节点以进行常规故障排除。然而，在某些情况下，您需要在某些硬件组件上执行故障排除或维护任务。本节讨论执行该硬件维护所需的主题。
17.2.7.1. 连接到集群中的裸机节点
您可以连接到裸机集群节点，以进行常规维护任务。
不建议或不支持从主机操作系统配置集群节点。
要排除节点的问题，您可以执行以下任务：
- 从节点检索日志
- 使用调试
- 使用 SSH 连接到节点
只有在无法使用 oc debug 命令连接到节点时，才使用 SSH。
流程
运行以下命令，从节点检索日志：
$ oc adm node-logs <node_name> -u crio
运行以下命令使用调试：
$ oc debug node/<node_name>
将
/host设置为 debug shell 中的根目录。debug pod 在 pod 中的/host中挂载主机的 root 文件系统。将根目录改为/host，您可以运行主机可执行路径中包含的二进制文件：# chroot /host
输出
You are now logged in as root on the node
可选：运行以下命令来使用 SSH 连接到节点：
$ ssh core@<node_name>
17.2.7.2. 将应用程序移到集群中的 pod
对于调度的硬件维护，您需要考虑如何将应用程序 pod 移到集群中的其他节点，而不影响 pod 工作负载。
流程
运行以下命令，将节点标记为不可调度：
$ oc adm cordon <node_name>
当节点不可调度时，不能将 pod 调度到该节点上。如需更多信息，请参阅"使用节点"。
在移动 CNF 应用程序时，您可能需要提前验证集群中有足够的 worker 节点，因为反关联性和 pod 中断预算。
其他资源
17.2.7.3. DIMM 内存替换
双线内存模块(DIMM)问题有时会在服务器重启后才会出现。您可以检查这些问题的日志文件。
当您执行标准重启且服务器没有启动时，您可以在控制台中看到一条有故障 DIMM 内存的消息。在这种情况下，您可以确认出现故障的 DIMM，如果剩余的内存足够，则继续重新启动。然后，您可以调度一个维护窗口来替换有问题的 DIMM。
有时，事件日志中的信息指示了错误的内存模块。在这些情况下，您可以在服务器重启前调度内存替换。
17.2.7.4. 磁盘替换
如果您没有通过独立磁盘的硬件或软件冗余阵列(RAID)配置磁盘冗余，您需要检查以下内容：
- 磁盘是否包含正在运行的 pod 镜像？
- 磁盘是否包含 pod 的持久性数据？
如需更多信息，请参阅 存储中的"OpenShift Container Platform 存储概述 "。
17.2.7.5. 集群网卡替换
当您替换网卡时，MAC 地址会改变。MAC 地址可以是 DHCP 或 SR-IOV Operator 配置、路由器配置、防火墙规则或应用程序 Cloud-native Network Function (CNF)配置的一部分。在替换网卡后恢复节点之前，您必须验证这些配置是否已更新。
如果您没有对网络中的 MAC 地址更改的具体流程，请联系您的网络管理员或网络硬件供应商。
