7.6. Troubleshooting Operator 的问题
Operator 是一种打包、部署和管理 OpenShift Container Platform 应用程序的方法。它可以被看作是软件厂商的工程团队的扩展,可以在 OpenShift Container Platform 监控软件的运行情况,并根据软件的当前状态实时做出决策。Operator 被设计为用来无缝地处理升级过程,并对出现的错误自动进行响应,而且不会采取“捷径”(如跳过软件备份过程来节省时间)。
OpenShift Container Platform 4.8 包括了一组默认的 Operator,它们是集群正常工作所需的。这些默认 Operator 由 Cluster Version Operator(CVO)管理。
作为集群管理员,您可使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的应用程序 Operator。然后,您可将 Operator 订阅至一个或多个命名空间,供集群上的开发人员使用。应用程序 Operator 由 Operator Lifecycle Manager(OLM)进行管理。
如果遇到 Operator 问题,请验证 Operator 订阅状态。检查集群中的 Operator pod 健康状况,并收集 Operator 日志以进行诊断。
7.6.1. operator 订阅状况类型
订阅可报告以下状况类型:
状况 | 描述 |
---|---|
| 用于解析的一个或多个目录源不健康。 |
| 缺少订阅的安装计划。 |
| 订阅的安装计划正在安装中。 |
| 订阅的安装计划失败。 |
默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator(CVO)管理,它们没有 Subscription
对象。应用程序 Operator 由 Operator Lifecycle Manager(OLM)管理,它们具有 Subscription
对象。
7.6.2. 使用 CLI 查看 Operator 订阅状态
您可以使用 CLI 查看 Operator 订阅状态。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
列出 Operator 订阅:
$ oc get subs -n <operator_namespace>
使用
oc describe
命令检查Subscription
资源:$ oc describe sub <subscription_name> -n <operator_namespace>
在命令输出中,找到 Operator 订阅状况类型的
Conditions
部分。在以下示例中,CatalogSourcesUnhealthy
条件类型具有false
状态,因为所有可用目录源都健康:输出示例
Conditions: Last Transition Time: 2019-07-29T13:42:57Z Message: all available catalogsources are healthy Reason: AllCatalogSourcesHealthy Status: False Type: CatalogSourcesUnhealthy
默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator(CVO)管理,它们没有 Subscription
对象。应用程序 Operator 由 Operator Lifecycle Manager(OLM)管理,它们具有 Subscription
对象。
7.6.3. 使用 CLI 查看 Operator 目录源状态
您可以使用 CLI 查看 Operator 目录源的状态。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
列出命名空间中的目录源。例如,您可以检查
openshift-marketplace
命名空间,该命名空间用于集群范围的目录源:$ oc get catalogsources -n openshift-marketplace
输出示例
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-marketplace Red Hat Marketplace grpc Red Hat 55m redhat-operators Red Hat Operators grpc Red Hat 55m
使用
oc describe
命令获取有关目录源的详情和状态:$ oc describe catalogsource example-catalog -n openshift-marketplace
输出示例
Name: example-catalog Namespace: openshift-marketplace ... Status: Connection State: Address: example-catalog.openshift-marketplace.svc:50051 Last Connect: 2021-09-09T17:07:35Z Last Observed State: TRANSIENT_FAILURE Registry Service: Created At: 2021-09-09T17:05:45Z Port: 50051 Protocol: grpc Service Name: example-catalog Service Namespace: openshift-marketplace
在上例的输出中,最后观察到的状态是
TRANSIENT_FAILURE
。此状态表示目录源建立连接时出现问题。列出创建目录源的命名空间中的 pod:
$ oc get pods -n openshift-marketplace
输出示例
NAME READY STATUS RESTARTS AGE certified-operators-cv9nn 1/1 Running 0 36m community-operators-6v8lp 1/1 Running 0 36m marketplace-operator-86bfc75f9b-jkgbc 1/1 Running 0 42m example-catalog-bwt8z 0/1 ImagePullBackOff 0 3m55s redhat-marketplace-57p8c 1/1 Running 0 36m redhat-operators-smxx8 1/1 Running 0 36m
在命名空间中创建目录源时,会在该命名空间中为目录源创建一个 pod。在前面的示例中,
example-catalog-bwt8z
pod 的状态是ImagePullBackOff
。此状态表示拉取目录源的索引镜像存在问题。使用
oc describe
命令检查 pod 以获取更多详细信息:$ oc describe pod example-catalog-bwt8z -n openshift-marketplace
输出示例
Name: example-catalog-bwt8z Namespace: openshift-marketplace Priority: 0 Node: ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 48s default-scheduler Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd Normal AddedInterface 47s multus Add eth0 [10.131.0.40/23] from openshift-sdn Normal BackOff 20s (x2 over 46s) kubelet Back-off pulling image "quay.io/example-org/example-catalog:v1" Warning Failed 20s (x2 over 46s) kubelet Error: ImagePullBackOff Normal Pulling 8s (x3 over 47s) kubelet Pulling image "quay.io/example-org/example-catalog:v1" Warning Failed 8s (x3 over 47s) kubelet Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized Warning Failed 8s (x3 over 47s) kubelet Error: ErrImagePull
在前面的示例输出中,错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如,索引镜像可能存储在需要登录凭证的 registry 中。
7.6.4. 查询 Operator pod 状态
您可以列出集群中的 Operator pod 及其状态。您还可以收集详细的 Operator pod 概述。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - API 服务仍然可以正常工作。
-
已安装 OpenShift CLI(
oc
)。
流程
列出集群中运行的 Operator。输出包括 Operator 版本、可用性和运行时间信息:
$ oc get clusteroperators
列出在 Operator 命名空间中运行的 Operator pod,以及 pod 状态、重启和年龄:
$ oc get pod -n <operator_namespace>
输出详细的 Operator pod 概述:
$ oc describe pod <operator_pod_name> -n <operator_namespace>
如果 Operator 问题特定于某个节点,则在该节点上查询 Operator 容器状态。
为节点启动 debug pod:
$ oc debug node/my-node
将
/host
设为 debug shell 中的根目录。debug pod 在 pod 中的/host
中挂载主机的 root 文件系统。将根目录改为/host
,您可以运行主机可执行路径中包含的二进制文件:# chroot /host
注意运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.8 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,
oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。列出节点容器的详细信息,包括状态和关联的 pod ID:
# crictl ps
列出节点上特定 Operator 容器的信息。以下示例列出了
network-operator
容器的信息:# crictl ps --name network-operator
- 退出 debug shell。
7.6.5. 收集 Operator 日志
如果遇到 Operator 问题,您可以从 Operator pod 日志中收集详细诊断信息。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - API 服务仍然可以正常工作。
-
已安装 OpenShift CLI(
oc
)。 - 您有 control plane 或 control plane 机器的完全限定域名(也称为 master 机器)。
流程
列出在 Operator 命名空间中运行的 Operator pod,以及 pod 状态、重启和年龄:
$ oc get pods -n <operator_namespace>
检查 Operator pod 的日志:
$ oc logs pod/<pod_name> -n <operator_namespace>
如果 Operator pod 具有多个容器,则上述命令将会产生一个错误,其中包含每个容器的名称。从独立容器查询日志:
$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
如果 API 无法正常工作,请使用 SSH 来查看每个 control plane 节点上的 Operator pod 和容器日志。将
<master-node>.<cluster_name>.<base_domain>
替换为适当的值。列出每个 control plane 节点上的 pod:
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
对于任何未显示
Ready
状态的 Operator pod,详细检查 Pod 的状态。将<operator_pod_id>
替换为上一命令输出中列出的 Operator pod ID:$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
列出与 Operator pod 相关的容器:
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
对于任何未显示
Ready
状态的 Operator 容器,请详细检查容器的状态。将<container_id>
替换为上一命令输出中列出的容器 ID:$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
检查任何未显示
Ready
状态的 Operator 容器的日志。将<container_id>
替换为上一命令输出中列出的容器 ID:$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
注意运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.8 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行
oc adm must gather
和其他oc
命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。
7.6.6. 禁用 Machine Config Operator 自动重新引导
当 Machine Config Operator(MCO)进行配置更改时,Red Hat Enterprise Linux CoreOS(RHCOS)必须重启才能使更改生效。无论配置更改是自动还是手动的,RHCOS 节点都会自动重启,除非它已被暂停。
以下修改不会触发节点重新引导:
当 MCO 检测到以下任何更改时,它会在不排空或重启节点的情况下应用更新:
-
在机器配置的
spec.config.passwd.users.sshAuthorizedKeys
参数中更改 SSH 密钥。 -
在
openshift-config
命名空间中更改全局 pull secret 或 pull secret。 -
Kubernetes API Server Operator 自动轮转
/etc/kubernetes/kubelet-ca.crt
证书颁发机构(CA)。
-
在机器配置的
当 MCO 检测到对
/etc/containers/registries.conf
文件的更改时,如添加或编辑ImageDigestMirrorSet
或ImageTagMirrorSet
对象,它会排空对应的节点,应用更改并取消记录节点。节点排空不会发生以下更改:-
增加了一个 registry,带有为每个镜像(mirror)设置了
pull-from-mirror = "digest-only"
参数。 -
增加了一个镜像(mirror),带有在一个 registry 中设置的
pull-from-mirror = "digest-only"
参数。 -
在
unqualified-search-registries
列表中添加项目。
-
增加了一个 registry,带有为每个镜像(mirror)设置了
为了避免不必要的中断,您可以修改机器配置池(MCP)以防止在 Operator 更改机器配置后自动重启。
暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer
CA 证书。如果在 kube-apiserver-to-kubelet-signer
CA 证书过期且 MCO 尝试自动续订证书时,MCP 会暂停,但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc
命令失败,包括但不限于 oc debug
、oc logs
、oc exec
和 oc attach
。在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer
CA 证书过期的问题,且仅在短时间内暂停。
新 CA 证书会在自安装日期起的 292 天生成,并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转,请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。
7.6.6.1. 使用控制台禁用 Machine Config Operator 自动重新引导
为了避免对 Machine Config Operator(MCO)所做的更改造成不必要的中断,您可以使用 OpenShift Container Platform Web 控制台修改机器配置池(MCP),以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。
暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer
CA 证书。如果在 kube-apiserver-to-kubelet-signer
CA 证书过期且 MCO 尝试自动续订证书时,MCP 会暂停,但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc
命令失败,包括但不限于 oc debug
、oc logs
、oc exec
和 oc attach
。在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer
CA 证书过期的问题,且仅在短时间内暂停。
新 CA 证书会在自安装日期起的 292 天生成,并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转,请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
要暂停或取消暂停自动 MCO 更新重新引导:
暂停自动引导过程:
-
以具有
cluster-admin
角色的用户身份登录到 OpenShift Container Platform web 控制台。 -
点 Compute
MachineConfigPools。 - 在 MachineConfigPools 页面中,点击 master 或 worker,具体取决于您要暂停重新引导的节点。
- 在 master 或 worker 页面中,点 YAML。
在 YAML 中,将
spec.paused
字段更新为true
。MachineConfigPool 对象示例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool ... spec: ... paused: true 1
- 1
- 将
spec.paused
字段更新为true
以暂停重新引导。
要验证 MCP 是否已暂停,请返回到 MachineConfigPools 页面。
在 MachineConfigPools 页面中,您修改的 MCP 报告了 Paused 列中为 True。
如果 MCP 在暂停时有待处理的变化,Updated 列为 False,Updating 为 False。当 Updated 为 True 且 Updating 为 False 时,代表没有待处理的更改。
重要如果有尚未进行的更改( Updated 和 Updating 字段都是 False),建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程,以应用上一次重启后排队的更改。
-
以具有
取消暂停自动引导过程:
-
以具有
cluster-admin
角色的用户身份登录到 OpenShift Container Platform web 控制台。 -
点 Compute
MachineConfigPools。 - 在 MachineConfigPools 页面中,点击 master 或 worker,具体取决于您要暂停重新引导的节点。
- 在 master 或 worker 页面中,点 YAML。
在 YAML 中,将
spec.paused
字段更新为false
。MachineConfigPool 对象示例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool ... spec: ... paused: false 1
- 1
- 将
spec.paused
字段更新为false
以允许重启。
注意通过取消暂停 MCP,MCO 应用所有暂停的更改,根据需要重启 Red Hat Enterprise Linux CoreOS(RHCOS)。
要验证 MCP 是否已暂停,请返回到 MachineConfigPools 页面。
在 MachineConfigPools 页面中,您修改的 MCP 报告 Paused 列为 False。
如果 MCP 正在应用任何待处理的更改,Updated 列为 False,Updating 列为 True。当 Updated 为 True 且 Updating 为 False 时,不会再进行任何更改。
-
以具有
7.6.6.2. 使用 CLI 禁用 Machine Config Operator 自动重新引导
为了避免对 Machine Config Operator(MCO)所做的更改造成不必要的中断,您可以使用 OpenShift CLI(oc)来修改机器配置池(MCP),以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。
暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer
CA 证书。如果在 kube-apiserver-to-kubelet-signer
CA 证书过期且 MCO 尝试自动续订证书时,MCP 会暂停,但不会在暂停的 MCP 中跨节点应用新证书。这会导致多个 oc
命令失败,包括但不限于 oc debug
、oc logs
、oc exec
和 oc attach
。在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer
CA 证书过期的问题,且仅在短时间内暂停。
新 CA 证书会在自安装日期起的 292 天生成,并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转,请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
要暂停或取消暂停自动 MCO 更新重新引导:
暂停自动引导过程:
更新
MachineConfigPool
自定义资源,将spec.paused
字段设置为true
。Control plane(master)节点
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
Worker 节点
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
验证 MCP 是否已暂停:
Control plane(master)节点
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
Worker 节点
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
输出示例
true
spec.paused
字段为true
,MCP 暂停。确定 MCP 是否有待处理的更改:
# oc get machineconfigpool
输出示例
NAME CONFIG UPDATED UPDATING master rendered-master-33cf0a1254318755d7b48002c597bf91 True False worker rendered-worker-e405a5bdb0db1295acea08bcca33fa60 False False
如果 UPDATED 列是 False,UPDATING 为 False,则有待处理的更改。当 UPDATED 为 True 且 UPDATING 为 False 时,没有待处理的更改。在上例中,worker 节点有待处理的变化。control plane 节点(也称为 master 节点)没有任何待处理的更改。
重要如果有尚未进行的更改( Updated 和 Updating 字段都是 False),建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程,以应用上一次重启后排队的更改。
取消暂停自动引导过程:
更新
MachineConfigPool
自定义资源,将spec.paused
字段设置为false
。Control plane(master)节点
$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master
Worker 节点
$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker
注意通过取消暂停 MCP,MCO 应用所有暂停的更改,根据需要重启 Red Hat Enterprise Linux CoreOS(RHCOS)。
验证 MCP 是否已取消暂停:
Control plane(master)节点
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
Worker 节点
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
输出示例
false
spec.paused
字段为false
,MCP 被取消暂停。确定 MCP 是否有待处理的更改:
$ oc get machineconfigpool
输出示例
NAME CONFIG UPDATED UPDATING master rendered-master-546383f80705bd5aeaba93 True False worker rendered-worker-b4c51bb33ccaae6fc4a6a5 False True
如果 MCP 正在应用任何待处理的更改,UPDATED 列为 False,UPDATING 列为 True。当 UPDATED 为 True 且 UPDATING 为 False 时,没有进一步的更改。在上例中,MCO 正在更新 worker 节点。
7.6.7. 刷新失败的订阅
在 Operator Lifecycle Manager(OLM)中,如果您订阅的是引用网络中无法访问的镜像的 Operator,您可以在 openshift-marketplace
命名空间中找到带有以下错误的作业:
输出示例
ImagePullBackOff for Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
输出示例
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
因此,订阅会处于这个失败状态,Operator 无法安装或升级。
您可以通过删除订阅、集群服务版本(CSV)及其他相关对象来刷新失败的订阅。重新创建订阅后,OLM 会重新安装 Operator 的正确版本。
先决条件
- 您有一个失败的订阅,无法拉取不能访问的捆绑包镜像。
- 已确认可以访问正确的捆绑包镜像。
流程
从安装 Operator 的命名空间中获取
Subscription
和ClusterServiceVersion
对象的名称:$ oc get sub,csv -n <namespace>
输出示例
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
删除订阅:
$ oc delete subscription <subscription_name> -n <namespace>
删除集群服务版本:
$ oc delete csv <csv_name> -n <namespace>
在
openshift-marketplace
命名空间中获取所有失败的作业的名称和相关配置映射:$ oc get job,configmap -n openshift-marketplace
输出示例
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
删除作业:
$ oc delete job <job_name> -n openshift-marketplace
这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。
删除配置映射:
$ oc delete configmap <configmap_name> -n openshift-marketplace
- 在 Web 控制台中使用 OperatorHub 重新安装 Operator。
验证
检查是否已成功重新安装 Operator:
$ oc get sub,csv,installplan -n <namespace>