Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

トラブルシューティング

Red Hat Advanced Cluster Management for Kubernetes 2.1

トラブルシューティング

概要

Red Hat Advanced Cluster Management for Kubernetes でのトラブルシューティング

第1章 トラブルシューティング
リンクのコピー

トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細、ログを収集し、問題のデバッグ手順を行います。

また、ロールベースのアクセス権限を確認してください。詳細は、「ロールベースアクセス制御機能」を参照してください。

1.1. Must-gather
リンクのコピー

はじめに、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオについて説明します。

  • シナリオ 1: ドキュメント 化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。本ガイドは、製品の主な機能別に構成されています。

    このシナリオでは、解決策が本書にまとめられているかどうかを、本ガイドで確認します。たとえば、クラスターの作成に関するトラブルシューティングの場合には、「クラスターの管理」セクションの解決策を探します。

  • シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合には、must-gather コマンドを実行し、その出力を使用して問題をデバッグします。
  • シナリオ 3: must-gather コマンドの出力を使用して問題をデバッグできない場合は、Red Hat サポートに、出力を共有します。

must-gather コマンドの使用を開始するには、以下の手順を参照してください。

トラブルシューティングを開始するには、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオについて確認し、このコマンドの使用を開始する手順を参照してください。

必要なアクセス権限: クラスターの管理者

  1. must-gather コマンドについて確認し、「Red Hat サポート用のクラスターについてのデータの収集」に必要な前提条件をインストールします。

  2. クラスターにログインします。通常のユースケースでは、ハブ クラスターにログインして、must-gather を実行する必要があります。

    注記: マネージドクラスターを確認する場合には、cluster-scoped-resources ディレクトリーにある gather-managed.log ファイルを検索します。 

    <your-directory>/cluster-scoped-resources/gather-managed.log>
    Copy to Clipboard Toggle word wrap

    JOINED および AVAILABLE 列に True が設定されていないマネージドクラスターがないかを確認します。must-gather コマンドは、ステータスが True として関連付けられていないクラスター上で、実行できます。

  3. データおよびディレクトリーの収集に使用する Red Hat Advanced Cluster Management for Kubernetes イメージを追加します。以下のコマンドを実行して、出力用にイメージとディレクトリーを挿入します。 

    oc adm must-gather --image=registry.redhat.io/rhacm2/acm-must-gather-rhel8:v2.1.0 --dest-dir=<directory>
    Copy to Clipboard Toggle word wrap

  4. 指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。

    • ピアレベル 2 つ: cluster-scoped-resources と namespace のリソース
    • それぞれのサブレベル: クラスタースコープおよび namespace スコープ両方のリソースに対するカスタムリソース定義の API グループ。
    • それぞれの次のレベル: kind でソートされた YAML ファイル

1.2. 非接続環境での must-gather の実行
リンクのコピー

非接続環境で must-gather コマンドを実行するには、次の手順を実行します。

  1. 非接続環境では、Red Hat オペレーターのカタログイメージをミラーレジストリーにミラーリングします。詳細は、「ネットワーク切断状態でのインストール」を参照してください。
  2. 次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。 
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/rhacm2/acm-must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8
oc adm must-gather --image=$IMAGE --dest-dir=./data
Copy to Clipboard Toggle word wrap

1.3. 文書化されたトラブルシューティング
リンクのコピー

以下に、Red Hat Advanced Cluster Management for Kubernetes のトラブルシューティングのトピックリストを表示します。

インストール

元のインストールタスクに戻るには、『インストール』を参照してください。

クラスター管理

元のクラスター管理タスクを表示するには、『クラスターの管理』を参照してください。

アプリケーション管理

元のアプリケーション管理タスクを表示するには、『アプリケーションの管理』を参照してください。

ガバナンスおよびリスク

元のセキュリティーガイドを表示するには、「セキュリティー」を参照してください。

コンソールの可観測性

コンソールの可観測性には、ヘッダーおよびナビゲーション機能、検索機能および Visual Web ターミナルが含まれます。元の可観測性ガイドを表示するには、「コンソールの可観測性」を参照してください。

1.4. 再インストールに失敗する場合のトラブルシューティング
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes を再インストールすると Pod が起動しません。

1.4.1. 現象: 再インストールの失敗
リンクのコピー

Red Hat Advanced Cluster Management のインストール後に Pod が起動しない場合には、Red Hat Advanced Cluster Management 以前にインストールされており、今回のインストールを試行する前にすべてのパーツが削除されていない可能性があります。

Pod はこのような場合に、インストールプロセスの完了後に起動しません。

1.4.2. 問題の解決: 再インストールの失敗
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. 「アンインストール」の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
  2. 「Helm のインストール」の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
  3. oc コマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法に関する詳細は、Red Hat OpenShift Container Platform ドキュメントの「CLI の使用方法」を参照してください。

  4. 以下のスクリプトをファイルにコピーします。 

    #!/bin/bash
ACM_NAMESPACE=<namespace>
oc delete mch --all -n $ACM_NAMESPACE
helm ls --namespace $ACM_NAMESPACE | cut -f 1 | tail -n +2 | xargs -n 1 helm delete --namespace $ACM_NAMESPACE
oc delete apiservice v1beta1.webhook.certmanager.k8s.io v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
oc delete clusterimageset --all
oc delete configmap -n $ACM_NAMESPACE cert-manager-controller cert-manager-cainjector-leader-election cert-manager-cainjector-leader-election-core
oc delete consolelink acm-console-link
oc delete crd klusterletaddonconfigs.agent.open-cluster-management.io placementbindings.policy.open-cluster-management.io policies.policy.open-cluster-management.io userpreferences.console.open-cluster-management.io searchservices.search.acm.com
oc delete mutatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1
oc delete oauthclient multicloudingress
oc delete rolebinding -n kube-system cert-manager-webhook-webhook-authentication-reader
oc delete scc kui-proxy-scc
oc delete validatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1
    Copy to Clipboard Toggle word wrap

    スクリプトの <namespace> は、Red Hat Advanced Cluster Management がインストールされている namespace 名に置き換えます。namespace が消去され、削除されるので、正しい namespace を指定するようにしてください。

  5. スクリプトを実行して、アーティファクトを以前のインストールから削除します。
  6. インストールを実行します。「ネットワーク接続時のオンラインインストール」を参照してください。

1.5.1. 現象: リソースが存在しないためにアンインストールに失敗する
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes をアンインストールすると、以下のエラーメッセージのいずれかで、インストールに失敗します。 

Cannot delete MultiClusterHub resource because ManagedCluster resource(s) exist
Copy to Clipboard Toggle word wrap 
Cannot delete MultiClusterHub resource because BareMetalAssets resource(s) exist
Copy to Clipboard Toggle word wrap 
Cannot delete MultiClusterHub resource because MultiClusterObservability resource(s) exist
Copy to Clipboard Toggle word wrap

1.5.2. 問題の解決: リソースが存在しないためにアンインストールに失敗する
リンクのコピー

このようなエラーは、クラスターの管理、ベアメタルアセットのホスト、または可観測性データの収集を行っているにもかかわらず、Red Hat Advanced Cluster Management for Kubernetes ハブクラスターのアンインストールを試行すると、発生します。ハブクラスターをアンインストールする前に、このようなリソースすべてを削除する必要があります。

  • ManagedCluster エラーメッセージを解決するには、ハブクラスターが管理しているクラスターをすべてデタッチし、再度アンインストールを試みます。

クラスターのデタッチの詳細は、「クラスターの作成」でお使いのプロバイダーの情報を選択して、「マネージメントからのクラスターの削除」セクションを参照してください。

  • BareMetalAssets リソースのエラーメッセージを解決するには、ハブクラスターからベアメタルアセットをすべて削除し、再度アンインストールを試みます。

ベアメタルアセットの削除に関する詳細は、「ベアメタルアセットの削除」を参照してください。

  • MultiClusterObservability リソースのエラーを解決するには、ハブクラスターからすべての MultiClusterObservability リソースを削除して、再度アンインストールを試みます。

1.6. オフラインクラスターのトラブルシューティング
リンクのコピー

クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。

1.6.1. 現象: クラスターのステータスがオフライン状態である
リンクのコピー

クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。

1.6.2. 問題の解決: クラスターのステータスがオフライン状態である
リンクのコピー

  1. マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。

    利用不可の場合は、マネージドクラスターの再起動を試行します。

  2. マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。

    1. ハブクラスターで oc get managedcluster <cluster_name> -o yaml コマンドを実行します。<cluster_name> は、クラスター名に置き換えます。
    2. status.conditions セクションを見つけます。
    3. type: ManagedClusterConditionAvailable のメッセージを確認して、問題を解決します。

1.7. Pending Import (インポート待ち) のステータスのクラスターのトラブルシューティング
リンクのコピー

クラスターのコンソールで継続的に Pending import と表示される場合には、以下の手順を実行して問題をトラブルシューティングしてください。

1.7.1. 現象: ステータスが Pending Import (インポート待ち) のクラスター
リンクのコピー

Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。

1.7.2. 問題の特定: ステータスが Pending Import (インポート待ち) のクラスター
リンクのコピー

  1. マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。 

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
    Copy to Clipboard Toggle word wrap

  2. マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。 

    kubectl logs <registration_agent_pod>
    Copy to Clipboard Toggle word wrap

    registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。

  3. 返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。(例: no such host)

1.7.3. 問題の解決: ステータスが Pending Import (インポート待ち) のクラスター
リンクのコピー

  1. ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。 

    oc get infrastructure cluster -o yaml | grep apiServerURL
    Copy to Clipboard Toggle word wrap

  2. マネージドクラスターからのホスト名が解決でき、ホストとポートへの送信接続が機能していることを確認します。

    マネージドクラスターで通信が確立できない場合には、クラスターのインポートは完了しません。マネージドクラスターのクラスターステータスは、Pending import になります。

1.8. VMware vSphere でのクラスター作成のトラブルシューティング
リンクのコピー

VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。

1.8.1. 証明書 の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

1.8.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。

1.8.1.2. 問題の特定: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error
Copy to Clipboard Toggle word wrap
1.8.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

プロバイダー接続の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。

1.8.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

1.8.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。

1.8.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
Copy to Clipboard Toggle word wrap
1.8.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

プロバイダー接続の作成時に認証局からの正しい証明書が入力されていることを確認します。

1.8.3. 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

1.8.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、まだ有効化されていないため、クラスターに問題が発生します。

1.8.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

x509: certificate has expired or is not yet valid
Copy to Clipboard Toggle word wrap
1.8.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

ESXi ホストの時間が同期されていることを確認します。

1.8.4. タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する
リンクのコピー

1.8.4.1. 現象: タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないのでクラスターに問題が発生します。

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..."
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden"
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="  on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":"
time="2020-08-07T19:41:58Z" level=error msg="  54: resource \"vsphere_tag_category\" \"category\" {"
Copy to Clipboard Toggle word wrap

VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、「インストール時に削除されたイメージレジストリー」を参照してください。

1.8.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

1.8.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。

1.8.5.2. 問題の特定: 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform リリースイメージを使用しているためです。 

failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
Copy to Clipboard Toggle word wrap
1.8.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。

1.8.6. ネットワークタイプが正しくないのでマネージドクラスターの作成に失敗する
リンクのコピー

1.8.6.1. 現象: ネットワークタイプが正しくないのでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているので、クラスターに問題が発生します。

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform イメージを使用しているためです。 

time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..."
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing"
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
Copy to Clipboard Toggle word wrap

指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。

1.8.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

1.8.7.1. 現象: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。

以下のようなメッセージがログに表示されます。 

ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
Copy to Clipboard Toggle word wrap

VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限 の 全権限 を割り当てます。

1.9.1. 現象: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
リンクのコピー

Red Hat OpenShift Container Platform バージョン 3.11 クラスターのインポートを試行すると、以下の内容のようなログメッセージでインポートに失敗します。 

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...
Copy to Clipboard Toggle word wrap

1.9.2. 問題の特定: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
リンクのコピー

この問題は多くの場合、インストールされている kubectl コマンドラインツールのバージョンが 1.11 以前であるために発生します。以下のコマンドを実行して、実行中の kubectl コマンドラインツールのバージョンを表示します。 

kubectl version
Copy to Clipboard Toggle word wrap

返されたデータがバージョンが 1.11 以前の場合は、「問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する」の修正のいずれかを実行します。

1.9.3. 問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
リンクのコピー

この問題は、以下のいずれかの手順を実行して解決できます。

  • 最新バージョンの kubectl コマンドラインツールをインストールします。

    1. Kubernetes ドキュメントの Install and Set Up kubectl から最新バージョンの kubectl ツールをダウンロードします。
    2. kubectl ツールのアップグレード後にクラスターを再度インポートします。

  • import コマンドが含まれるファイルを実行します。

    1. 「CLI を使用したマネージドクラスターのインポート」の手順を開始します。
    2. クラスターのインポートコマンドを作成する場合には、このインポートコマンドを import.yaml という名前の YAML ファイルにコピーします。

    3. 以下のコマンドを実行して、ファイルからクラスターを再度インポートします。 

      oc apply -f import.yaml
      Copy to Clipboard Toggle word wrap

カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされた クラスターの 1 つまたは複数でステータスが オフライン になる可能性があります。

1.10.1. 現象: 証明書の変更後にクラスターがオフラインになる
リンクのコピー

証明書シークレットの更新手順を完了すると、オンラインになっていたクラスターの 1 つまたは複数が、Red Hat Advanced Cluster Management for Kubernetes コンソールで オフライン ステータスと表示される可能性があります。

1.10.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる
リンクのコピー

カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが オフライン になります。

オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。

work-agent のログ: 

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap

registration-agent のログ: 

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap

1.10.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる
リンクのコピー

証明書情報の更新後にクラスターを手動で復元するには、各マネージドクラスターで以下の手順を実行します。

  1. もう一度、クラスターを手動でインポートします。Red Hat Advanced Cluster Management で作成された Red Hat OpenShift Container Platform クラスターは 2 時間ごとに再同期されるので、これらのクラスターについてはこの手順を省略できます。

    1. ハブクラスターで、以下のコマンドを入力してインポートコマンドを表示します。 

      oc get secret -n ${CLUSTER_NAME} ${CLUSTER_NAME}-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml
      Copy to Clipboard Toggle word wrap

      CLUSTER_NAME は、インポートするマネージドクラスターの名前に置き換えます。

    2. マネージドクラスターで、import.yaml ファイルを適用します。 

      oc apply -f import.yaml
      Copy to Clipboard Toggle word wrap

1.11. クラスターの削除後も namespace が残る
リンクのコピー

マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合には、namaspace を手動で削除する必要があります。

1.11.1. 現象: クラスターの削除後も namespace が残る
リンクのコピー

マネージドクラスターの削除後に namespace が削除されません。

1.11.2. 問題の解決: クラスターの削除後も namespace が残る
リンクのコピー

namespace を手作業で削除するには、以下の手順を実行します。

  1. 次のコマンドを実行して、<cluster_name> namespace に残っているリソースのリストを作成します。 

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>
    Copy to Clipboard Toggle word wrap

    cluster_name は、削除しようとしたクラスターの namespace 名に置き換えます。

  2. 以下のコマンドを入力してリストを編集し、ステータスが Delete ではないリストから特定したリソースを削除します。 

    oc edit <resource_kind> <resource_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    resource_kind は、リソースの種類に置き換えます。resource_name は、リソース名に置き換えます。namespace は、リソースの namespace に置き換えます。

  3. メタデータで finalizer 属性の場所を特定します。
  4. vi エディターの dd コマンドを使用して、Kubernetes 以外のファイナライザーを削除します。
  5. :wq コマンドを入力し、リストを保存して vi エディターを終了します。

  6. 以下のコマンドを入力して namespace を削除します。 

    oc delete ns <cluster-name>
    Copy to Clipboard Toggle word wrap

    CLUSTER_NAME は、削除する namespace の名前に置き換えます。

1.12. クラスターのステータスが offline から available に変わる場合のトラブルシューティング
リンクのコピー

マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offline と available とが切り替わります。

1.12.1. 現象: クラスターのステータスが offline から available に変わる
リンクのコピー

マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offline と available との間で順に切り替わると、ハブクラスターにより報告されます。

1.12.2. 問題の解決: クラスターのステータスが offline から available に変わる
リンクのコピー

この問題を解決するには、以下の手順を実行します。

  1. 次のコマンドを入力して、ハブクラスターで ManagedCluster の仕様を編集します。 

    oc edit managedcluster <cluster-name>
    Copy to Clipboard Toggle word wrap

    cluster-name は、マネージドクラスターの名前に置き換えます。

  2. ManagedCluster 仕様の leaseDurationSeconds の値を増やします。デフォルト値は 5 分ですが、ネットワークの問題がある状態で接続を維持するには十分でない場合があります。リースの時間を長く指定します。たとえば、設定を 20 分に増やします。

作成してたクラスターのステータスがコンソールで Pending または Failed と表示されている場合には、以下の手順を実行して問題のトラブルシューティングを実行します。

Red Hat Advanced Cluster Management for Kubernetes コンソールで新規クラスターを作成した後に、コンソールでクラスターのステータスが Pending または Failed と表示されてそれ以上進みません。

1.13.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター
リンクのコピー

クラスターのステータスが Failed と表示される場合には、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。

  • 手順 1

    1. ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。 

      oc get pod -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name は、作成したクラスター名に置き換えます。

    2. 名前に provision の文字列が含まれる Pod が表示されていない場合には、手順 2 に進みます。タイトルに provision が含まれる Pod があった場合には、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。 

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
      Copy to Clipboard Toggle word wrap

      new_cluster_name_provision_pod_name は、作成したクラスター名の後に provision が含まれる Pod 名を指定するように置き換えます。

    3. ログでエラーを検索してください。この問題の原因が解明する場合があります。

  • 手順 2

    名前に provision が含まれる Pod がない場合には、問題がプロセスの初期段階で発生していますログを表示するには、以下の手順を実行します。

    1. ハブクラスターで以下のコマンドを実行してください。 

      oc describe clusterdeployments -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name は、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの「インストールログの収集」を参照してください。

    2. リソースの Status.Conditions.Message と Status.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。

1.13.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター
リンクのコピー

ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。

以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、関係に必要なアクションが提示されています。 

No subnets provided for zones
Copy to Clipboard Toggle word wrap

クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。

  • リージョン内の異なるゾーンを選択します。
  • 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
  • お使いのクラスターに、別のリージョンを選択します。

ログから問題を特定した後に、クラスターを破棄し、再作成します。

クラスターの作成に関する詳細は、「クラスターの作成」を参照してください。

1.14. アプリケーションの Git サーバー接続のトラブルシューティング
リンクのコピー

open-cluster-management namespace のログでは、Git リポジトリーのクローンの失敗について表示されます。

1.14.1. 現象: Git サーバー接続
リンクのコピー

open-cluster-management namespace にあるサブスクリプションコントローラー Pod multicluster-operators-hub-subscription-<random-characters> のログに、Git リポジトリーのクローン作成に失敗したことが示されています。x509: certificate signed by unknown authority エラーまたは BadGateway エラーが表示されます。

1.14.2. 問題の解決: Git サーバー接続
リンクのコピー

重要: 以前のバージョンを使用している場合には、製品バージョン 2.1 にアップグレードしてください。

  1. apps.open-cluster-management.io_channels_crd.yaml を apps.open-cluster-management.io_channels_crd.yaml というファイル名で保存してください。

  2. Advanced Cluster Management クラスターで以下のコマンドを実行し、ファイルを適用します。 

    oc apply -f apps.open-cluster-management.io_channels_crd.yaml
    Copy to Clipboard Toggle word wrap

  3. open-cluster-management namespace で以下のコマンドを実行して advanced-cluster-management.v2.1.0 CSV を編集します。 

    oc edit csv advanced-cluster-management.v2.1.0 -n open-cluster-management
    Copy to Clipboard Toggle word wrap

    以下のコンテナーを見つけます。

    • multicluster-operators-standalone-subscription

    • multicluster-operators-hub-subscription

      コンテナーイメージは以下に置き換えます。 

      quay.io/open-cluster-management/multicluster-operators-subscription:2.2-PR337-91af6cb37d427d22160b2c055589a4418dada4eb
      Copy to Clipboard Toggle word wrap

    この更新では open-cluster-management namespace に以下の Pod を作成します。

    • multicluster-operators-standalone-subscription-<random-characters>
    • multicluster-operators-hub-subscription-<random-characters>
  4. 新たに作成した Pod が新規 docker イメージで実行されていることを確認します。以下のコマンドを実行して、新しい docker イメージを見つけます。 
oc get pod multicluster-operators-standalone-subscription-<random-characters> -n open-cluster-management -o yaml
oc get pod multicluster-operators-hub-subscription-<random-characters> -n open-cluster-management -o yaml
Copy to Clipboard Toggle word wrap

  1. マネージドクラスターのイメージを更新します。

    ハブクラスターで以下のコマンドを実行します。CLUSTER_NAME は、実際のマネージドクラスター名に置き換えます。 

    oc annotate klusterletaddonconfig -n CLUSTER_NAME CLUSTER_NAME klusterletaddonconfig-pause=true --overwrite=true
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを実行します。CLUSTER_NAME は、実際のマネージドクラスター名に置き換えます。 

    oc edit manifestwork -n CLUSTER_NAME  CLUSTER_NAME-klusterlet-addon-appmgr
    Copy to Clipboard Toggle word wrap

  3. spec.global.imageOverrides.multicluster_operators_subscription を見つけて、値を以下のように設定します。 

    quay.io/open-cluster-management/multicluster-operators-subscription:2.2-PR337-91af6cb37d427d22160b2c055589a4418dada4eb
    Copy to Clipboard Toggle word wrap

    上記の設定で、マネージドクラスターの open-cluster-management-agent-addon namespace に klusterlet-addon-appmgr-<random-characters> Pod が再作成されます。

  4. 新たに作成した Pod が新規 docker イメージで実行されていることを確認します。

  5. コンソールまたは CLI を使用してアプリケーションを作成する場合には、チャネル仕様に「insecureSkipVerify: true」を手動で追加します。以下の例を参照してください。 

    apiVersion: apps.open-cluster-management.io/v1
ind: Channel
metadata:
labels:
  name: sample-channel
  namespace: sample
spec:
  type: GitHub
  pathname: <Git URL>
  insecureSkipVerify: true
    Copy to Clipboard Toggle word wrap

1.15. 配置ルールでローカルクラスターが選択されていない場合のトラブルシューティング
リンクのコピー

マネージドクラスターは配置ルールで選択されますが、local-cluster (同じく管理されているハブクラスター) は選択されません。配置ルールユーザーには、local-cluster namespace に deployable リソースを作成するためのパーミッションは付与されません。

1.15.1. 現象: ローカルクラスターが選択されていない問題のトラブルシューティング
リンクのコピー

すべてのマネージドクラスターは配置ルールで選択されますが、local-cluster は選択されません。配置ルールユーザーには、local-cluster namespace に deployable リソースを作成するためのパーミッションは付与されません。

1.15.2. 問題の解決: ローカルクラスターが選択されていない問題のトラブルシューティング
リンクのコピー

この問題を解決するには、local-cluster namespace に deployable 管理パーミッションを付与する必要があります。以下の手順を実行します。

  1. マネージドクラスターのリストに local-cluster が含まれ、配置ルールの decisions リストにローカルクラスターが表示されないことを確認します。以下のコマンドを実行して結果を表示します。 

    % oc get managedclusters
    Copy to Clipboard Toggle word wrap 
    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
local-cluster   true                                  True     True        56d
cluster1        true                                  True     True        16h
    Copy to Clipboard Toggle word wrap 
    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: all-ready-clusters
  namespace: default
spec:
  clusterSelector: {}
status:
  decisions:
  - clusterName: cluster1
    clusterNamespace: cluster1
    Copy to Clipboard Toggle word wrap

  2. .yaml ファイルに Role を作成し、local-cluster namespace に deployable 管理パーミッションを付与します。以下の例を参照してください。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployables-admin-user-zisis
  namespace: local-cluster
rules:
- apiGroups:
  - apps.open-cluster-management.io
  resources:
  - deployables
  verbs:
  - '*'
    Copy to Clipboard Toggle word wrap

  3. RoleBinding リソースを作成し、配置ルールユーザーに local-cluster namespace へのアクセスを許可します。以下の例を参照してください。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deployables-admin-user-zisis
  namespace: local-cluster
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: deployables-admin-user-zisis
  namespace: local-cluster
subjects:
- kind: User
  name: zisis
  apiGroup: rbac.authorization.k8s.io
    Copy to Clipboard Toggle word wrap

1.16. アプリケーションの Kubernetes デプロイメントバージョンのトラブルシューティング
リンクのコピー

非推奨の Kubernetes apiVersion を使用するマネージドクラスターはサポートされない可能性があります。非推奨の API バージョンの詳細は、Kubernetes issue を参照してください。

1.16.1. 現象: アプリケーションデプロイメントバージョン
リンクのコピー

サブスクリプションの YAML ファイルのアプリケーションリソースの 1 つまたは複数で、非推奨の API が使用されている場合に、以下のようなエラーが発生する可能性があります。 

failed to install release: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for
kind "Deployment" in version "extensions/v1beta1"
Copy to Clipboard Toggle word wrap

または、old.yaml などの名前で YAML ファイルに新しい Kubernetes API バージョンを追加している場合には、以下のエラーが発生する可能性があります。 

error: unable to recognize "old.yaml": no matches for kind "Deployment" in version "deployment/v1beta1"
Copy to Clipboard Toggle word wrap

1.16.2. 解決: アプリケーションデプロイメントバージョン
リンクのコピー

  1. リソースの apiVersion を更新します。たとえば、サブスクリプション YAML ファイルの Deployment の種類のエラーが表示された場合には、apiVersion を extensions/v1beta1 から apps/v1 に更新する必要があります。

    以下の例を参照してください。 

    apiVersion: apps/v1
kind: Deployment
    Copy to Clipboard Toggle word wrap

  2. マネージドクラスターで以下のコマンドを実行して、利用可能なバージョンを確認します。 

    kubectl explain <resource>
    Copy to Clipboard Toggle word wrap
  3. VERSION を確認します。

1.17. スタンドアロンのサブスクリプションメモリーのトラブルシューティング
リンクのコピー

メモリーの問題が原因で multicluster-operators-standalone-subscription Pod が定期的に再起動します。

1.17.1. 現象: スタンドアロンのサブスクリプションメモリー
リンクのコピー

Operator Lifecycle Manager (OLM) が全 Operator をデプロイすると、スタンドアロンのサブスクリプションコンテナーに十分なめオリーが割り当てられていないため、multicluster-subscription-operator だけでなく、multicluster-operators-standalone-subscription Pod も再起動されます。

マルチクラスターサブスクリプションコミュニティー Operator CSV で multicluster-operators-standalone-subscription Pod のメモリーの上限が 2GB に増えましたが、OLM はこのリソース制限の設定を無視します。

1.17.2. 問題の解決: スタンドアロンのサブスクリプションメモリー
リンクのコピー

  1. インストール後に、マルチクラスターサブスクリプションコミュニティー Operator をサブスクライブする Operator サブスクリプション CR を検索します。以下のコマンドを実行します。 

    % oc get sub -n open-cluster-management acm-operator-subscription
    Copy to Clipboard Toggle word wrap

  2. Operator サブスクリプションカスタムリソースを編集し、リソース制限を定義する spec.config.resources .yaml ファイルを追加します。

    注記: 同じマルチクラスターサブスクリプションコミュニティー Operator をサブスクライブする Operator サブスクリプションのカスタムリソースを新たに作成しないでください。2 つの Operator サブスクリプションが 1 つの Operator にリンクされているので、この 2 つの Operator サブスクリプションカスタムリソースは、Operator Pod を 強制終了 して再起動します。

    以下の更新後の .yaml ファイルの例を参照してください。 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: multicluster-operators-subscription-alpha-community-operators-openshift-marketplace
  namespace: open-cluster-management
spec:
  channel: release-2.1
  config:
    resources:
      limits:
        cpu: 750m
        memory: 2Gi
      requests:
        cpu: 150m
        memory: 128Mi
  installPlanApproval: Automatic
  name: multicluster-operators-subscription
  source: community-operators
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

  3. リソースの保存後に、スタンドアロンのサブスクリプション Pod が 2GB のメモリー上限で再起動されるようにします。以下のコマンドを実行します。 

    % oc get pods -n open-cluster-management multicluster-operators-standalone-subscription-7c8cbf885f-c94kz -o yaml
    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
...
spec:
  containers:
  - image: quay.io/open-cluster-management/multicluster-operators-subscription:community-2.1
...
    resources:
      limits:
        cpu: 750m
        memory: 2Gi
      requests:
        cpu: 150m
        memory: 128Mi
...
status:
  qosClass: Burstable
    Copy to Clipboard Toggle word wrap

1.18. 状態が Degraded の Klusterlet のトラブルシューティング
リンクのコピー

Klusterlet の状態が Degraded の場合には、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合には、以下の情報を参照します。

1.18.1. 現象: Klusterlet の状態が degraded である
リンクのコピー

マネージドクラスターで Klusterlet をデプロイした後に、KlusterletRegistrationDegraded または KlusterletWorkDegraded の状態が True と表示されます。

1.18.2. 問題の特定: Klusterlet の状態が degraded である
リンクのコピー

  1. マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します 

    kubectl get klusterlets klusterlet -oyaml
    Copy to Clipboard Toggle word wrap
  2. KlusterletRegistrationDegraded または KlusterletWorkDegraded をチェックして、状態が True に設定されいるかどうかを確認します。記載されている Degraded の状態については、問題の解決 に進みます。

1.18.3. 問題の解決: Klusterlet の状態が degraded である
リンクのコピー

ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。

  • KlusterletRegistrationDegraded の状態が True で、この状態の理由が BootStrapSecretMissing の場合には、open-cluster-management-agent namespace にブートストラップのシークレットを作成する必要があります。
  • KlusterletRegistrationDegraded の状態が True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized の場合には、現在のブートストラップシークレットは無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agent namespace で有効なブートストラップシークレットをもう一度作成します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegraded が True と表示され、状態の理由が HubKubeConfigSecretMissing の場合には、Klusterlet を削除して作成し直します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegraded が True と表示され、状態の理由が ClusterNameMissing、KubeConfigMissing、HubConfigSecretError または HubConfigSecretUnauthorized の場合には、open-cluster-management-agent namespace からハブクラスターの kubeconfig シークレットを削除します。登録エージェントは再度ブートストラップして、新しいハブクラスターの kubecofnig シークレットを取得します。
  • KlusterletRegistrationDegraded が True と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod の場合には、状態のメッセージを確認して、問題の詳細を取得して解決してみてください。
  • KlusterletWorkDegraded が True と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod の場合には、状態のメッセージを確認して、問題の詳細を取得し、解決してみてください。

Red Hat Advanced Cluster Management for Kubernetes をアップグレードすると、Red Hat OpenShift Container Platform マネージドクラスターバージョン 4.5 および 4.6 上の klusterlet-addon-appmgr Pod が OOMKilled になります。

1.19.1. 現象: マネージドクラスター上の Klusterlet アプリケーションマネージャー
リンクのコピー

Red Hat OpenShift Container Platform マネージドクラスターのバージョン 4.5 および 4.6 上の klusterlet-addon-appmgr Pod で OOMKilled のエラーが発生します。

1.19.2. 問題の解決: マネージドクラスター上の Klusterlet アプリケーションマネージャー
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes 2.1.x の場合には、Pod のメモリー制限を手動で 8GB に増やす必要があります。以下の手順を参照してください。

  1. ハブクラスターで、 klusterletaddonconfig にアノテーションを付けてレプリケーションを一時停止します。以下のコマンドを使用します。 

    oc annotate klusterletaddonconfig -n ${CLUSTER_NAME} ${CLUSTER_NAME} klusterletaddonconfig-pause=true --  overwrite=true
    Copy to Clipboard Toggle word wrap

  2. ハブクラスターで、 klusterlet-addon-operator をスケールダウンします。以下のコマンドを使用します。 

    oc edit manifestwork ${CLUSTER_NAME}-klusterlet-addon-operator -n ${CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap

  3. klusterlet-addon-operator デプロイメントを探し、その仕様に replicas: 0 を追加してスケールダウンします。 

    - apiVersion: apps/v1
  kind: Deployment
  metadata:
    labels:
      app: cluster1
    name: klusterlet-addon-operator
    namespace: open-cluster-management-agent-addon
    spec:
      replicas: 0
    Copy to Clipboard Toggle word wrap

    マネージドクラスターでは、 open-cluster-management-agent-addon / klusterlet-addon-operator Pod が終了します。

  4. マネージドクラスターにログインして appmgr Pod のメモリー制限を手動で増やします。

    以下のコマンドを実行します。 

    % oc edit deployments -n open-cluster-management-agent-addon klusterlet-addon-appmgr
    Copy to Clipboard Toggle word wrap

    たとえば、制限が 5G の場合には、8G に増やします。 

    resources:
  limits:
    memory: 2Gi  -> 8Gi
  requests:
    memory: 128Mi -> 256Mi
    Copy to Clipboard Toggle word wrap

1.20. 可観測性のトラブルシューティング
リンクのコピー

可観測性コンポーネントをインストールした後に、コンポーネントが停止し、Installing のステータスが表示されます。

1.20.1. 現象: MultiClusterObservability リソースの状態が停止する
リンクのコピー

可観測性の CustomResosurceDefinition (CRD) をインストールして作成した後に可観測性のステータスが Installing で停止した場合に、spec:storageConfigObject:statefulSetStorageClass パラメーターに値が定義されない可能性があります。または、可観測性コンポーネントは自動的にデフォルトの storageClass を検索しますが、ストレージの値が指定されていない場合には、コンポーネントは Installing ステータスのままになります。

1.20.2. 問題の解決: MultiClusterObservability リソースの状態が停止する
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. 可観測性コンポーネントがインストールされていることを確認します。

    1. multicluster-observability-operator を確認するには、以下のコマンドを実行します。 

      kubectl get pods -n open-cluster-management|grep observability
      Copy to Clipboard Toggle word wrap

    2. 適切な CRD が存在することを確認するには、以下のコマンドを実行します。 

      kubectl get crd|grep observ
      Copy to Clipboard Toggle word wrap

      以下の CRD が表示されるまで、コンポーネントを有効化しないでください。 

      multiclusterobservabilities.observability.open-cluster-management.io
observabilityaddons.observability.open-cluster-management.io
observatoria.core.observatorium.io
      Copy to Clipboard Toggle word wrap
  2. Bare Metal クラスター用に独自の storageClass を作成する場合は、「How to create an NFS provisioner in the cluster or out of the cluster」を参照してください。
  3. 可観測性コンポーネントがデフォルトの storageClass を検索できるようにするには、multicluster-observability-operator CRD の storageClass パラメーターを更新します。パラメーターは、以下のような値になります。 
storageclass.kubernetes.io/is-default-class: "true"
Copy to Clipboard Toggle word wrap

インストールが完了すると、可観測性コンポーネントのステータスが Ready に更新されます。インストールの完了に失敗すると、ステータスが Fail と表示されます。

1.21. OpenShift モニタリングサービスのトラブルシューティング
リンクのコピー

マネージドクラスターの可観測性サービスは OpenShift Container Platform モニタリングスタックからメトリクスを収集する必要があります。metrics-collector は、OpenShift Container Platform モニタリングスタックが準備状態にならないと、インストールされません。

1.21.1. 現象: OpenShift モニタリングサービスが準備状態にならない
リンクのコピー

endpoint-observability-operator-x Pod は、prometheus-k8s サービスが openshift-monitoring namespace で利用可能かどうかを確認します。このサービスが openshift-monitoring namespace に存在しない場合には、metrics-collector はデプロイされません。Failed to get prometheus resource というエラーメッセージが表示される可能性があります。

1.21.2. 問題の解決: OpenShift モニタリングサービスが準備状態にならない
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. OpenShift Container Platform クラスターにログインします。
  2. openshift-monitoring namespace にアクセスし、prometheus-k8s サービスが利用可能であることを確認します。
  3. マネージドクラスターの open-cluster-management-addon-observability namespace で、endpoint-observability-operator-x Pod を再起動します。

1.22. managedcluster リソースに不必要なラベル値が含まれる
リンクのコピー

マネージドクラスターのインポート時に、可観測性コンポーネントがデフォルトでインストールされます。配置ルールは、以下の情報のようになります。 

status:
  decisions:
  - clusterName: sample-managed-cluster
    clusterNamespace: sample-managed-cluster
Copy to Clipboard Toggle word wrap

マネージドクラスターが配置ルールに含まれていない場合には、可観測性コンポーネントはインストールされません。

1.22.1. 現象: managedcluster リソースに不必要なラベル値が含まれる
リンクのコピー

インポートされたクラスターが含まれていない場合には、マネージドクラスターリソースの可観測性サービスが無効になる可能性があります。

注記: サービスを有効にすると、ターゲットのマネージドクラスターを表す vendor:OpenShift ラベルが追加されます。可観測性サービスは、OpenShift Container Platform マネージドクラスターでのみサポートされます。

1.22.2. 問題の解決: managedcluster リソースに不必要なラベル値が含まれる
リンクのコピー

この問題が発生した場合には、ターゲットのマネージドクラスターの可観測性サービスを有効にして managedcluster リソースのラベルを更新します。

以下の手順を実行します。

  1. Red Hat Advanced Cluster Management クラスターにログインします。

  2. 配置ルールを更新して、observability パラメーターの値を enabled に変更します。以下のコマンドを実行します。 

    oc edit placementrule -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを実行して、OpenShift がターゲットのマネージドクラスターのベンダーとしてリストされていることを確認します。 

    oc get managedcluster <CLUSTER NAME> -o yaml
    Copy to Clipboard Toggle word wrap

    metadata.labels.vendor パラメーターの値を OpenShift に更新します。

1.23. metrics-collector のトラブルシューティング
リンクのコピー

メトリクスコレクターは、{product-short} ハブクラスターにメトリクスをプッシュできない可能性があります。

1.23.1. 現象 1: 証明書が無効である
リンクのコピー

マネージドクラスターのインポート後に、metrics-collector-deployment-<pod_name> の証明書が無効であることが原因で以下のエラーメッセージが表示される可能性があります。 

x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap

metrics-collector-deployment-<pod_name> Pod の再起動後に observability-managed-cluster-certs シークレットが削除されるか、再作成されるとエラーが発生します。シークレットで証明書が更新されません。

1.23.2. 問題の解決: 証明書が無効である
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. {product-short} ハブクラスターにログインします。
  2. multicluster-observability-operator-<pod_name> Pod を再起動します。
  3. open-cluster-management-addon-observability namespace にアクセスし、マネージドクラスターで metrics-collector-deployment-<pod_name> Pod を再起動します。

1.23.3. 現象 2: マウントされた永続ボリュームのストレージがすべて使用される
リンクのコピー

data-observability-observatorium-thanos-receive-default-<pod_name> Pod でマウントされた永続ボリュームのストレージが容量に到達すると、メトリクスコレクターはメトリクスをハブクラスターに送信できません。

metrics-collector-deployment-<your_pod_name> Pod のログに no space left on device のエラーメッセージが表示される可能性があります。

1.23.4. 問題の解決: マウントされた永続ボリュームのストレージがすべて使用される
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. OpenShift Container Platform マネージドクラスターにログインします。
  2. data-observability-observatorium-thanos-receive-default-<pod_name> Pod にアクセスし、永続ボリューム要求を増やします。
  3. open-cluster-management-observability namespace で data-observability-observatorium-thanos-receive-default-<pod_name> Pod を再起動します。

1.24. Grafana ダッシュボードの現在のデータが消える
リンクのコピー

Red Hat Advanced Cluster Management コンソールのGrafana ダッシュボードから現在のデータが表示されなくなります。

1.24.1. 現象 1: Grafana ダッシュボードの現在のデータが消える
リンクのコピー

Red Hat Advanced Cluster Management クラスター概要ダッシュボードにはデータがありませんが、履歴データは引き続き利用できます。

1.24.2. 現象 2: statefulSetSize の編集後に PVC が変更されない
リンクのコピー

また、metrics-collector-deployment-x Pod が open-cluster-management-addon-observability namespace で実行されている場合に、これらの Pod のログにメッセージが追加される可能性があります。また、ディスクがいっぱいであることを言及するテキストと、以下のエラーメッセージが表示される場合があります。 

HTTP 500
Copy to Clipboard Toggle word wrap

1.24.3. 問題の解決: PVC サイズの拡張
リンクのコピー

この問題が発生した場合は、以下の手順を実行します。

  1. クエリーを実行して、ディスク容量がいっぱいであることを確認します。

    1. Red Hat OpenShift Container Platform コンソールにログインします。
    2. ナビゲーションメニューから Monitoring > Metrics の順にクリックします。

    3. Expression ウィンドウで以下のクエリーを入力して、クエリーを Volume のコラムで昇順に並べ替えます。 

      kubelet_volume_stats_available_bytes{namespace="open-cluster-management-observability"}/kubelet_volume_stats_capacity_bytes{namespace="open-cluster-management-observability"}
      Copy to Clipboard Toggle word wrap

      注: 値が0の場合にはディスクはいっぱいです。ディスクがいっぱいの場合は、次のタスクを続行します。

  2. data-observability-observatorium-thanos-receive-default-x PVCを展開して、storage パラメーターを MultiClusterObservability (mco) CRの statefulSetSize 値よりも大きい値に更新します。data-observability-observatorium-thanos-receive-default-x PVCごとに、次のコマンドを実行します。 

    kubectl get pvc data-observability-observatorium-thanos-receive-default-0 -o yaml
    Copy to Clipboard Toggle word wrap

    data-observability-observatorium-thanos-receive-default-x PVCは、次の内容のようになります。 

    spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage:
    Copy to Clipboard Toggle word wrap

    これが機能するまでに時間がかかる場合があります。storageとstatus の値が一致すると、変更が有効になります。1 つ前のコマンドを再度実行して確認します。

  3. 次の手順を実行して、修正を確認します。

    1. Red Hat Advanced Cluster Management コンソールにログインします。
    2. ナビゲーションメニューから Observe environments > Overview を選択します。
    3. コンソールヘッダーの近くにある Grafana リンクをクリックして、マネージドクラスターからメトリクスを表示します。
    4. metrics-collector-deployment-x Pod ログを確認してください。ログでエラーが修正されると、Metrics pushed successfully というメッセージが表示されます。

    5. Red Hat OpenShift Container Platform コンソールからクエリーを実行して、ディスクスペースがいっぱいになっていないかどうかを確認します。Expression ウィンドウで以下のクエリーを入力して、クエリーを Volume のコラムで昇順に並べ替えます。 

      kubelet_volume_stats_available_bytes{namespace="open-cluster-management-observability"}/kubelet_volume_stats_capacity_bytes{namespace="open-cluster-management-observability"}
      Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat