7.6. Operator 関連の問題のトラブルシューティング

手順

1. Operator サブスクリプションをリスト表示します。

   $ oc get subs -n <operator_namespace>

2. oc describe コマンドを使用して、Subscription リソースを検査します。

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

3. コマンド出力で、Conditions セクションで Operator サブスクリプションの状態タイプのステータスを確認します。以下の例では、利用可能なすべてのカタログソースが正常であるため、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
   # ...

手順

1. namespace のカタログソースをリスト表示します。たとえば、クラスター全体のカタログソースに使用されている openshift-marketplace namespace を確認することができます。

   $ 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

2. カタログソースの詳細やステータスを確認するには、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 となっています。この状態は、カタログソースの接続確立に問題があることを示しています。

3. カタログソースが作成された namespace の 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

   namespace にカタログソースを作成すると、その namespace にカタログソース用の Pod が作成されます。前述の出力例では、example-catalog-bwt8z Pod のステータスが ImagePullBackOff になっています。このステータスは、カタログソースのインデックスイメージのプルに問題があることを示しています。

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

   前述の出力例では、エラーメッセージは、カタログソースのインデックスイメージが承認問題のために正常にプルできないことを示しています。例えば、インデックスイメージがログイン認証情報を必要とするレジストリーに保存されている場合があります。

手順

1. クラスターで実行されている Operator をリスト表示します。出力には、Operator バージョン、可用性、およびアップタイムの情報が含まれます。

   $ oc get clusteroperators

2. Operator の namespace で実行されている 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. ノードのデバッグ Pod を起動します。

      $ oc debug node/my-node

   2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

      # chroot /host

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.14 クラスターノードは変更できず、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. デバッグシェルを終了します。

手順

1. Operator の namespace で実行されている 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 を使用して各コントロールプレーンノードで Operator Pod およびコンテナーログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

   1. 各コントロールプレーンノードの Pod をリスト表示します。

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

   2. Operator Pod で Ready ステータスが表示されない場合は、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.14 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

手順

1. Operator がインストールされている namespace から 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

2. サブスクリプションを削除します。

   $ oc delete subscription <subscription_name> -n <namespace>

3. クラスターサービスバージョンを削除します。

   $ oc delete csv <csv_name> -n <namespace>

4. openshift-marketplace namespace の失敗したジョブおよび関連する config map の名前を取得します。

   $ 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 の再インストール

手順

1. "Terminating" 状態のままになっている Operator に関連する namespace があるかどうかを確認します。

   $ oc get namespaces

   出力例

   operator-ns-1                                       Terminating

2. アンインストールの失敗後も Operator に関連する CRD があるか確認します。

   $ oc get crds

   注記

   CRD はグローバルクラスター定義です。CRD に関連する実際のカスタムリソース (CR) インスタンスは、他の namespace にあるか、グローバルクラスターインスタンスである可能性があります。

3. Operator によって提供または管理されている CRD があり、その CRD をアンインストール後に削除する必要がある場合は、CRD を削除します。

   $ oc delete crd <crd_name>

4. アンインストールした後も Operator に関連する CR インスタンスが残っているか確認し、残っている場合は CR を削除します。

   1. アンインストール後は、検索する CR のタイプの判断が困難になり、Operator が管理する CRD を把握している必要がある場合もあります。たとえば、EtcdCluster CRD を提供する etcd Operator のアンインストールをトラブルシューティングする場合、namespace で残りの EtcdCluster CR を検索できます。

      $ oc get EtcdCluster -n <namespace_name>

      もしくは、すべての namespace で検索できます。

      $ oc get EtcdCluster --all-namespaces

   2. 削除する必要のある CR が残っている場合は、インスタンスを削除します。

      $ oc delete <cr_name> <cr_instance_name> -n <namespace_name>

5. namespace の削除が正常に解決されたことを確認します。

   $ oc get namespace <namespace_name>

   重要

   namespace やその他の Operator リソースが正常にアンインストールされていない場合は、Red Hat サポートにお問い合わせください。

6. Web コンソールの OperatorHub を使用した Operator の再インストール