5.5. Troubleshooting Operator 的问题

Operator 是一种打包、部署和管理 OpenShift Container Platform 应用程序的方法。它可以被看作是软件厂商的工程团队的扩展,可以在 OpenShift Container Platform 监控软件的运行情况,并根据软件的当前状态实时做出决策。Operator 被设计为用来无缝地处理升级过程,并对出现的错误自动进行响应,而且不会采取“捷径”(如跳过软件备份过程来节省时间)。

OpenShift Container Platform 4.7 包括了一组默认的 Operator,它们是集群正常工作所需的。这些默认 Operator 由 Cluster Version Operator(CVO)管理。

作为集群管理员,您可使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的应用程序 Operator。然后,您可将 Operator 订阅至一个或多个命名空间,供集群上的开发人员使用。应用程序 Operator 由 Operator Lifecycle Manager(OLM)进行管理。

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

5.5.1. operator 订阅状况类型

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

表 5.1. 订阅状况类型

状况描述

CatalogSourcesUnhealthy

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

InstallPlanMissing

缺少订阅的安装计划。

InstallPlanPending

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

InstallPlanFailed

订阅的安装计划失败。

注意

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

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

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

先决条件

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

流程

  1. 列出 Operator 订阅:

    $ oc get subs -n <operator_namespace>
  2. 使用 oc describe 命令检查 Subscription 资源:

    $ oc describe sub <subscription_name> -n <operator_namespace>
  3. 在命令输出中,找到 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 对象。

5.5.3. 查询 Operator pod 状态

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

先决条件

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

流程

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

    $ oc get clusteroperators
  2. 列出在 Operator 命名空间中运行的 Operator pod,以及 pod 状态、重启和年龄:

    $ oc get pod -n <operator_namespace>
  3. 输出详细的 Operator pod 概述:

    $ oc describe pod <operator_pod_name> -n <operator_namespace>
  4. 如果 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.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。但是,如果 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。

5.5.4. 收集 Operator 日志

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

先决条件

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

流程

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

    $ oc get pods -n <operator_namespace>
  2. 检查 Operator pod 的日志:

    $ oc logs pod/<pod_name> -n <operator_namespace>

    如果 Operator pod 具有多个容器,则上述命令将会产生一个错误,其中包含每个容器的名称。从独立容器查询日志:

    $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
  3. 如果 API 无法正常工作,请使用 SSH 来检查各个 master 节点上的 Operator pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。

    1. 列出每个 master 节点上的 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.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

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

当 Machine Config Operator(MCO)进行配置更改时,Red Hat Enterprise Linux CoreOS(RHCOS)必须重启才能使更改生效。无论配置更改是自动的(如 kube-apiserver-to-kubelet-signer 证书颁发机构(CA)被轮转时),还是手动的,RHCOS 节点都会自动重启,除非它被暂停。

注意

以下修改不会触发节点重新引导:

  • 在机器配置的 spec.config.ignition.passwd.users.sshAuthorizedKeys 参数中更改 SSH 密钥
  • openshift-config 命名空间中更改全局 pull secret 或 pull secret
  • /etc/containers/registries.conf 文件的更改,如添加或编辑一个 ImageContentSourcePolicy 对象

当 MCO 检测到任何这些更改时,它会排空相应的节点,应用更改并对节点进行 uncordon。

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

注意

暂停机器配置池会停止所有系统重启过程以及所有配置更改。

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

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

注意

暂停 MCP 会停止 RHCOS 节点的所有更新,包括操作系统更新、安全、证书和与机器配置相关的任何其他更新。暂停应只在短时间内进行。

先决条件

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

流程

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

  • 暂停自动引导过程:

    1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。
    2. ComputeMachine Config Pools
    3. Machine Config Pools 页面中,根据您要暂停重新引导的节点,点 masterworker
    4. masterworker 页面中,点 YAML
    5. 在 YAML 中,将 spec.paused 字段更新为 true

      MachineConfigPool 对象示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
       ...
      spec:
       ...
        paused: true 1

      1
      spec.paused 字段更新为 true 以暂停重新引导。
    6. 要验证 MCP 是否已暂停,请返回到 Machine Config Pools 页面。

      Machine Config Pools 页面中,您修改的 MCP 报告在 Paused 列中为 True

      如果 MCP 在暂停时有待处理的变化,Updated 列为 FalseUpdatingFalse。当 UpdatedTrueUpdatingFalse 时,代表没有待处理的更改。

      重要

      如果有尚未进行的更改( UpdatedUpdating 字段都是 False),建议您尽快调度一个维护窗口用于重启。使用以下步骤取消暂停自动引导过程,以应用上一次重启后排队的更改。

  • 取消暂停自动引导过程:

    1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。
    2. ComputeMachine Config Pools
    3. Machine Config Pools 页面中,根据您要暂停重新引导的节点,点 masterworker
    4. masterworker 页面中,点 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 是否已暂停,请返回到 Machine Config Pools 页面。

      Machine Config Pools 页面中,您修改的 MCP 报告在 Paused 列中为 False

      如果 MCP 正在应用任何待处理的更改,Updated 列为 FalseUpdating 列为 True。当 UpdatedTrueUpdatingFalse 时,不会再进行任何更改。

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

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

注意

暂停 MCP 会停止 RHCOS 节点的所有更新,包括操作系统更新、安全、证书和与机器配置相关的任何其他更新。暂停应只在短时间内进行。

先决条件

  • 您可以使用具有 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 列是 FalseUPDATINGFalse,则有待处理的更改。当 UPDATEDTrueUPDATINGFalse 时,没有待处理的更改。在上例中,worker 节点有待处理的变化。Master 节点没有任何待处理的更改。

      重要

      如果有尚未进行的更改( UpdatedUpdating 字段都是 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 列为 FalseUPDATING 列为 True。当 UPDATEDTrueUPDATINGFalse 时,没有进一步的更改。在上例中,MCO 正在更新 worker 节点。

5.5.6. 刷新失败的订阅

在 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 的正确版本。

先决条件

  • 您有一个失败的订阅,无法拉取不能访问的捆绑包镜像。
  • 已确认可以访问正确的捆绑包镜像。

流程

  1. 从安装 Operator 的命名空间中获取 SubscriptionClusterServiceVersion 对象的名称:

    $ 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

  2. 删除订阅:

    $ oc delete subscription <subscription_name> -n <namespace>
  3. 删除集群服务版本:

    $ oc delete csv <csv_name> -n <namespace>
  4. 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

  5. 删除作业:

    $ oc delete job <job_name> -n openshift-marketplace

    这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。

  6. 删除配置映射:

    $ oc delete configmap <configmap_name> -n openshift-marketplace
  7. 在 Web 控制台中使用 OperatorHub 重新安装 Operator。

验证

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

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