4.13. Troubleshooting Operator 的问题

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

4.13.1. operator 订阅状况类型

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

表 4.3. 订阅状况类型
状况	描述
`CatalogSourcesUnhealthy`	用于解析的一个或多个目录源不健康。
`InstallPlanMissing`	缺少订阅的安装计划。
`InstallPlanPending`	订阅的安装计划正在安装中。
`InstallPlanFailed`	订阅的安装计划失败。
`ResolutionFailed`	订阅的依赖项解析失败。

注意

默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator（CVO）管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。

其他资源

4.13.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 状态，因为所有可用目录源都健康：

输出示例

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
# ...

注意

4.13.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
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

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

其他资源

4.13.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 容器状态。
1. 为节点启动 debug pod：
```
$ oc debug node/my-node
```
2. 将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：
```
# chroot /host
```
  注意
  运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.13 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。
3. 列出节点容器的详细信息，包括状态和关联的 pod ID:
```
# crictl ps
```
4. 列出节点上特定 Operator 容器的信息。以下示例列出了 network-operator 容器的信息：
```
# crictl ps --name network-operator
```
5. 退出 debug shell。

4.13.5. 收集 Operator 日志

如果遇到 Operator 问题，您可以从 Operator pod 日志中收集详细诊断信息。

先决条件

您可以使用具有 cluster-admin 角色的用户访问集群。
API 服务仍然可以正常工作。
已安装 OpenShift CLI(oc)。
您有 control plane 或 control plane 机器的完全限定域名。

流程

列出在 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> 替换为适当的值。
1. 列出每个 control plane 节点上的 pod：
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
```
2. 对于任何未显示 Ready 状态的 Operator pod，详细检查 Pod 的状态。将 <operator_pod_id> 替换为上一命令输出中列出的 Operator pod ID:
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
```
3. 列出与 Operator pod 相关的容器：
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
```
4. 对于任何未显示 Ready 状态的 Operator 容器，请详细检查容器的状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
```
5. 检查任何未显示 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.13 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

4.13.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 或 ImageContentSourcePolicy 对象，它会排空对应的节点，应用更改并取消记录节点。对于以下更改，节点排空不会发生：
- 增加了一个 registry，带有为每个镜像（mirror）设置了 pull-from-mirror = "digest-only" 参数。
- 增加了一个镜像（mirror），带有在一个 registry 中设置的 pull-from-mirror = "digest-only" 参数。
- 在 unqualified-search-registries 列表中添加项目。

为了避免不必要的中断，您可以修改机器配置池（MCP）以防止在 Operator 更改机器配置后自动重启。

注意

暂停 MCP 可防止 MCO 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。

当 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时，MCO 无法将新轮转的证书推送到这些节点。这会导致集群降级，并在多个 oc 命令中造成失败，包括 oc debug、oc logs、oc exec 和 oc attach。如果在轮转证书时，如果 MCP 被暂停，则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。

在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。

新 CA 证书会在自安装日期起的 292 天生成，并在自该日期起的 365 天后删除。要确定下一个自动 CA 证书轮转，请参阅 Red Hat OpenShift 4 中的了解 CA 证书自动续订。

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

为了避免对 Machine Config Operator（MCO）所做的更改造成不必要的中断，您可以使用 OpenShift Container Platform Web 控制台修改机器配置池（MCP），以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。

注意

请参阅第二个有关禁用 Machine Config Operator 自动重新引导的备注。

先决条件

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

流程

要暂停或取消暂停自动 MCO 更新重新引导：

暂停自动引导过程：
1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。
2. 点 Compute MachineConfigPools。
3. 在 MachineConfigPools 页面中，点击 master 或 worker，具体取决于您要暂停重新引导的节点。
4. 在 master 或 worker 页面中，点 YAML。
5. 在 YAML 中，将 spec.paused 字段更新为 true。
  MachineConfigPool 对象示例
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
# ...
spec:
# ...
  paused: true 1
# ...
```
  1
  将 spec.paused 字段更新为 true 以暂停重新引导。
6. 要验证 MCP 是否已暂停，请返回到 MachineConfigPools 页面。
  在 MachineConfigPools 页面中，您修改的 MCP 报告了 Paused 列中为 True。
  如果 MCP 在暂停时有待处理的变化，Updated 列为 False，Updating 为 False。当 Updated 为 True 且 Updating 为 False 时，代表没有待处理的更改。
  重要
  如果有尚未进行的更改（ Updated 和 Updating 字段都是 False）,建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程，以应用上一次重启后排队的更改。
取消暂停自动引导过程：
1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。
2. 点 Compute 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 报告 Paused 列为 False。
  如果 MCP 正在应用任何待处理的更改，Updated 列为 False，Updating 列为 True。当 Updated 为 True 且 Updating 为 False 时，不会再进行任何更改。

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

为了避免对 Machine Config Operator（MCO）所做的更改造成不必要的中断，您可以使用 OpenShift CLI（oc）来修改机器配置池（MCP），以防止 MCO 在那个池中对节点进行任何更改。这会防止任何通常属于 MCO 更新过程一部分的重启。

注意

请参阅第二个有关禁用 Machine Config Operator 自动重新引导的备注。

先决条件

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

流程

要暂停或取消暂停自动 MCO 更新重新引导：

暂停自动引导过程：
1. 更新 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
```
2. 验证 MCP 是否已暂停：
  Control plane（master）节点
```
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
```
  Worker 节点
```
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
```
  输出示例
```
true
```
  spec.paused 字段为 true，MCP 暂停。
3. 确定 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 节点没有任何待处理的更改。
  重要
  如果有尚未进行的更改（ Updated 和 Updating 字段都是 False）,建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程，以应用上一次重启后排队的更改。
取消暂停自动引导过程：
1. 更新 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）。
2. 验证 MCP 是否已取消暂停：
  Control plane（master）节点
```
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
```
  Worker 节点
```
$ 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 正在应用任何待处理的更改，UPDATED 列为 False，UPDATING 列为 True。当 UPDATED 为 True 且 UPDATING 为 False 时，没有进一步的更改。在上例中，MCO 正在更新 worker 节点。

4.13.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>

4.13.8. 卸载失败后重新安装 Operator

在尝试重新安装同一 Operator 前，您必须已成功并完全卸载了 Operator。无法正确卸载 Operator 可以正确地保留资源，如项目或命名空间，处于"Terminating"状态，并导致"错误解析资源"信息。例如：

Project 资源描述示例

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

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

警告

强制删除命名空间可能无法解决 "Terminating" 状态问题，并可能导致不稳定或无法预计的集群行为，因此最好尝试查找可能会阻止命名空间被删除的相关资源。如需更多信息，请参阅红帽知识库解决方案 #4165791，请专注于注意和警告部分。

以下流程演示了如何在无法重新安装 Operator 时进行故障排除，因为之前安装 Operator 中的自定义资源定义 (CRD) 会阻止相关的命名空间成功删除。

流程

检查是否有与 Operator 相关的命名空间是否处于"Terminating"状态：
```
$ oc get namespaces
```
输出示例
```
operator-ns-1                                       Terminating
```
检查卸载失败后是否存在与 Operator 相关的 CRD：
```
$ oc get crds
```
注意
CRD 是全局集群定义；与 CRD 相关的实际自定义资源 (CR) 实例可能位于其他命名空间中，也可以是全局集群实例。
如果有任何 CRD 由 Operator 提供或管理，并在卸载后删除 CRD：
```
$ oc delete crd <crd_name>
```
检查卸载后是否仍然存在与 Operator 相关的剩余 CR 实例，如果存在，请删除 CR：
1. 要搜索的 CR 类型可能很难确定卸载后，需要了解 Operator 管理哪些 CRD。例如，如果您要对提供 EtcdCluster CRD 的 etcd Operator 卸载进行故障排除，您可以在命名空间中搜索剩余的 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 资源仍然没有完全卸载，请联系红帽支持。
在 Web 控制台中使用 OperatorHub 重新安装 Operator。

验证

检查是否已成功重新安装 Operator:

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

其他资源

4.13. Troubleshooting Operator 的问题

4.13.1. operator 订阅状况类型

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

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

4.13.4. 查询 Operator pod 状态

4.13.5. 收集 Operator 日志

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

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

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

4.13.7. 刷新失败的订阅

4.13.8. 卸载失败后重新安装 Operator

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links