サポート

手順

1. OpenShift Container Platform クラスターで実行される Prometheus サービスの URL を見つけます。

   $ oc get route prometheus-k8s -n openshift-monitoring -o jsonpath="{.spec.host}"

2. URL に移動します。

3. このクエリーを Expression 入力ボックスに入力し、Execute を押します。

   {__name__=~"cluster:usage:.*|count:up0|count:up1|cluster_version|cluster_version_available_updates|cluster_operator_up|cluster_operator_conditions|cluster_version_payload|cluster_installer|cluster_infrastructure_provider|cluster_feature_set|instance:etcd_object_counts:sum|ALERTS|code:apiserver_request_total:rate:sum|cluster:capacity_cpu_cores:sum|cluster:capacity_memory_bytes:sum|cluster:cpu_usage_cores:sum|cluster:memory_usage_bytes:sum|openshift:cpu_usage_cores:sum|openshift:memory_usage_bytes:sum|workload:cpu_usage_cores:sum|workload:memory_usage_bytes:sum|cluster:virt_platform_nodes:sum|cluster:node_instance_type_count:sum|cnv:vmi_status_running:count|node_role_os_version_machine:cpu_capacity_cores:sum|node_role_os_version_machine:cpu_capacity_sockets:sum|subscription_sync_total|csv_succeeded|csv_abnormal|ceph_cluster_total_bytes|ceph_cluster_total_used_raw_bytes|ceph_health_status|job:ceph_osd_metadata:count|job:kube_pv:count|job:ceph_pools_iops:total|job:ceph_pools_iops_bytes:total|job:ceph_versions_running:count|job:noobaa_total_unhealthy_buckets:sum|job:noobaa_bucket_count:sum|job:noobaa_total_object_count:sum|noobaa_accounts_num|noobaa_total_usage|console_url|cluster:network_attachment_definition_instances:max|cluster:network_attachment_definition_enabled_instance_up:max|insightsclient_request_send_total|cam_app_workload_migrations|cluster:apiserver_current_inflight_requests:sum:max_over_time:2m|cluster:telemetry_selected_series:count",alertstate=~"firing|"}

   このクエリーは、Telemetry が実行中の OpenShift Container Platform クラスターの Prometheus サービスに対して行う要求をレプリケートし、Telemetry によってキャプチャーされる時系列の完全なセットを返します。

手順

1. Insights Operator の現在実行中の Pod の名前を検索します。

   $ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

2. Insights Operator で収集される最近のデータアーカイブをコピーします。

   $ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

手順

1. グローバルクラスタープルシークレットをローカルファイルシステムにダウンロードします。

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. テキストエディターで、ダウンロードした .dockerconfigjson ファイルを編集します。

3. 以下のように cloud.openshift.com JSON エントリーを削除します。

   "cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}

4. ファイルを保存します。

手順

1. オプション: 既存のプルシークレットに新しいプルシークレットを追加するには、以下の手順を実行します。

   1. 以下のコマンドを入力してプルシークレットをダウンロードします。

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      プルシークレットファイルへのパスを指定します。

   2. 以下のコマンドを実行して、新しいプルシークレットを追加します。

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      新しいレジストリーを指定します。同じレジストリー内に複数のリポジトリーを含めることができます (例: --registry="<registry/my-namespace/my-repository>")。

      2

      新しいレジストリーの認証情報を指定します。

      3

      プルシークレットファイルへのパスを指定します。

      または、プルシークレットファイルを手動で更新することもできます。

2. 以下のコマンドを実行して、クラスターのグローバルプルシークレットを更新します。

   $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   新規プルシークレットファイルへのパスを指定します。

手順

1. 左側のペインで Clusters メニューをクリックします。
2. クラスターの名前をクリックして、クラスターの詳細を表示します。

3. クラスターの Insights タブを開きます。

   その結果に応じて、タブには以下のいずれかが表示されます。

   • Your cluster passed all health checks: Insights がいずれの問題も特定しなかった場合。
   • Insights が検出さる問題の一覧。これらの問題には、リスクに基づいて優先度 (低 low、中 moderate、重要 importanto および重大 critical) が付けられます。
   • No health checks to display: Insights がクラスターを分析していない場合。この分析は、クラスターがインストールされ、インターネットに接続された直後に開始します。

4. 問題がタブに表示される場合、エントリーの前にある > アイコンをクリックして詳細を確認してください。

   この問題によっては、詳細情報に Red Hat ナレッジベースアーティクルへのリンクが含まれることがあります。問題の解決方法の詳細については、How to remediate this issue をクリックしてください。

手順

1. Insights Operator の実行中の Pod の名前を見つけます。

   $ oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running

2. Insights Operator で収集される最近のデータアーカイブをコピーします。

   $ oc cp openshift-insights/<insights_operator_pod_name>:/var/lib/insights-operator ./insights-data 1

   1

   <insights_operator_pod_name> を、前のコマンドから出力された Pod 名に置き換えます。

手順

1. アーカイブから /insights-operator/gathers.json を開きます。

   このファイルには、Insights Operator 収集操作のリストが含まれています。

       {
         "name": "clusterconfig/authentication",
         "duration_in_ms": 730, 1
         "records_count": 1,
         "errors": null,
         "panic": null
       }

   1

   duration_in_ms は、各収集操作にかかるミリ秒単位の時間です。

2. 各収集操作に異常がないか検査します。

手順

1. 現在実行中の Insights Operator Pod の名前を見つけます。

   $ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

2. Insights Operator コンテナーから最近のデータアーカイブをコピーします。

   $ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

手順

1. dockerconfig.json ファイルをダウンロードします。

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. dockerconfig.json ファイルから" cloud.openshift.com" "auth " トークンをコピーします。

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "asd@redhat.com"
       }
   }

3. console.redhat.com にアーカイブをアップロードします。

   $ curl -v -H "User-Agent: insights-operator/one10time200gather184a34f6a168926d93c330 cluster/<cluster_id>" -H "Authorization: Bearer <your_token>" -F "upload=@<path_to_archive>; type=application/vnd.redhat.openshift.periodic+tar" https://console.redhat.com/api/ingress/v1/upload

   ここで、<cluster_id> はクラスター ID、<your_token> はプルシークレットからのトークン、<path_to_archive> は Insights Operator アーカイブへのパスに置き換えます。

   操作に成功すると、コマンドは "request_id" と "account_number" を返します。

   出力例

   * Connection #0 to host console.redhat.com left intact
   {"request_id":"393a7cf1093e434ea8dd4ab3eb28884c","upload":{"account_number":"6274079"}}%

検証手順

1. https://console.redhat.com/openshift にログインします。
2. 左側のペインで Clusters メニューをクリックします。
3. クラスターの詳細を表示するには、クラスターの名前をクリックします。

4. クラスターの Insights Advisor タブを開きます。

   アップロードに成功すると、タブには以下のいずれかが表示されます。

   • Your cluster passed all recommendations: Insights でないも問題が特定されなかった場合。
   • Insights Advisor が検出した問題。リスク (低、中、重要および重大) 別に優先度が付けられます。

手順

1. must-gather データを保存するディレクトリーに移動します。

2. oc adm must-gather コマンドを実行します。

   $ oc adm must-gather

   注記

   このコマンドが失敗する場合 (クラスターで Pod をスケジュールできない場合など)、oc adm inspect コマンドを使用して特定リソースについての情報を収集します。収集する推奨リソースについては、Red Hat サポートにお問い合わせください。

   注記

   クラスターがネットワークが制限された環境を使用している場合、追加の手順を実行する必要があります。ミラーレジストリーに信頼される CA がある場合、まず信頼される CA をクラスターに追加する必要があります。ネットワークが制限された環境のすべてのクラスターについて、oc adm must-gather コマンドを使用する前に、デフォルトの must-gather イメージをイメージストリームとしてインポートする必要があります。

   $ oc import-image is/must-gather -n openshift

3. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/ を実際のディレクトリー名に置き換えてください。

4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

手順

1. must-gather データを保存するディレクトリーに移動します。

2. oc adm must-gather コマンドを 1 つまたは複数の --image または --image-stream 引数と共に実行します。たとえば、以下のコマンドは、デフォルトのクラスターデータと OpenShift Virtualization に固有の情報の両方を収集します。

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
    --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.5.8 2

   1

   デフォルトの OpenShift Container Platform must-gather イメージ

   2

   OpenShift Virtualization の must-gather イメージ

   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}')

   例5.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-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
      │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
      │  │  │  ├── elasticsearch-im-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-im-app-1596030300-bpgcx
      │  │  │  ├── elasticsearch-im-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
         ├── ...

3. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/ を実際のディレクトリー名に置き換えてください。

4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

手順

1. -- /usr/bin/gather_audit_logs フラグを使用して oc adm must-gather コマンドを実行します。

   $ oc adm must-gather -- /usr/bin/gather_audit_logs

2. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

   1

   must-gather-local.472290403699006248 は、実際のディレクトリー名に置き換えます。

3. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

1. Ignition 設定ファイルが作成されます。
2. ブートストラップマシンが起動し、コントロールプレーンマシン (別名マスターマシン) の起動に必要なリモートリソースのホスティングを開始します。
3. コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。
4. コントロールプレーンマシンはブートストラップマシンを使用して、etcd クラスターを作成します。
5. ブートストラップマシンは、新規 etcd クラスターを使用して一時的な Kubernetes コントロールプレーンを起動します。
6. 一時的なコントロールプレーンは、実稼働コントロールプレーンをコントロールプレーンマシンにスケジュールします。
7. 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
8. ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに追加します。
9. インストールプログラムはブートストラップマシンをシャットダウンします。
10. コントロールプレーンはワーカーノードをセットアップします。
11. コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。
12. クラスターはサポートされる環境でのワーカーマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。

手順

1. haproxy systemd サービスがアクティブであることを確認します。

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. ロードバランサーが必要なポートでリッスンしていることを確認します。以下の例では、ポート 80、443、6443、および 22623 を参照します。

   • Red Hat Enterprise Linux (RHEL) 6 で実行している HAProxy インスタンスの場合は、netstat コマンドを使用して、ポートのステータスを確認します。

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • Red Hat Enterprise Linux (RHEL) 7 または 8 で実行している HAProxy インスタンスの場合、ss コマンドを使用して、ポートのステータスを確認します。

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     注記

     Red Hat は、Red Hat Enterprise Linux (RHEL) 7 以降の netstat ではなく、ss コマンドを推奨しています。ss は、iproute パッケージで提供されます。ss コマンドの詳細は、Red Hat Enterprise Linux (RHEL) 7 パフォーマンスチューニングガイド を参照してください。

3. ワイルドカード DNS レコードがロードバランサーに解決されていることを確認します。

   $ dig <wildcard_fqdn> @<dns_server>

手順

1. インストールの進捗に応じてインストールログを監視します。

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. 起動後にブートストラップノードで bootkube.service journald ユニットログを監視します。これにより、最初のコントロールプレーンのブートストラップを可視化できます。<bootstrap_fqdn> をブートストラップノードの完全修飾ドメイン名に置き換えます。

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注記

   ブートストラップノードの bootkube.service のログは etcd の connection refused エラーを出力し、ブートストラップサーバーがコントロールプレーンノードの etcd に接続できないことを示します。etcd が各コントロールプレーンノードで起動し、ノードがクラスターに参加した後には、エラーは発生しなくなるはずです。

3. 起動後のコントロールプレーンノードで kubelet.service journald ユニットログを監視します。これにより、コントロールプレーンノードエージェントのアクティビティーを可視化できます。

   1. oc を使用してログを監視します。

      $ oc adm node-logs --role=master -u kubelet

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

4. 起動後のコントロールプレーンノードで crio.service journald ユニットログを監視します。これにより、コントロールプレーンノードの CRI-O コンテナーランタイムのアクティビティーを可視化できます。

   1. oc を使用してログを監視します。

      $ oc adm node-logs --role=master -u crio

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

手順

1. ブートストラップノードのコンソールにアクセスできる場合は、ノードがログインプロンプトに到達するまでコンソールを監視します。

2. Ignition ファイル設定を検証します。

   • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合。

     1. ブートストラップノードの Ignition ファイル URL を確認します。<http_server_fqdn> を HTTP サーバーの完全修飾ドメイン名に置き換えます。

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        -I オプションはヘッダーのみを返します。Ignition ファイルが指定された URL で利用可能な場合、コマンドは 200 OK ステータスを返します。これが利用できない場合は、コマンドは 404 file not found を返します。

     2. Ignition ファイルがブートストラップノードで受信されたことを確認するには、提供側ホストの HTTP サーバーログをクエリーします。たとえば、Apache Web サーバーを使用して Ignition ファイルを提供する場合は、以下のコマンドを入力します。

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        ブートストラップ Ignition ファイルが受信される場合、関連付けられた HTTP GET ログメッセージには要求が成功したことを示す 200 OK の成功ステータスが含まれます。

     3. Ignition ファイルが受信されていない場合には、Ignition ファイルが存在し、それらに提供側ホストの適切なファイルおよび Web サーバーパーミッションがあることを直接確認します。

   • クラウドプロバイダーのメカニズムを使用して Ignition 設定ファイルを初期デプロイメントの一部としてホストに挿入する場合。

     1. ブートストラップノードのコンソールを確認し、ブートストラップノードの Ignition ファイルを正しく挿入するメカニズムが機能しているかどうかを確認します。
3. ブートストラップノードの割り当てられたストレージデバイスの可用性を確認します。
4. ブートストラップノードに DHCP サーバーから IP アドレスが割り当てられていることを確認します。

5. ブートストラップノードから bootkube.service journald ユニットログを収集します。<bootstrap_fqdn> をブートストラップノードの完全修飾ドメイン名に置き換えます。

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注記

   ブートストラップノードの bootkube.service ログは、etcd の connection refused エラーを出力し、ブートストラップサーバーがコントロールプレーンノード (別名マスターノード) の etcd に接続できないことを示します。etcd が各コントロールプレーンノードで起動し、ノードがクラスターに参加した後には、エラーは発生しなくなるはずです。

6. ブートストラップノードコンテナーからログを収集します。

   1. ブートストラップノードで podman を使用してログを収集します。<bootstrap_fqdn> をブートストラップノードの完全修飾ドメイン名に置き換えます。

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

7. ブートストラッププロセスに失敗した場合は、以下を確認します。

   • インストールホストから api.<cluster_name>.<base_domain> を解決できます。
   • ロードバランサーはブートストラップおよびコントロールプレーンノードへのポート 6443 接続をプロキシーします。プロキシー設定が OpenShift Container Platform のインストール要件を満たしていることを確認します。

手順

1. コントロールプレーンノードのコンソールにアクセスできる場合は、ノードがログインプロンプトに到達するまでコンソールを監視します。インストール時に、Ignition ログメッセージはコンソールに出力されます。

2. Ignition ファイル設定を確認します。

   • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合。

     1. コントロールプレーンノードの Ignition ファイル URL を確認します。<http_server_fqdn> を HTTP サーバーの完全修飾ドメイン名に置き換えます。

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        -I オプションはヘッダーのみを返します。Ignition ファイルが指定された URL で利用可能な場合、コマンドは 200 OK ステータスを返します。これが利用できない場合は、コマンドは 404 file not found を返します。

     2. Ignition ファイルがコントロールプレーンノードで受信されたことを確認するには、提供側ホストの HTTP サーバーログをクエリーします。たとえば、Apache Web サーバーを使用して Ignition ファイルを提供する場合は、以下を考慮してください。

        $ grep -is 'master.ign' /var/log/httpd/access_log

        マスター Ignition ファイルが受信される場合、関連付けられた HTTP GET ログメッセージには要求が成功したことを示す 200 OK の成功ステータスが含まれます。

     3. Ignition ファイルが受信されなかった場合、これが提供側ホストに存在することを直接確認します。適切なファイルおよび Web サーバーのパーミッションが適用されていることを確認します。

   • クラウドプロバイダーのメカニズムを使用して Ignition 設定ファイルを初期デプロイメントの一部としてホストに挿入する場合。

     1. コントロールプレーンノードのコンソールを確認し、コントロールプレーンノードの Ignition ファイルを正しく挿入するメカニズムが機能しているかどうかを確認します。
3. コントロールプレーンノードに割り当てられたストレージデバイスの可用性を確認します。
4. コントロールプレーンノードに DHCP サーバーから IP アドレスが割り当てられていることを確認します。

5. コントロールプレーンノードのステータスを判別します。

   1. コントロールプレーンノードのステータスをクエリーします。

      $ oc get nodes

   2. コントロールプレーンノードのいずれかが Ready ステータスに達していない場合は、詳細なノードの説明を取得します。

      $ oc describe node <master_node>

      注記

      インストールの問題により OpenShift Container Platform API が実行できなくなったり、kubelet が各ノードでまだ実行されていない場合、oc コマンドを実行することはできません。

6. OpenShift Container Platform SDN のステータスを判別します。

   1. openshift-sdn namespace で、sdn-controller、sdn、および ovs デーモンセットのステータスを確認します。

      $ oc get daemonsets -n openshift-sdn

   2. これらのリソースが Not found として一覧表示されている場合には、openshift-sdn namespace の Pod を確認します。

      $ oc get pods -n openshift-sdn

   3. openshift-sdn namespace で失敗した OpenShift Container Platform SDN Pod に関連するログを確認します。

      $ oc logs <sdn_pod> -n openshift-sdn

7. クラスターのネットワーク設定のステータスを確認します。

   1. クラスターのネットワーク設定が存在するかどうかを確認します。

      $ oc get network.config.openshift.io cluster -o yaml

   2. インストーラーがネットワーク設定の作成に失敗した場合、Kubernetes マニフェストを再度生成し、メッセージの出力を確認します。

      $ ./openshift-install create manifests

   3. openshift-network-operator namespace で Pod のステータスを確認し、Cluster Network Operator (CNO) が実行されているかどうかを判別します。

      $ oc get pods -n openshift-network-operator

   4. openshift-network-operator namespace からネットワーク Operator Pod ログを収集します。

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. 起動後のコントロールプレーンノードで kubelet.service journald ユニットログを監視します。これにより、コントロールプレーンノードエージェントのアクティビティーを可視化できます。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=master -u kubelet

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

9. 起動後のコントロールプレーンノードで crio.service journald ユニットログを取得します。これにより、コントロールプレーンノードの CRI-O コンテナーランタイムのアクティビティーを可視化できます。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=master -u crio

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

10. コントロールプレーンノードの /var/log/ の下にある特定のサブディレクトリーからログを収集します。

    1. /var/log/ サブディレクトリー内に含まれるログの一覧を取得します。以下の例では、すべてのコントロールプレーンノードの /var/log/openshift-apiserver/ にあるファイルを一覧表示します。

       $ oc adm node-logs --role=master --path=openshift-apiserver

    2. /var/log/ サブディレクトリー内の特定ログを確認します。以下の例は、すべてのコントロールプレーンノードから /var/log/openshift-apiserver/audit.log コンテンツを出力します。

       $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

    3. API が機能しない場合は、代わりに SSH を使用して各ノードのログを確認します。以下の例は、/var/log/openshift-apiserver/audit.log をベースとしています。

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

11. SSH を使用してコントロールプレーンノードのコンテナーログを確認します。

    1. コンテナーを一覧表示します。

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

    2. crictl を使用してコンテナーのログを取得します。

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

12. コントロールプレーンノードの設定に問題がある場合には、MCO、MCO エンドポイント、および DNS レコードが機能していることを確認します。Machine Config Operator (MCO) は、インストール時にオペレーティングシステムの設定を管理します。システムクロックの精度と証明書の有効性も確認します。

    1. MCO エンドポイントが利用可能かどうかをテストします。<cluster_name> を適切な値に置き換えます。

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. エンドポイントが応答しない場合は、ロードバランサーの設定を確認します。エンドポイントがポート 22623 で実行されるよう設定されていることを確認します。

    3. MCO エンドポイントの DNS レコードが設定され、ロードバランサーに対して解決していることを確認します。

       1. 定義された MCO エンドポイント名の DNS ルックアップを実行します。

          $ dig api-int.<cluster_name> @<dns_server>

       2. ロードバランサーの割り当てられた MCO IP アドレスに対して逆引き参照を実行します。

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. MCO がブートストラップノードから直接機能していることを確認します。<bootstrap_fqdn> をブートストラップノードの完全修飾ドメイン名に置き換えます。

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. システムクロックは、ブートストラップ、マスター、およびワーカーノード間で同期される必要があります。各ノードのシステムクロックの参照時間と時刻同期の統計を確認します。

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 証明書の有効性を確認します。

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

手順

1. etcd Pod のステータスを確認します。

   1. openshift-etcd namespace の Pod のステータスを確認します。

      $ oc get pods -n openshift-etcd

   2. openshift-etcd-operator namespace の Pod のステータスを確認します。

      $ oc get pods -n openshift-etcd-operator

2. 直前のコマンドで一覧表示される Pod のいずれかに Running または Completed ステータスが表示されない場合は、Pod の診断情報を収集します。

   1. Pod のイベントを確認します。

      $ oc describe pod/<pod_name> -n <namespace>

   2. Pod のログを検査します。

      $ oc logs pod/<pod_name> -n <namespace>

   3. Pod に複数のコンテナーがある場合、前述のコマンドでエラーが作成され、コンテナー名はエラーメッセージに指定されます。各コンテナーのログを検査します。

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>

3. API が機能しない場合には、代わりに SSH を使用して各コントロールプレーンノードで etcd Pod およびコンテナーログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

   1. 各コントロールプレーンノードに etcd Pod を一覧表示します。

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

   2. Ready ステータスが表示されない Pod について、Pod のステータスの詳細を検査します。<pod_id> を前述のコマンドの出力に一覧表示されている Pod の ID に置き換えます。

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

   3. Pod に関連するコンテナーを一覧表示します。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

   4. Ready ステータスが表示されていないコンテナーの場合は、コンテナーのステータスの詳細を検査します。<container_id> を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。

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

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

4. コントロールプレーンノードからプライマリーおよびセカンダリー DNS サーバー接続を検証します。

手順

1. API サーバーの DNS レコードがコントロールプレーンノードの kubelet を https://api-int.<cluster_name>.<base_domain>:6443 にダイレクトすることを確認します。レコードがロードバランサーを参照することを確認します。
2. ロードバランサーのポート 6443 定義が各コントロールプレーンノードを参照することを確認します。
3. DHCP によって固有のコントロールプレーンノードのホスト名が指定されていることを確認します。

4. 各コントロールプレーンノードで kubelet.service journald ユニットログを検査します。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=master -u kubelet

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

5. コントロールプレーンノードの kubelet ログで証明書の有効期限のメッセージの有無を確認します。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

手順

1. ワーカーノードのコンソールにアクセスできる場合は、ノードがログインプロンプトに到達するまでコンソールを監視します。インストール時に、Ignition ログメッセージはコンソールに出力されます。

2. Ignition ファイル設定を確認します。

   • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合。

     1. ワーカーノードの Ignition ファイル URL を確認します。<http_server_fqdn> を HTTP サーバーの完全修飾ドメイン名に置き換えます。

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        -I オプションはヘッダーのみを返します。Ignition ファイルが指定された URL で利用可能な場合、コマンドは 200 OK ステータスを返します。これが利用できない場合は、コマンドは 404 file not found を返します。

     2. Ignition ファイルがワーカーノードで受信されたことを確認するには、HTTP ホストの HTTP サーバーログをクエリーします。たとえば、Apache Web サーバーを使用して Ignition ファイルを提供する場合は、以下を考慮してください。

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        ワーカー Ignition ファイルが受信される場合、関連付けられた HTTP GET ログメッセージには要求が成功したことを示す 200 OK の成功ステータスが含まれます。

     3. Ignition ファイルが受信されなかった場合、これが提供側ホストに存在することを直接確認します。適切なファイルおよび Web サーバーのパーミッションが適用されていることを確認します。

   • クラウドプロバイダーのメカニズムを使用して Ignition 設定ファイルを初期デプロイメントの一部としてホストに挿入する場合。

     1. ワーカーノードのコンソールを確認し、ワーカーノードの Ignition ファイルを正しく挿入するメカニズムが機能しているかどうかを確認します。
3. ワーカーノードの割り当てられたストレージデバイスの可用性を確認します。
4. ワーカーノードに DHCP サーバーから IP アドレスが割り当てられていることを確認します。

5. ワーカーノードのステータスを判別します。

   1. ノードのステータスをクエリーします。

      $ oc get nodes

   2. Ready ステータスが表示されないワーカーノードの詳細なノードの説明を取得します。

      $ oc describe node <worker_node>

      注記

      インストールの問題により OpenShift Container Platform API が実行できなくなったり、kubelet が各ノードでまだ実行されていない場合、oc コマンドを実行することはできません。

6. コントロールプレーンノード (別名マスターノード) とは異なり、ワーカーノードは Machine API Operator を使用してデプロイされ、スケーリングされます。Machine API Operator のステータスを確認します。

   1. Machine API Operator Pod のステータスを確認します。

      $ oc get pods -n openshift-machine-api

   2. Machine API Operator Pod のステータスが Ready ではない場合は、Pod のイベントを詳細に作成します。

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. machine-api-operator コンテナーログを検査します。コンテナーは machine-api-operator Pod 内で実行されます。

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. また、kube-rbac-proxy コンテナーログも検査します。コンテナーは machine-api-operator Pod 内でも実行されます。

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. kubelet.service journald ユニットログを、起動後のワーカーノードでモニターします。これにより、ワーカーノードエージェントのアクティビティーを可視化できます。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=worker -u kubelet

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。<worker-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

8. 起動後のワーカーノードで crio.service journald ユニットログを取得します。これにより、ワーカーノードの CRI-O コンテナーランタイムのアクティビティーを可視化できます。

   1. oc を使用してログを取得します。

      $ oc adm node-logs --role=worker -u crio

   2. API が機能しない場合は、代わりに SSH を使用してログを確認します。

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

9. ワーカーノードの /var/log/ の下にある特定のサブディレクトリーからログを収集します。

   1. /var/log/ サブディレクトリー内に含まれるログの一覧を取得します。以下の例は、すべてのワーカーノードの /var/log/sssd/ にあるファイルを一覧表示します。

      $ oc adm node-logs --role=worker --path=sssd

   2. /var/log/ サブディレクトリー内の特定ログを確認します。以下の例では、すべてのワーカーノードから /var/log/sssd/audit.log コンテンツを出力します。

      $ oc adm node-logs --role=worker --path=sssd/sssd.log

   3. API が機能しない場合は、代わりに SSH を使用して各ノードのログを確認します。以下の例は、/var/log/sssd/sssd.log をベースとしています。

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. SSH を使用してワーカーノードのコンテナーログを確認します。

    1. コンテナーを一覧表示します。

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. crictl を使用してコンテナーのログを取得します。

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

11. ワーカーノードの設定に問題がある場合には、MCO、MCO エンドポイント、および DNS レコードが機能していることを確認します。Machine Config Operator (MCO) は、インストール時にオペレーティングシステムの設定を管理します。システムクロックの精度と証明書の有効性も確認します。

    1. MCO エンドポイントが利用可能かどうかをテストします。<cluster_name> を適切な値に置き換えます。

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. エンドポイントが応答しない場合は、ロードバランサーの設定を確認します。エンドポイントがポート 22623 で実行されるよう設定されていることを確認します。

    3. MCO エンドポイントの DNS レコードが設定され、ロードバランサーに対して解決していることを確認します。

       1. 定義された MCO エンドポイント名の DNS ルックアップを実行します。

          $ dig api-int.<cluster_name> @<dns_server>

       2. ロードバランサーの割り当てられた MCO IP アドレスに対して逆引き参照を実行します。

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. MCO がブートストラップノードから直接機能していることを確認します。<bootstrap_fqdn> をブートストラップノードの完全修飾ドメイン名に置き換えます。

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. システムクロックは、ブートストラップ、マスター、およびワーカーノード間で同期される必要があります。各ノードのシステムクロックの参照時間と時刻同期の統計を確認します。

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 証明書の有効性を確認します。

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

手順

1. クラスター Operator がすべてインストールの終わりに利用可能な状態であることを確認します。

   $ oc get clusteroperators

2. 必要な証明書署名要求 (CSR) がすべて承認されていることを確認します。一部のノードは Ready ステータスには移行さず、一部のクラスター Operator は保留中の CSR がある場合に利用できない可能性があります。

   1. CSR のステータスを確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

      $ oc get csr

      出力例

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      クライアント要求の CSR。

      2

      サーバー要求の CSR。

      この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

   2. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

      注記

      CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。

      注記

      ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、 oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

      • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name> は、現行の CSR の一覧からの CSR の名前です。

      • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. Operator イベントを表示します。

   $ oc describe clusteroperator <operator_name>

4. Operator の namespace 内で Operator Pod のステータスを確認します。

   $ oc get pods -n <operator_namespace>

5. Running ステータスを持たない Pod についての詳細な説明を取得します。

   $ oc describe pod/<operator_pod_name> -n <operator_namespace>

6. Pod ログを検査します。

   $ oc logs pod/<operator_pod_name> -n <operator_namespace>

7. Pod ベースイメージに関連する問題が発生した場合には、ベースイメージのステータスを確認します。

   1. 問題のある Pod で使用されるベースイメージの詳細を取得します。

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>

   2. ベースイメージのリリース情報を一覧表示します。

      $ oc adm release info <image_path>:<tag> --commits

手順

1. ブートストラップおよびコントロールプレーンマシンからインストールログを収集するために必要なコマンドを生成します。

   • インストーラーでプロビジョニングされたインフラストラクチャーを使用する場合は、インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

     $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory は、./openshift-install create cluster を実行した際に指定したディレクトリーです。このディレクトリーには、インストールプログラムが作成する OpenShift Container Platform 定義ファイルが含まれます。

     インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムは、ホスト名または IP アドレスを指定しなくてもよいようにクラスターについての情報を保存します。

   • 各自でプロビジョニングしたインフラストラクチャーを使用した場合は、インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address>" 5

     1

     installation_directory には、./openshift-install create cluster を実行した際に指定したのと同じディレクトリーを指定します。このディレクトリーには、インストールプログラムが作成する OpenShift Container Platform 定義ファイルが含まれます。

     2

     <bootstrap_address> は、クラスターのブートストラップマシンの完全修飾ドメイン名または IP アドレスです。

     3 4 5

     クラスター内のそれぞれのコントロールプレーン (またはマスター) マシンについては、<master_*_address> をその完全修飾ドメイン名または IP アドレスに置き換えます。

     注記

     デフォルトクラスターには 3 つのコントロールプレーンマシンが含まれます。クラスターが使用する数にかかわらず、表示されるようにすべてのコントロールプレーンマシンを一覧表示します。

   出力例

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   インストールの失敗についての Red Hat サポートケースを作成する場合は、圧縮したログをケースに含めるようにしてください。

手順

1. kubelet は各ノードの systemd サービスを使用して管理されます。デバッグ Pod 内で kubelet systemd サービスをクエリーし、kubelet のステータスを確認します。

   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 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. kubelet systemd サービスがノードでアクティブかどうかを確認します。

      # systemctl is-active kubelet

   4. より詳細な kubelet.service ステータスの要約を出力します。

      # systemctl status kubelet

手順

1. OpenShift Container Platform クラスターノードから kubelet の journald ユニットログをクエリーします。以下の例では、コントロールプレーンノード (別名マスターノード) のみをクエリーします。

   $ oc adm node-logs --role=master -u kubelet  1

   1

   他のユニットログをクエリーするために、kubelet を適宜置き換えます。

2. クラスターノードの /var/log/ の下にある特定のサブディレクトリーからログを収集します。

   1. /var/log/ サブディレクトリー内に含まれるログの一覧を取得します。以下の例では、すべてのコントロールプレーンノードの /var/log/openshift-apiserver/ にあるファイルを一覧表示します。

      $ oc adm node-logs --role=master --path=openshift-apiserver

   2. /var/log/ サブディレクトリー内の特定ログを確認します。以下の例は、すべてのコントロールプレーンノードから /var/log/openshift-apiserver/audit.log コンテンツを出力します。

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

   3. API が機能しない場合は、代わりに SSH を使用して各ノードのログを確認します。以下の例は、/var/log/openshift-apiserver/audit.log をベースとしています。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

手順

1. デバッグ Pod 内で、ノードの crio systemd サービスをクエリーして CRI-O ステータスを確認します。

   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.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. crio systemd サービスがノードでアクティブかどうかを確認します。

      # systemctl is-active crio

   4. より詳細な crio.service ステータスの要約を出力します。

      # systemctl status crio.service

手順

1. CRI-O journald ユニットログを収集します。以下の例は、クラスター内のすべてのコントロールプレーンノードからログを収集します。

   $ oc adm node-logs --role=master -u crio

2. 特定のノードから CRI-O journald ユニットログを収集します。

   $ oc adm node-logs <node_name> -u crio

3. API が機能しない場合は、代わりに SSH を使用してログを確認します。<node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   注記

   Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

手順

1. ノードで cordon を使用します。これは、ノードが Ready 状態になった場合に、ワークロードがスケジューリングされるのを防ぐためです。Status セクションに SchedulingDisabled と表示されていれば、スケジューリングが無効になっていることがわかります。

   $ oc adm cordon <nodename>

2. cluster-admin ユーザーとして、ノードをドレインします。

   $ oc adm drain <nodename> --ignore-daemonsets --delete-local-data

   注記

   Pod または Pod テンプレートの terminateGracePeriodSeconds 属性は、正常な終了期間を制御します。この属性のデフォルトは 30 秒ですが、必要に応じてアプリケーションごとにカスタマイズできます。90 秒を超えて設定すると、Pod が SIGKILLed とマークされ、正常に終了しない可能性があります。

3. ノードが戻ってきたら、SSH またはコンソールでノードに接続し直します。その後、root ユーザーで接続します。

   $ ssh core@node1.example.com
   $ sudo -i

4. kubelet を手動で停止します。

   # systemctl stop kubelet

5. コンテナーや Pod を停止します。

   # crictl rmp -fa

6. crio のサービスを手動で停止します。

   # systemctl stop crio

7. これらのコマンドを実行すると、一時ストレージを完全に消去することができます。

   # crio wipe -f

8. crio および kubelet サービスを起動します。

   # systemctl start crio
   # systemctl start kubelet

9. crio および kubelet サービスが起動しており、ノードが Ready のステータスになっている場合には、クリーンアップが正常に機能したことが分かります。

   $ oc get nodes

   出力例

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.22.0-rc.0+75ee307

10. ノードをスケジューリング可能な状態にします。スケジューリングが有効になったことは、SchedulingDisabled のステータスがなくなったときにわかります。

    $ oc adm uncordon <nodename>

    出力例

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.22.0-rc.0+75ee307

手順

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 になります。

   出力例

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

手順

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
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   前述の出力例では、最後に観測された状態が TRANSIENT_FAILURE となっています。この状態は、カタログソースの接続確立に問題があることを示しています。

3. カタログソースが作成された namespace の Pod をリストアップします。

   $ oc get pods -n openshift-marketplace

   出力例

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

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

4. oc describe コマンドを使用して、より詳細な情報を得るために Pod を検査します。

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   出力例

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

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

手順

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

   $ oc get clusteroperators

2. Operator の namespace で実行されている Operator Pod を一覧表示し、Pod のステータス、再起動、および経過時間を一覧表示します。

   $ oc get pod -n <operator_namespace>

3. 詳細な Operator Pod の要約を出力します。

   $ oc describe pod <operator_pod_name> -n <operator_namespace>

4. Operator の問題がノード固有の問題である場合、そのノードで Operator コンテナーのステータスをクエリーします。

   1. ノードのデバッグ Pod を起動します。

      $ oc debug node/my-node

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

      # chroot /host

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. 状態および関連付けられた Pod ID を含む、ノードのコンテナーについての詳細を一覧表示します。

      # crictl ps

   4. ノード上の特定の Operator コンテナーについての情報を一覧表示します。以下の例では、network-operator コンテナーに関する情報を一覧表示します。

      # crictl ps --name network-operator

   5. デバッグシェルを終了します。

手順

1. Operator の namespace で実行されている Operator Pod、Pod のステータス、再起動、および経過時間を一覧表示します。

   $ oc get pods -n <operator_namespace>

2. Operator Pod のログを確認します。

   $ oc logs pod/<pod_name> -n <operator_namespace>

   Operator Pod に複数のコンテナーがある場合、前述のコマンドにより各コンテナーの名前が含まれるエラーが生成されます。個別のコンテナーからログをクエリーします。

   $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>

3. API が機能しない場合には、代わりに SSH を使用して各コントロールプレーンノードで Operator Pod およびコンテナーログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

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

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

   2. Operator Pod で Ready ステータスが表示されない場合は、Pod のステータスを詳細に検査します。<operator_pod_id> を直前のコマンドの出力に一覧表示されている Operator Pod の ID に置き換えます。

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

   3. Operator Pod に関連するコンテナーを一覧表示します。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

   4. Ready ステータスが Operator コンテナーに表示されない場合は、コンテナーのステータスを詳細に検査します。<container_id> を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。

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

   5. Ready ステータスが表示されない Operator コンテナーのログを確認します。<container_id> を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

手順

1. Operator がインストールされている namespace から Subscription および ClusterServiceVersion オブジェクトの名前を取得します。

   $ oc get sub,csv -n <namespace>

   出力例

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

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

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

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

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

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

   $ oc get job,configmap -n openshift-marketplace

   出力例

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. ジョブを削除します。

   $ oc delete job <job_name> -n openshift-marketplace

   これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。

6. 設定マップを削除します。

   $ oc delete configmap <configmap_name> -n openshift-marketplace

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

手順

1. プロジェクトに切り替えます。

   $ oc project <project_name>

2. namespace 内で実行されている Pod、Pod のステータス、エラーの状態、再起動、および経過時間を一覧表示します。

   $ oc get pods

3. namespace がデプロイメント設定で管理されているかどうかを判別します。

   $ oc status

   namespace がデプロイメント設定で管理される場合、出力には、デプロイメント設定名とベースイメージの参照が含まれます。

4. 前述のコマンドの出力で参照されているベースイメージを検査します。

   $ skopeo inspect docker://<image_reference>

5. ベースイメージの参照が正しくない場合は、デプロイメント設定の参照を更新します。

   $ oc edit deployment/my-deployment

6. デプロイメント設定が終了時に変更されると、設定が自動的に再デプロイされます。デプロイメントの進行中に Pod ステータスを確認し、問題が解決されているかどうかを判別します。

   $ oc get pods -w

7. Pod の失敗に関連する診断情報については、namespace 内でイベントを確認します。

   $ oc get events

手順

1. 特定の Pod のログをクエリーします。

   $ oc logs <pod_name>

2. Pod 内の特定コンテナーのログをクエリーします。

   $ oc logs <pod_name> -c <container_name>

   前述の oc logs コマンドを使用して取得されるログは、Pod またはコンテナー内の標準出力 (stdout) に送信されるメッセージで設定されます。

3. Pod 内の /var/log/ に含まれるログを検査します。

   1. Pod 内の /var/log に含まれるファイルおよびサブディレクトリーを一覧表示します。

      $ oc exec <pod_name> ls -alh /var/log

   2. Pod 内の /var/log に含まれる特定のログファイルをクエリーします。

      $ oc exec <pod_name> cat /var/log/<path_to_log>

   3. 特定のコンテナー内の /var/log に含まれるログファイルおよびサブディレクトリーを一覧表示します。

      $ oc exec <pod_name> -c <container_name> ls /var/log

   4. 特定のコンテナー内の /var/log に含まれる特定のログファイルをクエリーします。

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>

手順

1. アクセスする Pod が含まれるプロジェクトに切り替えます。これは、oc rsh コマンドが -n namespace オプションを受け入れないために必要です。

   $ oc project <namespace>

2. リモートシェルを Pod で起動します。

   $ oc rsh <pod_name>  1

   1

   Pod に複数のコンテナーがある場合、oc rsh は -c <container_name> が指定されていない限り最初のコンテナーにデフォルト設定されます。

3. Pod 内の特定のコンテナーでリモートシェルを起動します。

   $ oc rsh -c <container_name> pod/<pod_name>

4. Pod のポートへのポート転送セッションを作成します。

   $ oc port-forward <pod_name> <host_port>:<pod_port>  1

   1

   ポート転送セッションをキャンセルするには、Ctrl+C を入力します。

手順

1. デプロイメントに基づいて、root アクセスでデバッグ Pod を起動します。

   1. プロジェクトのデプロイメント名を取得します。

      $ oc get deployment -n <project_name>

   2. デプロイメントに基づいて、root 権限でデバッグ Pod を起動します。

      $ oc debug deployment/my-deployment --as-root -n <project_name>

2. デプロイメント設定に基づいて、root アクセスでデバッグ Pod を起動します。

   1. プロジェクトのデプロイメント設定名を取得します。

      $ oc get deploymentconfigs -n <project_name>

   2. デプロイメント設定に基づいて、root 権限でデバッグ Pod を起動します。

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>

手順

1. ファイルを Pod にコピーします。

   $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1

   1

   -c オプションが指定されていない場合、Pod の最初のコンテナーが選択されます。

2. Pod からファイルをコピーします。

   $ oc cp <pod_name>:/<path>  -c <container_name><local_path>  1

   1

   -c オプションが指定されていない場合、Pod の最初のコンテナーが選択されます。

   注記

   oc cp が機能するには、tar バイナリーがコンテナー内で利用可能である必要があります。

1. ビルド設定の段階 で、ビルド Pod はベースイメージおよびアプリケーションのソースコードからアプリケーションコンテナーイメージを作成するために使用されます。
2. デプロイメント設定の段階 で、デプロイメント Pod はビルド設定段階でビルドされたアプリケーションコンテナーイメージからアプリケーション Pod をデプロイするために使用されます。デプロイメント Pod は、サービスやルートなどの他のリソースもデプロイします。デプロイメント設定は、ビルド設定が成功すると開始されます。
3. デプロイメント Pod のアプリケーション Pod の起動後 に、アプリケーションの障害が実行中のアプリケーション Pod 内で発生する可能性があります。たとえば、アプリケーション Pod が Running 状態であっても、アプリケーションは予想通りに動作しない可能性があります。このシナリオでは、実行中のアプリケーション Pod にアクセスして、Pod 内のアプリケーションの障害を調査できます。

1. ビルド、デプロイメント、およびアプリケーション Pod ステータスの監視
2. 問題が発生した S2I プロセスのステージの判別
3. 失敗したステージに対応するログの確認

手順

1. S2I プロセス全体での Pod のステータスを確認し、障害が発生するステージを判別します。

   $ oc get pods -w  1

   1

   -w を使用して、Ctrl+C を使用してコマンドを終了するまで Pod で変更の有無を監視します。

2. 障害のある Pod のログでエラーの有無を確認します。

   • ビルド Pod が失敗する場合、ビルド Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-build

     注記

     または、oc logs -f bc/<application_name> を使用して、ビルド設定のログを確認できます。ビルド設定のログには、ビルド Pod からのログが含まれます。

   • デプロイメント Pod が失敗する場合、デプロイメント Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     注記

     または、oc logs -f dc/<application_name> を使用して、デプロイメント設定のログを確認できます。これにより、デプロイメント Pod が正常に実行されるまで、デプロイメント Pod からログが出力されます。デプロイメント Pod の完了後に実行すると、コマンドはアプリケーション Pod からログを出力します。デプロイメント Pod の完了後も、oc logs -f pod/<application_name>-<build_number>-deploy を実行してログにアクセスできます。

   • アプリケーション Pod が失敗した場合や、アプリケーションが実行中のアプリケーション Pod 内で予想通りに動作しない場合、アプリケーション Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

手順

1. 特定のアプリケーション Pod に関連するイベントを一覧表示します。以下の例では、my-app-1-akdlg という名前のアプリケーション Pod のイベントを取得します。

   $ oc describe pod/my-app-1-akdlg

2. アプリケーション Pod からのログを確認します。

   $ oc logs -f pod/my-app-1-akdlg

3. 実行中のアプリケーション Pod 内で特定のログをクエリーします。標準出力 (stdout) に送信されるログは OpenShift Container Platform のロギングフレームワークによって収集され、これは前述のコマンドの出力に含まれます。以下のクエリーは、標準出力 (stdout) に送信されないログにのみ必要です。

   1. Pod 内で root 権限なしにアプリケーションログにアクセスできる場合は、以下のようにログファイルを連結します。

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

   2. アプリケーションログの表示に root アクセスが必要な場合は、root 権限でデバッグコンテナーを起動し、コンテナー内でログファイルを表示できます。プロジェクトの DeploymentConfig オブジェクトからデバッグコンテナーを起動します。通常、Pod ユーザーは root 以外の権限で実行しますが、問題を調査するために一時的な root 権限で Pod のトラブルシューティングを実行することは役に立ちます。

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      注記

      oc debug dc/<deployment_configuration> --as-root を -- <command> を追加せずに実行する場合、デバッグ Pod 内で root アクセスでインタラクティブなシェルにアクセスできます。

4. インタラクティブなシェルでアプリケーション機能を対話的にテストし、アプリケーションコンテナーで診断ツールを実行します。

   1. アプリケーションコンテナーでインタラクティブなシェルを起動します。

      $ oc exec -it my-app-1-akdlg /bin/bash

   2. シェルからアプリケーションの機能を対話的にテストします。たとえば、コンテナーのエントリーポイントコマンドを実行して、結果を確認することができます。次に、ソースコードを更新し、S2I プロセスでアプリケーションコンテナーを再ビルドする前に、コマンドラインから直接に変更をテストします。

   3. コンテナー内で利用可能な診断バイナリーを実行します。

      注記

      一部の診断バイナリーを実行するには、root 権限が必要です。このような状況では、oc debug dc/<deployment_configuration> --as-root を実行して、問題のある Pod の DeploymentConfig オブジェクトに基づいて、root 権限でデバッグ Pod を起動できます。次に、デバッグ Pod 内から診断バイナリーを root として実行できます。

5. 診断バイナリーがコンテナー内で利用できない場合は、nsenter を使用して、コンテナーの namespace 内でホストの診断バイナリーを実行できます。以下の例では、ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。

   1. ターゲットノードのデバッグセッションに入ります。この手順は、<node_name>-debug というデバッグ Pod をインスタンス化します。

      $ oc debug node/my-cluster-node

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

      # chroot /host

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.6 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. ターゲットコンテナー ID を判別します。

      # crictl ps

   4. コンテナーのプロセス ID を確認します。この例では、ターゲットコンテナー ID は a7fe32346b120 です。

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。この例では、31150 をコンテナーのプロセス ID として使用します。nsenter コマンドは、ターゲットプロセスの namespace を入力し、その namespace でコマンドを実行します。この例のターゲットプロセスはコンテナーのプロセス ID であるため、ip ad コマンドは、ホストからコンテナーの namespace で実行されます。

      # nsenter -n -t 31150 -- ip ad

      注記

      デバッグノードなどの特権付きコンテナーを使用している場合のみ、コンテナーの namespace 内でホストの診断バイナリーを実行できます。

手順

1. C:\var\logs のすべてのディレクトリー下でログを表示するには、以下のコマンドを実行します。

   $ oc adm node-logs -l kubernetes.io/os=windows --path= \
       /ip-10-0-138-252.us-east-2.compute.internal containers \
       /ip-10-0-138-252.us-east-2.compute.internal hybrid-overlay \
       /ip-10-0-138-252.us-east-2.compute.internal kube-proxy \
       /ip-10-0-138-252.us-east-2.compute.internal kubelet \
       /ip-10-0-138-252.us-east-2.compute.internal pods

2. 同じコマンドを使用してディレクトリー内のファイルを一覧表示し、個別のログファイルを表示できるようになりました。たとえば、kubelet ログを表示するには、以下のコマンドを実行します。

   $ oc adm node-logs -l kubernetes.io/os=windows --path=/kubelet/kubelet.log

手順

1. Windows ノードに SSH を実行し、PowerShell と入力します。

   C:\> powershell

2. 以下のコマンドを実行して Docker ログを表示します。

   C:\> Get-EventLog -LogName Application -Source Docker

手順

1. サービスおよび ServiceMonitor リソース設定で、対応するラベルの一致を確認 します。

   1. サービスに定義されたラベルを取得します。以下の例では、ns1 プロジェクトの prometheus-example-app サービスをクエリーします。

      $ oc -n ns1 get service prometheus-example-app -o yaml

      出力例

        labels:
          app: prometheus-example-app

   2. ServiceMonitor リソース設定の matchLabels app ラベルが直前のステップのラベルの出力と一致することを確認します。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      出力例

      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      注記

      プロジェクトの表示パーミッションを持つ開発者として、サービスおよび ServiceMonitor リソースラベルを確認できます。

2. openshift-user-workload-monitoring プロジェクトの Prometheus Operator のログを検査します。

   1. openshift-user-workload-monitoring プロジェクトの Pod を一覧表示します。

      $ oc -n openshift-user-workload-monitoring get pods

      出力例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. prometheus-operator Pod の prometheus-operator コンテナーからログを取得します。以下の例では、Pod は prometheus-operator-776fcbbd56-2nbfm になります。

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      サービスモニターに問題がある場合、ログには以下のようなエラーが含まれる可能性があります。

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. Prometheus UI でプロジェクトのターゲットステータスを直接確認します。

   1. openshift-user-workload-monitoring プロジェクトで Prometheus インスタンスへのポート転送を確立します。

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090

   2. Web ブラウザーで http://localhost:9090/targets を開き、 Prometheus UI でプロジェクトのターゲットのステータスを直接確認します。ターゲットに関連するエラーメッセージがあるかどうかを確認します。

4. openshift-user-workload-monitoring プロジェクトで Prometheus Operator のデバッグレベルのロギングを設定 します。

   1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. prometheusOperator の logLevel: debug を data/config.yaml に追加し、ログレベルを debug に設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug

   3. 変更を適用するためにファイルを保存します。

      注記

      openshift-user-workload-monitoring プロジェクトの prometheus-operator は、ログレベルの変更時に自動的に再起動します。

   4. debug ログレベルが openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントに適用されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      出力例

              - --log-level=debug

      debug レベルのロギングにより、Prometheus Operator によって行われるすべての呼び出しが表示されます。

   5. prometheus-operator Pod が実行されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get pods

      注記

      認識されない Prometheus Operator の loglevel 値が設定マップに含まれる場合、prometheus-operator Pod が正常に再起動されない可能性があります。

   6. デバッグログを確認し、Prometheus Operator が ServiceMonitor リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。

手順

1. Administrator パースペクティブで、Monitoring → Metrics に移動します。

2. Expression フィールドで、以下の Prometheus Query Language (PromQL) クエリーを実行します。これにより、収集サンプルの数が最も多い 10 メトリクスが返されます。

   topk(10,count by (job)({__name__=~".+"}))

3. 予想されるよりも多くの収集サンプルを持つメトリクスに割り当てられたバインドされていないラベル値の数を調査します。

   • メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
   • メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。

4. Prometheus UI で TSDB ステータスを確認します。

   1. Administrator パースペクティブで、Networking → Routes に移動します。
   2. Project: 一覧で openshift-monitoring プロジェクトを選択します。
   3. prometheus-k8s 行の URL を選択し、Prometheus UI のログインページを開きます。
   4. Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。
   5. Prometheus UI で、Status → TSDB Status に移動します。

手順

1. oc コマンドの実行時に oc ログレベルを指定します。

   $ oc <options> --loglevel <log_level>

2. 通常、OpenShift Container Platform ユーザーの現行セッショントークンは、必要に応じてログに記録される curl 要求に含まれます。また、手順に従って oc コマンドの基礎となるプロセスをテストする際に使用するために、現行ユーザーのセッショントークンを手動で取得することもできます。

   $ oc whoami -t