疑难解答：运营商问题 - 疑难解答 | 支持 | OpenShift Container Platform 4.17

操作符订阅条件类型
使用 CLI 查看操作符订阅状态
使用 CLI 查看操作符目录源状态
查询操作符 Pod 状态
收集操作符日志
禁用机器配置操作符自动重启
- 使用控制台禁用机器配置操作符自动重启
- 使用 CLI 禁用机器配置操作符自动重启
刷新失败的订阅
在卸载失败后重新安装操作符

操作符是打包、部署和管理 OpenShift Container Platform 应用程序的一种方法。它们就像软件供应商工程团队的扩展，监视 OpenShift Container Platform 环境并使用其当前状态实时做出决策。操作符旨在无缝处理升级，自动响应故障，并且不走捷径，例如跳过软件备份过程以节省时间。

OpenShift Container Platform 4.17 包含一组默认的操作符，这些操作符对于集群的正常运行是必需的。这些默认操作符由集群版本操作符 (CVO) 管理。

作为集群管理员，您可以使用 OpenShift Container Platform Web 控制台或 CLI 从 OperatorHub 安装应用程序操作符。然后，您可以将操作符订阅到一个或多个命名空间，以使其可供集群中的开发人员使用。应用程序操作符由操作符生命周期管理器 (OLM) 管理。

如果您遇到操作符问题，请验证操作符订阅状态。检查整个集群中的操作符 Pod 健康状况并收集操作符日志以进行诊断。

操作符订阅条件类型

订阅可以报告以下条件类型

表 1. 订阅条件类型
条件	描述
`CatalogSourcesUnhealthy`	一些或所有将在解析中使用的目录源都不健康。
`InstallPlanMissing`	缺少订阅的安装计划。
`InstallPlanPending`	订阅的安装计划正在等待安装。
`InstallPlanFailed`	订阅的安装计划已失败。
`ResolutionFailed`	订阅的依赖项解析已失败。

默认的 OpenShift Container Platform 集群操作符由集群版本操作符 (CVO) 管理，它们没有 `Subscription` 对象。应用程序操作符由操作符生命周期管理器 (OLM) 管理，它们具有 `Subscription` 对象。

其他资源

使用 CLI 查看操作符订阅状态

您可以使用 CLI 查看操作符订阅状态。

先决条件

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

步骤

列出操作符订阅
```
$ oc get subs -n <operator_namespace>
```

使用oc describe命令检查Subscription资源

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

在命令输出中，查找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
# ...

使用CLI查看操作符目录源状态

您可以使用CLI查看操作符目录源的状态。

先决条件

您可以作为具有 `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
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
# ...

在前面的示例输出中，最后观察到的状态是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

在前面的示例输出中，错误消息表明由于授权问题，目录源的索引镜像未能成功拉取。例如，索引镜像可能存储在需要登录凭据的注册表中。

其他资源

查询操作符Pod状态

您可以列出集群中运行的操作符Pod及其状态。您还可以收集详细的操作符Pod摘要。

先决条件

您可以作为具有 `cluster-admin` 角色的用户访问集群。
您的API服务仍在运行。
您已安装 OpenShift CLI ( `oc` )。

步骤

列出集群中运行的操作符。输出包括操作符版本、可用性和运行时间信息
```
$ oc get clusteroperators
```
列出在操作符命名空间中运行的操作符Pod，以及Pod状态、重启次数和运行时间
```
$ oc get pod -n <operator_namespace>
```

输出详细的操作符Pod摘要

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

如果操作符问题是节点特定的，请查询该节点上的操作符容器状态。

为节点启动一个调试Pod
```
$ oc debug node/my-node
```

将/host设置为调试shell中的根目录。调试Pod将宿主机根文件系统挂载到Pod内的/host。通过将根目录更改为/host，您可以运行包含在主机可执行路径中的二进制文件

# chroot /host

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

列出有关节点容器的详细信息，包括状态和关联的Pod ID
```
# crictl ps
```
列出有关节点上特定操作符容器的信息。以下示例列出了有关network-operator容器的信息
```
# crictl ps --name network-operator
```
退出调试shell。

收集操作符日志

如果您遇到操作符问题，您可以从操作符Pod日志中收集详细的诊断信息。

先决条件

您可以作为具有 `cluster-admin` 角色的用户访问集群。
您的API服务仍在运行。
您已安装 OpenShift CLI ( `oc` )。
您拥有控制平面或控制平面机器的完全限定域名。

步骤

列出在操作符命名空间中运行的操作符Pod，以及Pod状态、重启次数和运行时间
```
$ oc get pods -n <operator_namespace>
```
查看操作符Pod的日志
```
$ oc logs pod/<pod_name> -n <operator_namespace>
```
如果操作符Pod有多个容器，则前面的命令将产生一个错误，其中包含每个容器的名称。查询单个容器的日志
```
$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
```

如果API不可用，请改用SSH在每个控制平面节点上查看操作符Pod和容器日志。将<master-node>.<cluster_name>.<base_domain>替换为相应的值。

列出每个控制平面节点上的Pod

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

对于任何未显示Ready状态的操作符Pod，请详细检查Pod的状态。将<operator_pod_id>替换为前面命令输出中列出的操作符Pod的ID
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
```

列出与操作符Pod相关的容器

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

对于任何未显示Ready状态的操作符容器，请详细检查容器的状态。将<container_id>替换为前面命令输出中列出的容器ID
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
```

查看任何未显示Ready状态的操作符容器的日志。将<container_id>替换为前面命令输出中列出的容器ID

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

运行Red Hat Enterprise Linux CoreOS (RHCOS) 的OpenShift Container Platform 4.17集群节点是不可变的，并且依赖于操作符来应用集群更改。不建议使用SSH访问集群节点。在尝试通过SSH收集诊断数据之前，请先查看是否可以通过运行oc adm must gather和其他oc命令来收集足够的数据。但是，如果OpenShift Container Platform API不可用，或者kubelet在目标节点上运行不正常，则oc操作将受到影响。在这种情况下，可以使用ssh core@<node>.<cluster_name>.<base_domain>访问节点。

禁用机器配置操作符自动重启

当机器配置操作符 (MCO) 进行配置更改时，Red Hat Enterprise Linux CoreOS (RHCOS) 必须重启才能使更改生效。无论配置更改是自动的还是手动的，RHCOS 节点都会自动重启，除非它被暂停。

以下修改不会触发节点重启

当MCO检测到以下任何更改时，它会在不排水或重启节点的情况下应用更新
- 机器配置的spec.config.passwd.users.sshAuthorizedKeys参数中的SSH密钥更改。
- openshift-config命名空间中全局拉取密钥或拉取密钥的更改。
- Kubernetes API服务器操作符自动轮换/etc/kubernetes/kubelet-ca.crt证书颁发机构 (CA)。
当MCO检测到/etc/containers/registries.conf文件的更改时，例如添加或编辑ImageDigestMirrorSet、ImageTagMirrorSet或ImageContentSourcePolicy对象，它会排出相应的节点，应用更改，然后取消隔离节点。节点排水不会发生以下更改
- 添加具有为每个镜像设置pull-from-mirror = "digest-only"参数的注册表。
- 在注册表中添加具有pull-from-mirror = "digest-only"参数设置的镜像。
- 向unqualified-search-registries列表添加项目。

为避免不必要的干扰，您可以修改机器配置池 (MCP) 以防止操作符对机器配置进行更改后自动重启。

使用控制台禁用机器配置操作符自动重启

为避免机器配置操作员 (MCO) 所做的更改造成意外中断，您可以使用 OpenShift Container Platform Web 控制台修改机器配置池 (MCP)，以阻止 MCO 对该池中的节点进行任何更改。这可以防止通常作为 MCO 更新过程一部分的任何重启。

请参阅禁用机器配置操作员自动重启中的第二个NOTE。

先决条件

您可以作为具有 `cluster-admin` 角色的用户访问集群。

步骤

暂停或恢复自动 MCO 更新重启

暂停自动重启进程

以具有cluster-admin角色的用户身份登录 OpenShift Container Platform Web 控制台。
点击计算 → 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 报告True。

如果 MCP 在暂停时有待处理的更改，则已更新列为False，而正在更新为False。当已更新为True且正在更新为False时，则没有待处理的更改。

如果有待处理的更改（其中已更新和正在更新列均为False），建议尽快安排维护窗口进行重启。使用以下步骤恢复自动重启过程，以应用自上次重启以来已排队的更改。

恢复自动重启进程
1. 以具有cluster-admin角色的用户身份登录 OpenShift Container Platform Web 控制台。
2. 点击计算 → MachineConfigPools。
3. 在MachineConfigPools页面上，点击master或worker，具体取决于您想要暂停哪个节点的重启。
4. 在master或worker页面上，点击YAML。
5. 在 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)。
6. 要验证 MCP 是否已暂停，请返回MachineConfigPools页面。
  
  在MachineConfigPools页面上，已暂停列会为您修改的 MCP 报告False。
  
  如果 MCP 正在应用任何待处理的更改，则已更新列为False，而正在更新列为True。当已更新为True且正在更新为False时，则没有进一步的更改。

使用 CLI 禁用机器配置操作员自动重启

为避免机器配置操作员 (MCO) 所做的更改造成意外中断，您可以使用 OpenShift CLI (oc) 修改机器配置池 (MCP)，以阻止 MCO 对该池中的节点进行任何更改。这可以防止通常作为 MCO 更新过程一部分的任何重启。

请参阅禁用机器配置操作员自动重启中的第二个NOTE。

先决条件

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

步骤

暂停或恢复自动 MCO 更新重启

暂停自动重启进程

更新MachineConfigPool自定义资源，并将spec.paused字段设置为true。

控制平面 (master) 节点

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

工作节点

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

验证 MCP 是否已暂停

控制平面 (master) 节点

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

工作节点

$ 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

如果已更新列为False且正在更新为False，则有待处理的更改。当已更新为True且正在更新为False时，则没有待处理的更改。在前面的示例中，工作节点有待处理的更改。控制平面节点没有任何待处理的更改。

恢复自动重启进程
1. 更新MachineConfigPool自定义资源，并将spec.paused字段设置为false。
  控制平面 (master) 节点
  $ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master
  工作节点
  $ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker
  通过取消暂停 MCP，MCO 会应用所有暂停的更改并根据需要重启 Red Hat Enterprise Linux CoreOS (RHCOS)。
2. 验证 MCP 是否已恢复
  控制平面 (master) 节点
  $ oc get machineconfigpool/master --template='{{.spec.paused}}'
  工作节点
  $ oc get machineconfigpool/worker --template='{{.spec.paused}}'
  示例输出
  false
  spec.paused字段为false，MCP 已恢复。
3. 确定 MCP 是否有待处理的更改
  $ oc get machineconfigpool
  示例输出
  NAME CONFIG UPDATED UPDATING master rendered-master-546383f80705bd5aeaba93 True False worker rendered-worker-b4c51bb33ccaae6fc4a6a5 False True
  如果 MCP 正在应用任何待处理的更改，则已更新列为False，而正在更新列为True。当已更新为True且正在更新为False时，则没有进一步的更改。在前面的示例中，MCO 正在更新工作节点。

刷新失败的订阅

在 Operator Lifecycle Manager (OLM) 中，如果您订阅了引用网络上无法访问的镜像的操作符，则可以在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

结果，订阅卡在这个失败状态，操作符无法安装或升级。

您可以通过删除订阅、集群服务版本 (CSV) 和其他相关对象来刷新失败的订阅。重新创建订阅后，OLM 随后会重新安装操作符的正确版本。

先决条件

您有一个失败的订阅，无法拉取不可访问的 bundle 镜像。
您已确认正确的 bundle 镜像是可访问的。

步骤

从安装操作符的命名空间获取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 重新安装操作符。

验证

检查操作符是否已成功重新安装

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

在卸载失败后重新安装操作符

在尝试重新安装相同操作符之前，必须成功且完全卸载该操作符。未能正确完全卸载操作符可能会导致资源（例如项目或命名空间）卡在“终止”状态，并导致“解析资源错误”消息。例如

示例Project资源描述

...
    message: 'Failed to delete all resource types, 1 remaining: Internal error occurred:
      error resolving resource'
...

这些类型的问题可能会阻止操作符成功重新安装。

强制删除命名空间不太可能解决“终止”状态问题，并且可能导致集群行为不稳定或不可预测，因此最好尝试查找可能阻止命名空间删除的相关资源。有关更多信息，请参阅Red Hat 知识库解决方案 #4165791，并仔细注意注意事项和警告。

以下过程显示了当由于操作符先前安装的现有自定义资源定义 (CRD) 阻止相关命名空间成功删除而无法重新安装操作符时的故障排除方法。

步骤

检查是否有任何与操作符相关的命名空间卡在“终止”状态
```
$ oc get namespaces
```
示例输出
```
operator-ns-1                                       Terminating
```
检查在卸载失败后是否存在任何与操作符相关的 CRD
```
$ oc get crds
```
CRD 是全局集群定义；与 CRD 相关的实际自定义资源 (CR) 实例可能位于其他命名空间中，也可能是全局集群实例。
如果您知道任何 CRD 是由 Operator 提供或管理的，并且应该在卸载后删除，请删除该 CRD。
```
$ oc delete crd <crd_name>
```
检查卸载后是否还有任何与 Operator 相关的剩余 CR 实例，如果有，请删除这些 CR。
1. 卸载后，要搜索的 CR 类型可能难以确定，可能需要知道 Operator 管理哪些 CRD。例如，如果您正在对 etcd Operator 的卸载进行故障排除（etcd Operator 提供 EtcdCluster CRD），您可以搜索命名空间中剩余的 EtcdCluster CR。
  $ oc get EtcdCluster -n <namespace_name>
  或者，您可以在所有命名空间中搜索。
  $ oc get EtcdCluster --all-namespaces
2. 如果还有任何应该删除的剩余 CR，请删除这些实例。
  $ oc delete <cr_name> <cr_instance_name> -n <namespace_name>
检查命名空间删除是否已成功解决。
```
$ oc get namespace <namespace_name>
```
如果命名空间或其他 Operator 资源仍未干净卸载，请联系 Red Hat 支持。
使用 Web 控制台中的 OperatorHub 重新安装操作符。

验证

检查操作符是否已成功重新安装

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

其他资源

运营商问题疑难解答

操作符订阅条件类型

使用 CLI 查看操作符订阅状态

使用CLI查看操作符目录源状态

查询操作符Pod状态

收集操作符日志

禁用机器配置操作符自动重启

使用控制台禁用机器配置操作符自动重启

使用 CLI 禁用机器配置操作员自动重启

刷新失败的订阅

在卸载失败后重新安装操作符