Red Hat Summitサポート
OpenShift Container Platform のサポート
概要
第1章 サポート
1.1. サポート
このドキュメントで説明する手順に関連した問題が発生する場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルから、以下を行うことができます。
- Red Hat 製品に関する技術サポート記事の Red Hat ナレッジベースの検索またはブラウズ。
Red Hat サポートに対するサポートケースの送信。
注記サポートケースを送信する際、Red Hat サポートのトラブルシューティングに役立つ以下の情報を提供していただくことをお勧めします。
-
oc adm must-gatherコマンドを使用して収集されるデータ - 一意のクラスター ID。(?) Help → Open Support Case に移動すると、ケースの送信時にクラスター ID が自動入力されます。
-
- 他の製品ドキュメントへのアクセス。
本書の改善が提案されている場合や、エラーが見つかった場合は、Documentation コンポーネントの OpenShift Container Platform 製品に対して、Bugzilla レポート を送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。
第2章 クラスターに関するデータの収集
サポートケースを作成する際、ご使用のクラスターについてのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。
以下を提供することが推奨されます。
2.1. must-gather ツールについて
oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。
- リソース定義
- 監査ログ
- サービスログ
--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。
oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。
2.2. Red Hat サポート用のクラスターについてのデータの収集
oc adm must-gather CLI コマンドを使用して、クラスターについてのデバッグ情報を収集できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift Container Platform CLI (
oc) がインストールされている。
手順
-
must-gatherデータを保存するディレクトリーに移動します。 oc adm must-gatherコマンドを実行します。$ oc adm must-gather
注記このコマンドが失敗する場合 (クラスターで Pod をスケジュールできない場合など)、
oc adm inspectコマンドを使用して特定リソースについての情報を収集します。収集する推奨リソースについては、Red Hat サポートにお問い合わせください。注記クラスターがネットワークが制限された環境を使用している場合、
oc adm must-gatherコマンドを実行する前に、デフォルトの must-gather イメージをインポートする必要があります。$ oc import-image is/must-gather -n openshift
作業ディレクトリーに作成された
must-gatherディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1- 1
must-gather-local.5421342344627712289/を実際のディレクトリー名に置き換えてください。
- 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。
2.3. 特定の機能に関するデータ収集
oc adm must-gather CLI コマンドを --image または --image-stream 引数と共に使用して、特定に機能についてのデバッグ情報を収集できます。must-gather ツールは複数のイメージをサポートするため、単一のコマンドを実行して複数の機能についてのデータを収集できます。
| イメージ | 目的 |
|---|---|
|
| container-native virtualization のデータ収集。 |
|
| OpenShift Serverless のデータ収集。 |
|
| Red Hat OpenShift Service Mesh のデータ収集。 |
|
| 移行関連情報のデータ収集。 |
|
| Red Hat OpenShift Container Storage のデータ収集。 |
|
| Red Hat OpenShift クラスターロギングのデータ収集。 |
特定の機能データに加えてデフォルトの must-gather データを収集するには、--image-stream=openshift/must-gather 引数を追加します。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift Container Platform CLI (
oc) がインストールされている。
手順
-
must-gatherデータを保存するディレクトリーに移動します。 oc adm must-gatherコマンドを 1 つまたは複数の--imageまたは--image-stream引数と共に実行します。たとえば、以下のコマンドは、デフォルトのクラスターデータと {VirtProductName} に固有の情報の両方を収集します。$ oc adm must-gather \ --image-stream=openshift/must-gather \ 1 --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8 2
must-gatherツールを追加の引数と共に使用し、クラスターロギングおよびクラスター内の Cluster Logging Operator に関連するデータを収集できます。クラスターロギングの場合、以下のコマンドを実行します。$ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \ -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')例2.1 クラスターロギングの
must-gatherの出力例├── cluster-logging │ ├── clo │ │ ├── cluster-logging-operator-74dd5994f-6ttgt │ │ ├── clusterlogforwarder_cr │ │ ├── cr │ │ ├── csv │ │ ├── deployment │ │ └── logforwarding_cr │ ├── collector │ │ ├── fluentd-2tr64 │ ├── curator │ │ └── curator-1596028500-zkz4s │ ├── eo │ │ ├── csv │ │ ├── deployment │ │ └── elasticsearch-operator-7dc7d97b9d-jb4r4 │ ├── es │ │ ├── cluster-elasticsearch │ │ │ ├── aliases │ │ │ ├── health │ │ │ ├── indices │ │ │ ├── latest_documents.json │ │ │ ├── nodes │ │ │ ├── nodes_stats.json │ │ │ └── thread_pool │ │ ├── cr │ │ ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms │ │ └── logs │ │ ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms │ ├── install │ │ ├── co_logs │ │ ├── install_plan │ │ ├── olmo_logs │ │ └── subscription │ └── kibana │ ├── cr │ ├── kibana-9d69668d4-2rkvz ├── cluster-scoped-resources │ └── core │ ├── nodes │ │ ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml │ └── persistentvolumes │ ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml ├── event-filter.html ├── gather-debug.log └── namespaces ├── openshift-logging │ ├── apps │ │ ├── daemonsets.yaml │ │ ├── deployments.yaml │ │ ├── replicasets.yaml │ │ └── statefulsets.yaml │ ├── batch │ │ ├── cronjobs.yaml │ │ └── jobs.yaml │ ├── core │ │ ├── configmaps.yaml │ │ ├── endpoints.yaml │ │ ├── events │ │ │ ├── curator-1596021300-wn2ks.162634ebf0055a94.yaml │ │ │ ├── curator.162638330681bee2.yaml │ │ │ ├── elasticsearch-delete-app-1596020400-gm6nl.1626341a296c16a1.yaml │ │ │ ├── elasticsearch-delete-audit-1596020400-9l9n4.1626341a2af81bbd.yaml │ │ │ ├── elasticsearch-delete-infra-1596020400-v98tk.1626341a2d821069.yaml │ │ │ ├── elasticsearch-rollover-app-1596020400-cc5vc.1626341a3019b238.yaml │ │ │ ├── elasticsearch-rollover-audit-1596020400-s8d5s.1626341a31f7b315.yaml │ │ │ ├── elasticsearch-rollover-infra-1596020400-7mgv8.1626341a35ea59ed.yaml │ │ ├── events.yaml │ │ ├── persistentvolumeclaims.yaml │ │ ├── pods.yaml │ │ ├── replicationcontrollers.yaml │ │ ├── secrets.yaml │ │ └── services.yaml │ ├── openshift-logging.yaml │ ├── pods │ │ ├── cluster-logging-operator-74dd5994f-6ttgt │ │ │ ├── cluster-logging-operator │ │ │ │ └── cluster-logging-operator │ │ │ │ └── logs │ │ │ │ ├── current.log │ │ │ │ ├── previous.insecure.log │ │ │ │ └── previous.log │ │ │ └── cluster-logging-operator-74dd5994f-6ttgt.yaml │ │ ├── cluster-logging-operator-registry-6df49d7d4-mxxff │ │ │ ├── cluster-logging-operator-registry │ │ │ │ └── cluster-logging-operator-registry │ │ │ │ └── logs │ │ │ │ ├── current.log │ │ │ │ ├── previous.insecure.log │ │ │ │ └── previous.log │ │ │ ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml │ │ │ └── mutate-csv-and-generate-sqlite-db │ │ │ └── mutate-csv-and-generate-sqlite-db │ │ │ └── logs │ │ │ ├── current.log │ │ │ ├── previous.insecure.log │ │ │ └── previous.log │ │ ├── curator-1596028500-zkz4s │ │ ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms │ │ ├── elasticsearch-delete-app-1596030300-bpgcx │ │ │ ├── elasticsearch-delete-app-1596030300-bpgcx.yaml │ │ │ └── indexmanagement │ │ │ └── indexmanagement │ │ │ └── logs │ │ │ ├── current.log │ │ │ ├── previous.insecure.log │ │ │ └── previous.log │ │ ├── fluentd-2tr64 │ │ │ ├── fluentd │ │ │ │ └── fluentd │ │ │ │ └── logs │ │ │ │ ├── current.log │ │ │ │ ├── previous.insecure.log │ │ │ │ └── previous.log │ │ │ ├── fluentd-2tr64.yaml │ │ │ └── fluentd-init │ │ │ └── fluentd-init │ │ │ └── logs │ │ │ ├── current.log │ │ │ ├── previous.insecure.log │ │ │ └── previous.log │ │ ├── kibana-9d69668d4-2rkvz │ │ │ ├── kibana │ │ │ │ └── kibana │ │ │ │ └── logs │ │ │ │ ├── current.log │ │ │ │ ├── previous.insecure.log │ │ │ │ └── previous.log │ │ │ ├── kibana-9d69668d4-2rkvz.yaml │ │ │ └── kibana-proxy │ │ │ └── kibana-proxy │ │ │ └── logs │ │ │ ├── current.log │ │ │ ├── previous.insecure.log │ │ │ └── previous.log │ └── route.openshift.io │ └── routes.yaml └── openshift-operators-redhat ├── ...作業ディレクトリーに作成された
must-gatherディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1- 1
must-gather-local.5421342344627712289/を実際のディレクトリー名に置き換えてください。
- 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。
2.4. クラスター ID の取得
Red Hat サポートに情報を提供する際には、クラスターに固有の識別子を提供していただくと役に立ちます。OpenShift Container Platform Web コンソールを使用してクラスター ID を自動入力できます。Web コンソールまたは OpenShift CLI (oc) を使用してクラスター ID を手動で取得することもできます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
Web コンソールまたはインストールされている OpenShift CLI (
oc) へのアクセスがあること。
手順
Web コンソールを使用してサポートケースを開き、クラスター ID の自動入力を行うには、以下を実行します。
- ツールバーから、(?) Help → Open Support Case に移動します。
- Cluster ID 値は自動入力されます。
Web コンソールを使用してクラスター ID を手動で取得するには、以下を実行します。
- Home → Dashboards → Overview に移動します。
- 値は Details セクションの Cluster ID フィールドで利用できます。
OpenShift CLI (
oc) を使用してクラスター ID を取得するには、以下のコマンドを実行します。$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
第3章 接続クラスターを使用したリモートヘルスモニターリング
3.1. リモートヘルスモニターリングについて
OpenShift Container Platform はクラスターの健全性、使用状況、およびクラスターのサイズについての匿名の集計情報を収集し、統合コンポーネントの Telemetry および Insights Operator 経由で これを Red Hat にレポートします。Red Hat では、このような情報を OpenShift Container Platform の改善のために、またお客様に影響を与える問題への対応を迅速化するために使用します。また、これにより Red Hat のお客様のサブスクリプションとエンタイトルメントのプロセスが単純化され、Red Hat OpenShift Cluster Manager サービスによってクラスター、その健全性およびサブスクリプションのステータスについての概要を提供することが可能になります。
Telemetry および Insights Operator 経由でデータを Red Hat にレポートするクラスターは 接続クラスター (connected cluster) と見なされます。
3.1.1. Telemetry について
Telemetry は厳選されたクラスターモニタリングメトリクスのサブセットを Red Hat に送信します。これらのメトリクスは継続的に送信され、以下について記述します。
- OpenShift Container Platform クラスターのサイズ
- OpenShift Container Platform コンポーネントの健全性およびステータス
- 実行されるアップグレードの正常性およびステータス
- OpenShift Container Platform のコンポーネントおよび機能についての使用情報 (一部の制限された情報)
- クラスターモニターリングコンポーネントによってレポートされるアラートについてのサマリー情報
Red Hat では、リアルタイムでクラスターの健全性をモニターし、お客様に影響を与える問題に随時対応するためにこのデータの継続的なストリームを使用します。またこれにより、Red Hat がサービスへの影響を最小限に抑えつつつアップグレードエクスペリエンスの継続的な改善に向けた OpenShift Container Platform のアップグレードの展開を可能にします。
このデバッグ情報は、サポートケースでレポートされるデータへのアクセスと同じ制限が適用された状態で Red Hat サポートおよびエンジニアリングチームが利用できます。接続クラスターのすべての情報は、OpenShift Container Platform をより使用しやすく、より直感的に使用できるようにするために Red Hat によって使用されます。この情報のいずれもサードパーティーと共有されることはありません。
3.1.1.1. Telemetry で収集される情報
Telemetry によって収集される主な情報には、以下が含まれます。
- クラスターごとに利用可能な更新の数
- 更新に使用されるチャネルおよびイメージリポジトリー
- 更新中に発生するエラーの数
- 実行中の更新の進捗情報
- クラスターごとのマシン数
- CPU コアの数およびマシンの RAM のサイズ
- etcd クラスターのメンバー数、および現在 etcd クラスターに保存されているオブジェクトの数
- マシンタイプ (インフラまたはマスター) ごとに使用される CPU コアおよび RAM の数
- クラスターごとに使用される CPU コアおよび RAM の数
- クラスターごとの OpenShift Container Platform フレームワークコンポーネントの使用
- OpenShift Container Platform クラスターのバージョン
- クラスターにインストールされている OpenShift Container Platform フレームワークコンポーネントの健全性、状態、およびステータス。 たとえば、クラスターバージョン Operator、クラスターモニターリング、イメージレジストリー、およびロギング用の Elasticsearch がこれらのコンポーネントに含まれます。
- インストール時に生成される一意でランダムな識別子
- Amazon Web Services などの OpenShift Container Platform がデプロイされているプラットフォームの名前
Telemetry は、ユーザー名、パスワード、またはユーザーリソースの名前またはアドレスなどの識別情報を収集しません。
3.1.2. Insights Operator について
Insights Operator は、匿名の設定およびコンポーネントの障害状態についての情報を定期的に収集し、これを Red Hat にレポートします。これは must-gather ツールによってキャプチャーされる情報のサブセットであり、これよって Red Hat は重要な設定にアクセスし、Telemetry 経由でレポートされる障害についてのデータよりも深い洞察の得られる情報にアクセスできます。このデータは 1 日に数回送信され、以下について記述します。
- クラスターが実行される環境についての重要な設定情報
- クラスターおよびその主要なコンポーネントの状態についての詳細情報
- 障害をレポートするインフラストラクチャー Pod またはノードについてのデバッグ情報
このデバッグ情報は、サポートケースでレポートされるデータへのアクセスと同じ制限が適用された状態で Red Hat サポートおよびエンジニアリングチームが利用できます。接続クラスターのすべての情報は、OpenShift Container Platform をより使用しやすく、より直感的に使用できるようにするために Red Hat によって使用されます。この情報のいずれもサードパーティーと共有されることはありません。
3.1.2.1. Insights Operator によって収集される情報
Insights Operator によって収集される主要な情報には、以下が含まれます。
- クラスターおよびそのコンポーネントのバージョン、および一意のクラスター ID
- 更新に使用されるチャネルおよびイメージリポジトリー
- クラスターコンポーネントで発生したエラーについての詳細情報
- 実行中の更新の進捗および正常性についての情報、およびコンポーネントのアップグレードのステータス
- Red Hat サポートに関連するクラスター設定についての匿名の詳細情報
- Red Hat サポートに影響を与える可能性のあるテクノロジープレビューまたはサポート対象外の設定についての詳細情報
- Amazon Web Services などの OpenShift Container Platform がデプロイされるプラットフォームや、クラスターが置かれるリージョンについての詳細情報
- 動作が低下した OpenShift Container Platform クラスター Operator の Pod についての情報
-
NotReadyとマークされているノードについての情報 - 動作が低下した Operator の関連オブジェクトとして一覧表示されるすべての namespace のイベント
- 匿名の証明書署名要求 (CSR) および証明書の有効性に関する情報
Insights Operator は、ユーザー名、パスワード、またはユーザーリソースの名前またはアドレスなどの識別情報を収集しません。
3.2. リモートヘルスモニターリングによって収集されるデータの表示
管理者は、Telemetry および Insights Operator によって収集されるメトリクスを確認できます。
3.2.1. Telemetry によって収集されるデータの表示
Telemetry でキャプチャーされるクラスターとコンポーネントの時系列データを表示することができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
OpenShift Container Platform クラスターで実行される Prometheus サービスの URL を見つけます。
$ oc get route prometheus-k8s -n openshift-monitoring -o jsonpath="{.spec.host}"- URL に移動します。
このクエリーを Expression 入力ボックスに入力し、Execute を押します。
{__name__="up"} or {__name__="cluster_version"} or {__name__="cluster_version_available_updates"} or {__name__="cluster_operator_up"} or {__name__="cluster_operator_conditions"} or {__name__="cluster_version_payload"} or {__name__="cluster_version_payload_errors"} or {__name__="instance:etcd_object_counts:sum"} or {__name__="ALERTS",alertstate="firing"} or {__name__="code:apiserver_request_count:rate:sum"} or {__name__="kube_pod_status_ready:etcd:sum"} or {__name__="kube_pod_status_ready:image_registry:sum"} or {__name__="cluster:capacity_cpu_cores:sum"} or {__name__="cluster:capacity_memory_bytes:sum"} or {__name__="cluster:cpu_usage_cores:sum"} or {__name__="cluster:memory_usage_bytes:sum"} or {__name__="openshift:cpu_usage_cores:sum"} or {__name__="openshift:memory_usage_bytes:sum"} or {__name__="cluster:node_instance_type_count:sum"}このクエリーは、Telemetry が実行中の OpenShift Container Platform クラスターの Prometheus サービスに対して行う要求をレプリケートし、Telemetry によってキャプチャーされる時系列の完全なセットを返します。
3.2.2. Insights Operator によって収集されるデータの表示
Insights Operator で収集されるデータを確認することができます。
前提条件
-
cluster-adminロールを持つユーザーとしてのクラスターへのアクセスがあること。
手順
Insights Operator の現在実行中の Pod の名前を検索します。
$ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers --field-selector=status.phase=Running)
Insights Operator で収集される最近のデータアーカイブをコピーします。
$ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data
最近の Insights Operator アーカイブが insights-data ディレクトリーで利用可能になります。
3.3. リモートヘルスレポートのオプトアウト
クラスターの健全性や使用状況についてのデータのレポートをオプトアウトする必要が生じる可能性があります。たとえば、プライバシー法または組織の監視データのレポート方法を規定する各種の標準に従う必要がある場合がその例となります。
リモートヘルスレポートをオプトアウトするには、以下を実行する必要があります。
- グローバルクラスタープルシークレットを変更 してリモートヘルスレポートを無効にします。
- この変更されたプルシークレットを使用するように クラスターを更新 します。
3.3.1. リモートヘルスレポートを無効した場合の影響
OpenShift Container Platform では、健全性や使用状況についての情報のレポートをオプトアウトできます。ただし、接続クラスターは Red Hat が問題により迅速に対応し、お客様をより効果的にサポートし、製品のアップグレードによるクラスターへの影響をより明確に把握することを可能にします。
そのため、実稼働クラスターでのオプトアウトが必要な場合であっても、実稼働以前の環境やテストクラスターでは健全性および使用状況についてのレポートを有効な状態にしておくことが強く推奨されます。これにより、Red Hat は OpenShift Container Platform をご使用の環境に適合させ、製品関連の問題により迅速に対応する上で貢献することができます。
接続クラスターのオプトアウトによる影響には、以下が含まれます。
- Red Hat はサポートケースが作成されない限り、製品アップグレードの正常性やクラスターの健全性を監視することができません。
- Red Hat は匿名の設定データを使用して、お客様のサポートケースの優先付けや、お客様にとって重要な設定を特定することができません。
- Red Hat OpenShift Cluster Manager は健全性や使用状況についての情報を含むクラスターについてのデータを表示できません。
- 使用状況の自動レポート機能を使用できないため、サブスクリプションのエンタイトルメント情報は cloud.redhat.com で手動で入力する必要があります。
ネットワークが制限された環境の場合も、プロキシーの適切な設定により Telemetry および Insights データは依然としてレポートされます。
3.3.2. グローバルクラスタープルシークレットの変更によるリモートヘルスレポートの無効化
既存のグローバルクラスタープルシークレットを変更して、リモートヘルスレポートを無効にすることができます。これにより、Telemetry と Insights Operator の両方が無効になります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
グローバルクラスタープルシークレットをローカルファイルシステムにダウンロードします。
$ oc extract secret/pull-secret -n openshift-config --to=.
-
テキストエディターで、ダウンロードした
.dockerconfigjsonファイルを編集します。 以下のように
cloud.openshift.comJSON エントリーを削除します。"cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}- ファイルを保存します。
この変更されたプルシークレットを使用できるようにクラスターを更新できます。
3.3.3. グローバルクラスタープルシークレットの更新
クラスターのグローバルプルシークレットを更新できます。
クラスターリソースは新規のプルシークレットに合わせて調整する必要がありますが、これにより、クラスターのユーザービリティーが一時的に制限される可能性があります。
前提条件
- アップロードする新規または変更されたプルシークレットファイルがある。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行して、クラスターのグローバルプルシークレットを更新します。
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull-secret-location> 1- 1
- 新規プルシークレットファイルへのパスを指定します。
この更新はすべてのノードにロールアウトされます。これには、クラスターのサイズに応じて多少時間がかかる場合があります。この間に、ノードがドレイン (解放) され、Pod は残りのノードで再スケジュールされます。
