7.6. Operator 関連の問題のトラブルシューティング
Operator は、OpenShift Container Platform アプリケーションをパッケージ化し、デプロイし、管理する方法です。Operator はソフトウェアベンダーのエンジニアリングチームの拡張機能のように動作し、OpenShift Container Platform 環境を監視し、その最新状態に基づいてリアルタイムの意思決定を行います。Operator はアップグレードをシームレスに実行し、障害に自動的に対応するように設計されており、時間の節約のためにソフトウェアのバックアッププロセスを省略するなどのショートカットを実行することはありません。
OpenShift Container Platform 4.7 には、クラスターの正常な機能に必要なデフォルトの 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 サブスクリプションの状態のタイプ
サブスクリプションは状態についての以下のタイプを報告します。
状態 | 説明 |
---|---|
| 解決に使用される一部のまたはすべてのカタログソースは正常ではありません。 |
| サブスクリプションのインストール計画がありません。 |
| サブスクリプションのインストール計画はインストールの保留中です。 |
| サブスクリプションのインストール計画が失敗しました。 |
デフォルトの OpenShift Container Platform クラスター 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
) がインストールされている。
手順
Operator サブスクリプションを一覧表示します。
$ oc get subs -n <operator_namespace>
oc describe
コマンドを使用して、Subscription
リソースを検査します。$ oc describe sub <subscription_name> -n <operator_namespace>
コマンド出力で、
Conditions
セクションで Operator サブスクリプションの状態タイプのステータスを確認します。以下の例では、利用可能なすべてのカタログソースが正常であるため、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) によって管理され、これらの Operator には Subscription
オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription
オブジェクトがあります。
7.6.3. CLI を使った Operator カタログソースのステータス表示
Operator カタログソースのステータスは、CLI を使って確認できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
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
カタログソースの詳細やステータスを確認するには、
oc describe
コマンドを使用します。$ oc describe catalogsource example-catalog -n openshift-marketplace
出力例
Name: example-catalog Namespace: openshift-marketplace ... 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
となっています。この状態は、カタログソースの接続確立に問題があることを示しています。カタログソースが作成された 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
になっています。このステータスは、カタログソースのインデックスイメージのプルに問題があることを示しています。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
) がインストールされている。
手順
クラスターで実行されている Operator を一覧表示します。出力には、Operator バージョン、可用性、およびアップタイムの情報が含まれます。
$ oc get clusteroperators
Operator の namespace で実行されている Operator Pod を一覧表示し、Pod のステータス、再起動、および経過時間を一覧表示します。
$ oc get pod -n <operator_namespace>
詳細な Operator Pod の要約を出力します。
$ oc describe pod <operator_pod_name> -n <operator_namespace>
Operator の問題がノード固有の問題である場合、そのノードで Operator コンテナーのステータスをクエリーします。
ノードのデバッグ Pod を起動します。
$ oc debug node/my-node
/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。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>
を使用してノードにアクセスできます。状態および関連付けられた Pod ID を含む、ノードのコンテナーについての詳細を一覧表示します。
# crictl ps
ノード上の特定の Operator コンテナーについての情報を一覧表示します。以下の例では、
network-operator
コンテナーに関する情報を一覧表示します。# crictl ps --name network-operator
- デバッグシェルを終了します。
7.6.5. Operator ログの収集
Operator の問題が発生した場合、Operator Pod ログから詳細な診断情報を収集できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc
) がインストールされている。 - コントロールプレーンまたはコントロールプレーンマシン (別名マスターマシン) の完全修飾ドメイン名がある。
手順
Operator の namespace で実行されている 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 を使用して各コントロールプレーンノードで Operator Pod およびコンテナーログを確認します。
<master-node>.<cluster_name>.<base_domain>
を適切な値に置き換えます。各コントロールプレーンノードの Pod を一覧表示します。
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
Operator Pod で
Ready
ステータスが表示されない場合は、Pod のステータスを詳細に検査します。<operator_pod_id>
を直前のコマンドの出力に一覧表示されている Operator Pod の ID に置き換えます。$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
Operator Pod に関連するコンテナーを一覧表示します。
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
Ready
ステータスが Operator コンテナーに表示されない場合は、コンテナーのステータスを詳細に検査します。<container_id>
を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
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>
を使用してノードにアクセスできます。
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
オブジェクトの追加または編集などの/etc/containers/registries.conf
ファイルへの変更を検出すると、対応するノードをドレイン (解放) し、ノードの分離を解除します。
不要な中断を防ぐために、マシン設定プール (MCP) を変更して、Operator がマシン設定を変更した後に自動再起動を防ぐことができます。
MCP を一時停止にすると、MCO が関連付けられたノードに設定変更を適用できなくなります。MCP を一時停止することにより、kube-apiserver-to-kubelet-signer
CA 証明書の自動ローテーションを含め、自動的にローテーションされる証明書が関連付けられたノードにプッシュされないようにします。MCP が kube-apiserver-to-kubelet-signer
CA 証明書の期限が切れ、MCO が証明書を自動的に更新しようとすると、新規証明書が作成されますが、一時停止された MCP のノード全体では適用されません。これにより、oc debug
、oc logs
、oc exec
、oc attach
など、複数の oc
コマンドで問題が発生します。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 更新プロセスの一部として実行される再起動ができなくなります。
MCP を一時停止にすると、MCO が関連付けられたノードに設定変更を適用できなくなります。MCP を一時停止することにより、kube-apiserver-to-kubelet-signer
CA 証明書の自動ローテーションを含め、自動的にローテーションされる証明書が関連付けられたノードにプッシュされないようにします。MCP が kube-apiserver-to-kubelet-signer
CA 証明書の期限が切れ、MCO が証明書を自動的に更新しようとすると、新規証明書が作成されますが、一時停止された MCP のノード全体では適用されません。これにより、oc debug
、oc logs
、oc exec
、oc attach
など、複数の oc
コマンドで問題が発生します。MCP の一時停止は、kube-apiserver-to-kubelet-signer
CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。
新しい CA 証明書は、インストール日から 292 日後に生成され、その日から 365 日で削除されます。次回の CA 証明書の自動ローテーションを決定するには、Understand CA cert auto renewal in Red Hat OpenShift 4 を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
自動 MCO 更新の再起動の一時停止または一時停止を解除するには、以下を実行します。
自動再起動プロセスを一時停止します。
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 -
Compute
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 ページの Paused 列では、変更した MCP に対して True が報告されます。
MCP が一時停止中に保留中の変更がある場合は、Updated 列は False であり、Updating は False になります。Updated が True であり、Updating が False の場合、保留中の変更はありません。
重要保留中の変更がある場合 (Updated および Updating 列の両方が False の場合)、できるだけ早期に再起動のメンテナンス期間をスケジュールすることが推奨されます。自動再起動プロセスの一時停止を解除して、最後に再起動してからキューに追加された変更を適用するには、以下の手順に従います。
-
自動再起動プロセスの一時停止を解除するには、以下を実行します。
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 -
Compute
MachineConfigPools をクリックします。 - MachineConfigPools ページで、再起動を一時停止するノードに合わせて master または worker のいずれかをクリックします。
- master または worker ページで、YAML をクリックします。
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) を再起動します。
MCP が一時停止されていることを確認するには、MachineConfigPools ページに戻ります。
MachineConfigPools ページの Paused 列では、変更した MCP に対して False が報告されます。
MCP が保留中の変更を適用する場合、 Updated 列は False になり、Updating 列は True になります。Updated が True であり、Updating が False の場合、追加の変更は加えられません。
-
7.6.6.2. CLI の使用による Machine Config Operator の自動再起動の無効化
Machine Config Operator (MCO) によって加えられる変更から生じる不要な中断を防ぐには、OpenShift CLI (oc) を使用してマシン設定プール (MCP) を変更し、MCO がそのプール内のノードに変更を加えられないようにすることができます。これにより、通常 MCO 更新プロセスの一部として実行される再起動ができなくなります。
MCP を一時停止にすると、MCO が関連付けられたノードに設定変更を適用できなくなります。MCP を一時停止することにより、kube-apiserver-to-kubelet-signer
CA 証明書の自動ローテーションを含め、自動的にローテーションされる証明書が関連付けられたノードにプッシュされないようにします。MCP が kube-apiserver-to-kubelet-signer
CA 証明書の期限が切れ、MCO が証明書を自動的に更新しようとすると、新規証明書が作成されますが、一時停止された MCP のノード全体では適用されません。これにより、oc debug
、oc logs
、oc exec
、oc attach
など、複数の oc
コマンドで問題が発生します。MCP の一時停止は、kube-apiserver-to-kubelet-signer
CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。
新しい CA 証明書は、インストール日から 292 日後に生成され、その日から 365 日で削除されます。次回の CA 証明書の自動ローテーションを決定するには、Understand CA cert auto renewal in Red Hat OpenShift 4 を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
自動 MCO 更新の再起動の一時停止または一時停止を解除するには、以下を実行します。
自動再起動プロセスを一時停止します。
MachineConfigPool
カスタムリソースを、spec.paused
フィールドをtrue
に設定するように更新します。コントロールプレーン (マスター) ノード
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
ワーカーノード
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
MCP が一時停止されていることを確認します。
コントロールプレーン (マスター) ノード
$ 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
UPDATED 列が False であり、UPDATING が False の場合は、保留中の変更があります。UPDATED が True であり、UPDATING が False の場合、保留中の変更はありません。この例では、ワーカーノードに保留中の変更があります。コントロールプレーンノード (別名マスターノード) には、保留中の変更はありません。
重要保留中の変更がある場合 (Updated および Updating 列の両方が False の場合)、できるだけ早期に再起動のメンテナンス期間をスケジュールすることが推奨されます。自動再起動プロセスの一時停止を解除して、最後に再起動してからキューに追加された変更を適用するには、以下の手順に従います。
自動再起動プロセスの一時停止を解除するには、以下を実行します。
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) を再起動します。
MCP の一時停止が解除されていることを確認します。
コントロールプレーン (マスター) ノード
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
ワーカーノード
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
出力例
false
spec.paused
フィールドはfalse
であり、マシン設定プールの一時停止は解除されます。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 はワーカーノードを更新しています。
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 の正しいバージョンを再インストールします。
前提条件
- アクセス不可能なバンドルイメージをプルできない障害のあるサブスクリプションがある。
- 正しいバンドルイメージにアクセスできることを確認している。
手順
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
サブスクリプションを削除します。
$ oc delete subscription <subscription_name> -n <namespace>
クラスターサービスバージョンを削除します。
$ oc delete csv <csv_name> -n <namespace>
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
ジョブを削除します。
$ 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>