検索

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

download PDF

Operator は、OpenShift Container Platform アプリケーションをパッケージ化し、デプロイし、管理する方法です。Operator はソフトウェアベンダーのエンジニアリングチームの拡張機能のように動作し、OpenShift Container Platform 環境を監視し、その最新状態に基づいてリアルタイムの意思決定を行います。Operator はアップグレードをシームレスに実行し、障害に自動的に対応するように設計されており、時間の節約のためにソフトウェアのバックアッププロセスを省略するなどのショートカットを実行することはありません。

OpenShift Container Platform 4.12 には、クラスターの正常な機能に必要なデフォルトの Operator セットが含まれます。これらのデフォルト Operator は Cluster Version Operator (CVO) によって管理されます。

クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI を使用して OperatorHub からアプリケーション Operator をインストールできます。その後、Operator を 1 つまたは複数の namespace にサブスクライブし、クラスター上で開発者が使用できるようにできます。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理されます。

Operator に問題が発生した場合には、Operator Subscription のステータスを確認します。クラスター全体で Operator Pod の正常性を確認し、診断用に Operator ログを収集します。

7.6.1. Operator サブスクリプションの状態のタイプ

サブスクリプションは状態についての以下のタイプを報告します。

表7.2 サブスクリプションの状態のタイプ
状態説明

CatalogSourcesUnhealthy

解決に使用される一部のまたはすべてのカタログソースは正常ではありません。

InstallPlanMissing

サブスクリプションのインストール計画がありません。

InstallPlanPending

サブスクリプションのインストール計画はインストールの保留中です。

InstallPlanFailed

サブスクリプションのインストール計画が失敗しました。

ResolutionFailed

サブスクリプションの依存関係の解決に失敗しました。

注記

デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription オブジェクトがあります。

7.6.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. コマンド出力で、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
    # ...

注記

デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription オブジェクトがあります。

7.6.3. CLI を使用した Operator カタログソースのステータス表示

Operator カタログソースのステータスは、CLI を使用して確認できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ 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

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

7.6.4. Operator Pod ステータスのクエリー

クラスター内の Operator Pod およびそれらのステータスをリスト表示できます。詳細な Operator Pod の要約を収集することもできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • API サービスが機能している。
  • OpenShift CLI (oc) がインストールされている。

手順

  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.12 クラスターノードは変更できず、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. デバッグシェルを終了します。

7.6.5. Operator ログの収集

Operator の問題が発生した場合、Operator Pod ログから詳細な診断情報を収集できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • API サービスが機能している。
  • OpenShift CLI (oc) がインストールされている。
  • コントロールプレーンまたはコントロールプレーンマシンの完全修飾ドメイン名がある。

手順

  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.12 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。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 namespace でのグローバルプルシークレットまたはプルシークレットへの変更
    • Kubernetes API Server Operator による /etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーション。
  • MCO は、ImageContentSourcePolicy (ICSP) オブジェクトの追加または編集など、/etc/containers/registries.conf ファイルへの変更を検出すると、対応するノードをドレインし、変更を適用し、ノードを解放します。ノードのドレインは、次の変更では発生しません。

    • pull-from-mirror = "digest-only" パラメーターがミラーごとに設定されたレジストリーの追加。
    • 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 証明書の有効期限が切れたときに MCP が一時停止され、MCO が証明書を自動的に更新しようとすると、MCO は新しくローテーションされた証明書をそれらのノードにプッシュできません。これにより、クラスターが劣化し、oc debugoc logsoc execoc attach などの複数の oc コマンドで障害が発生します。証明書がローテーションされたときに MCP が一時停止された場合、OpenShift Container Platform コンソールのアラート UI でアラートを受け取ります。

MCP の一時停止は、kube-apiserver-to-kubelet-signer CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。

新しい CA 証明書は、インストール日から 292 日後に生成され、その日から 365 日で削除されます。次回の CA 証明書の自動ローテーションを決定するには、Understand CA cert auto renewal in Red Hat OpenShift 4 を参照してください。

7.6.6.1. コンソールの使用による Machine Config Operator の自動再起動の無効化

Machine Config Operator (MCO) の変更から不要な中断を防ぐには、OpenShift Container Platform Web コンソールを使用してマシン設定プール (MCP) を変更し、MCO がそのプール内のノードに変更を加えられないようにすることができます。これにより、通常 MCO 更新プロセスの一部として実行される再起動ができなくなります。

注記

Machine Config Operator の自動再起動の無効化 の 2 つ目の NOTE を参照してください。

前提条件

  • 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 ページの Paused 列では、変更した MCP に対して True が報告されます。

      MCP が一時停止中に保留中の変更がある場合は、Updated 列は False であり、UpdatingFalse になります。UpdatedTrue であり、UpdatingFalse の場合、保留中の変更はありません。

      重要

      保留中の変更がある場合 (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 ページの Paused 列では、変更した MCP に対して False が報告されます。

      MCP が保留中の変更を適用する場合、Updated 列は False になり、Updating 列は True になります。UpdatedTrue であり、UpdatingFalse の場合、追加の変更は加えられません。

7.6.6.2. CLI の使用による Machine Config Operator の自動再起動の無効化

Machine Config Operator (MCO) によって加えられる変更から生じる不要な中断を防ぐには、OpenShift CLI (oc) を使用してマシン設定プール (MCP) を変更し、MCO がそのプール内のノードに変更を加えられないようにすることができます。これにより、通常 MCO 更新プロセスの一部として実行される再起動ができなくなります。

注記

Machine Config Operator の自動再起動の無効化 の 2 つ目の NOTE を参照してください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

自動 MCO 更新の再起動の一時停止または一時停止を解除するには、以下を実行します。

  • 自動再起動プロセスを一時停止します。

    1. MachineConfigPool カスタムリソースを、spec.paused フィールドを true に設定するように更新します。

      コントロールプレーン (マスター) ノード

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

      ワーカーノード

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

    2. MCP が一時停止されていることを確認します。

      コントロールプレーン (マスター) ノード

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

      ワーカーノード

      $ 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 であり、UPDATINGFalse の場合は、保留中の変更があります。UPDATEDTrue であり、UPDATINGFalse の場合、保留中の変更はありません。この例では、ワーカーノードに保留中の変更があります。コントロールプレーンノードには保留中の変更がありません。

      重要

      保留中の変更がある場合 (Updated および Updating 列の両方が False の場合)、できるだけ早期に再起動のメンテナンス期間をスケジュールすることが推奨されます。自動再起動プロセスの一時停止を解除して、最後に再起動してからキューに追加された変更を適用するには、以下の手順に従います。

  • 自動再起動プロセスの一時停止を解除するには、以下を実行します。

    1. MachineConfigPool カスタムリソースを、spec.paused フィールドを false に設定するように更新します。

      コントロールプレーン (マスター) ノード

      $ 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 の一時停止が解除されていることを確認します。

      コントロールプレーン (マスター) ノード

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

      ワーカーノード

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

      出力例

      false

      spec.paused フィールドは false であり、マシン設定プールの一時停止は解除されます。

    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 になります。UPDATEDTrue であり、UPDATINGFalse の場合、追加の変更は加えられません。直前の例では、MCO はワーカーノードを更新しています。

7.6.7. 障害のあるサブスクリプションの更新

Operator Lifecycle Manager (OLM) で、ネットワークでアクセスできないイメージを参照する Operator をサブスクライブする場合、以下のエラーを出して失敗した openshift-marketplace namespace でジョブを見つけることができます。

出力例

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 がインストールされている 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 の失敗したジョブおよび関連する設定マップの名前を取得します。

    $ 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>

7.6.8. アンインストール失敗後の Operator の再インストール

同じ Operator の再インストールを試行する前に、Operator を正常かつ完全にアンインストールする必要があります。Operator を適切かつ完全にアンインストールできていない場合、プロジェクトや namespace などのリソースが "Terminating" ステータスでスタックし、"error resolving resource" メッセージが表示されます。以下に例を示します。

Project リソースの説明例

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

これらのタイプの問題は、Operator の正常な再インストールを妨げる可能性があります。

警告

namespace を強制的に削除しても、"Terminating" 状態の問題が解決される可能性は低く、クラスターの動作が不安定または予測不能になる可能性があるため、namespace の削除を妨げている可能性のある関連リソースの特定に注力することが推奨されます。詳細は、Red Hat Knowledgebase Solution #4165791 を参照し、特に注意と警告に注目してください。

次の手順では、以前インストールされた Operator からの既存カスタムリソース定義 (CRD) が原因で関連する namespace が正常に削除されないために 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 の再インストール

検証

  • Operator が正常に再インストールされていることを確認します。

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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.