第7章 トラブルシューティング

7.1. インストールのトラブルシューティング

7.1.1. インストールの問題が発生する場所の判別

OpenShift Container Platform のインストールの問題のトラブルシューティング時に、インストールログを監視して、問題が発生した段階を判別できます。次に、その段階に関連する診断データを取得します。

OpenShift Container Platform インストールは以下の段階に従って実行されます。

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

7.1.2. ユーザーによってプロビジョニングされるインフラストラクチャーのインストールに関する考慮事項

デフォルトのインストール方法は、インストーラーでプロビジョニングされるインフラストラクチャーです。インストーラーでプロビジョニングされるインフラストラクチャークラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。

OpenShift Container Platform 4.8 はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。このインストール方法を使用する場合は、ユーザーによってプロビジョニングされるインフラストラクチャーのインストールドキュメントに注意深く従ってください。また、インストール前に以下の考慮事項を確認してください。

  • Red Hat Enterprise Linux (RHEL) Ecosystem を確認し、選択したサーバーハードウェアまたは仮想化テクノロジー向けに提供されている Red Hat Enterprise Linux CoreOS (RHCOS) サポートのレベルを判別します。
  • 多くの仮想化環境およびクラウド環境では、ゲストオペレーティングシステムにエージェントをインストールする必要があります。これらのエージェントがデーモンセット経由でデプロイされるコンテナー化されたワークロードとしてインストールされていることを確認します。
  • 動的ストレージ、オンデマンドサービスルーティング、ノードホスト名の Kubernetes ホスト名への解決、クラスターの自動スケーリングなどの機能を有効にする場合は、クラウドプロバイダーの統合をインストールします。

    注記

    異なるクラウドプロバイダーのリソースを組み合わせた OpenShift Container Platform 環境でのクラウドプロバイダーの統合を有効にしたり、複数の物理または仮想プラットフォームにまたがるクラウドプロバイダーの統合を有効にすることはできません。ノードライフサイクルコントローラーでは、既存プロバイダーの外部にあるノードをクラスターに追加することはできず、複数のクラウドプロバイダーの統合を指定することはできません。

  • マシンセットまたは自動スケーリングを使用して OpenShift Container Platform クラスターノードを自動的にプロビジョニングする必要がある場合、プロバイダー固有のマシン API 実装が必要です。
  • 選択したクラウドプロバイダーが、初期デプロイメントの一部として Ignition 設定ファイルをホストに挿入する方法を提供するかどうかを確認します。提供しない場合は、HTTP サーバーを使用して Ignition 設定ファイルをホストする必要があります。Ignition 設定ファイルの問題のトラブルシューティングを行う手順は、これらの 2 つの方法のどちらをデプロイするかによって異なります。
  • 組み込みコンテナーレジストリー、ElasticSearch、Prometheus などのオプションのフレームワークコンポーネントを利用する必要がある場合は、ストレージを手動でプロビジョニングする必要があります。デフォルトのストレージクラスは、明示的に設定されない限り、ユーザーによってプロビジョニングされるインフラストラクチャーのインストールでは定義されません。
  • ロードバランサーは、可用性の高い OpenShift Container Platform 環境にあるすべてのコントロールプレーンノード (別名マスターノード) に API 要求を分散するために必要です。OpenShift Container Platform DNS ルーティングおよびポートの要件を満たす TCP ベースの負荷分散ソリューションを使用できます。

7.1.3. OpenShift Container Platform インストール前のロードバランサー設定の確認

OpenShift Container Platform インストールを開始する前に、ロードバランサーの設定を確認してください。

前提条件

  • OpenShift Container Platform インストールの準備のために、選択した外部ロードバランサーを設定している。以下の例では、HAProxy を使用した Red Hat Enterprise Linux (RHEL) ホストに基づいて、負荷分散サービスをクラスターに提供します。
  • OpenShift Container Platform インストールの準備のために DNS を設定している。
  • ロードバランサーへの SSH アクセスがある。

手順

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

    $ ssh <user_name>@<load_balancer> systemctl status haproxy
  2. ロードバランサーが必要なポートでリッスンしていることを確認します。以下の例では、ポート 804436443、および 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>

7.1.4. OpenShift Container Platform インストーラーのログレベルの指定

デフォルトで、OpenShift Container Platform インストーラーのログレベルは info に設定されます。失敗した OpenShift Container Platform インストールの診断時により詳細なロギングが必要な場合は、再びインストールを開始する際に openshift-install ログレベルを debug に引き上げることができます。

前提条件

  • インストールホストにアクセスできる。

手順

  • インストールを開始する際に、インストールのログレベルを debug に設定します。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete --log-level debug  1
    1
    ログレベルには、infowarnerror、 および debug が含まれます。

7.1.5. openshift-install コマンド関連の問題のトラブルシューティング

openshift-install コマンドの実行に問題がある場合には、以下を確認してください。

  • インストールは Ignition 設定ファイルの作成から 24 時間以内に開始されている。Ignition ファイルは以下のコマンドの実行時に作成されている。

    $ ./openshift-install create ignition-configs --dir=./install_dir
  • install-config.yaml ファイルはインストーラーと同じディレクトリーにある。代替インストールパスが ./openshift-install --dir オプションを使用して宣言される場合、そのディレクトリーに install-config.yaml ファイルが存在することを確認します。

7.1.6. インストールの進捗の監視

OpenShift Container Platform インストールの進捗として、高レベルのインストール、ブートストラップ、およびコントロールプレーンのログをモニターできます。これにより、インストールの進捗をより明確に把握できるようになり、インストールが失敗する段階を特定しやすくなります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ホストへの SSH アクセスがあること。
  • ブートストラップおよびコントロールプレーンノード (別名マスターノード) の完全修飾ドメイン名がある。

    注記

    初期の kubeadmin パスワードは、インストールホストの <install_directory>/auth/kubeadmin-password にあります。

手順

  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

7.1.7. ブートストラップノードの診断データの収集

ブートストラップ関連の問題が発生した場合、ブートストラップノードから bootkube.servicejournald ユニットログおよびコンテナーログを収集できます。

前提条件

  • ブートストラップノードへの SSH アクセスがある。
  • ブートストラップノードの完全修飾ドメイン名がある。
  • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合、HTTP サーバーの完全修飾ドメイン名およびポート番号が必要です。HTTP ホストへの SSH アクセスも必要です。

手順

  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 のインストール要件を満たしていることを確認します。

7.1.8. コントロールプレーンノードのインストールの問題の調査

コントロールプレーンノードのインストールに問題がある場合には、コントロールプレーンノード、OpenShift Container Platform ソフトウェア定義ネットワーク (SDN)、およびネットワーク Operator のステータスを判別します。kubelet.servicecrio.service journald ユニットログ、およびコントロールプレーンノードコンテナーログを収集し、コントロールプレーンノードエージェント、CRI-O コンテナーランタイム、および Pod アクティビティーを可視化します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ホストへの SSH アクセスがあること。
  • ブートストラップおよびコントロールプレーンノードの完全修飾ドメイン名がある。
  • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合、HTTP サーバーの完全修飾ドメイン名およびポート番号が必要です。HTTP ホストへの SSH アクセスも必要です。

    注記

    初期の kubeadmin パスワードは、インストールホストの <install_directory>/auth/kubeadmin-password にあります。

手順

  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-controllersdn、および 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.8 クラスターノードは変更できず、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

7.1.9. etcd インストールの問題の調査

インストール時に etcd の問題が発生した場合には、etcd Pod のステータスを確認し、etcd Pod ログを収集できます。etcd DNS レコードを確認し、コントロールプレーンノード (別名マスターノード) で DNS の可用性を確認することもできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ホストへの SSH アクセスがあること。
  • コントロールプレーンノードの完全修飾ドメイン名がある。

手順

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

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

7.1.10. コントロールプレーンノードの kubelet および API サーバーの問題の調査

インストール時にコントロールプレーンノードの kubelet および API サーバーの問題を調査するには、DNS、DHCP、およびロードバランサーの機能を確認してください。また、証明書の有効期限が切れていないことを確認します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ホストへの SSH アクセスがあること。
  • コントロールプレーンノードの完全修飾ドメイン名がある。

手順

  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.8 クラスターノードは変更できず、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'

7.1.11. ワーカーノードのインストールに関連する問題の調査

ワーカーノードのインストールに問題がある場合には、ワーカーノードのステータスを確認できます。kubelet.servicecrio.service journald ユニットログ、およびワーカーノードコンテナーログを収集し、ワーカーノードエージェント、CRI-O コンテナーランタイム、および Pod アクティビティーを可視化します。さらに、Ignition ファイルおよびマシン API Operator の機能を確認することもできます。ワーカーノードのインストール後の設定が失敗する場合は、Machine Config Operator (MCO) および DNS 機能を確認します。また、ブートストラップ、マスター、およびワーカーノード間のシステムクロックの同期を確認し、証明書を検証することもできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ホストへの SSH アクセスがあること。
  • ブートストラップおよびワーカーノードの完全修飾ドメイン名がある。
  • HTTP サーバーを使用して Ignition 設定ファイルをホストする場合、HTTP サーバーの完全修飾ドメイン名およびポート番号が必要です。HTTP ホストへの SSH アクセスも必要です。

    注記

    初期の kubeadmin パスワードは、インストールホストの <install_directory>/auth/kubeadmin-password にあります。

手順

  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.8 クラスターノードは変更できず、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

7.1.12. インストール後の Operator ステータスのクエリー

インストールの終わりに Operator のステータスを確認できます。利用できない Operator の診断データを取得します。Pending と一覧表示されているか、またはエラーステータスのある Operator Pod のログを確認します。問題のある Pod によって使用されるベースイメージを検証します。

前提条件

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

手順

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

7.1.13. 失敗したインストールのログの収集

SSH キーをインストールプログラムに指定している場合、失敗したインストールについてのデータを収集することができます。

注記

実行中のクラスターからログを収集する場合とは異なるコマンドを使用して失敗したインストールについてのログを収集します。実行中のクラスターからログを収集する必要がある場合は、oc adm must-gather コマンドを使用します。

前提条件

  • OpenShift Container Platform のインストールがブートストラッププロセスの終了前に失敗している。ブートストラップノードは実行中であり、SSH でアクセスできる。
  • ssh-agent プロセスはコンピューター上でアクティブであり、ssh-agent プロセスとインストールプログラムの両方に同じ SSH キーを提供している。
  • 独自にプロビジョニングしたインフラストラクチャーにクラスターのインストールを試行した場合には、ブートストラップおよびコントロールプレーンノード (別名マスターノード) の完全修飾ドメイン名がある。

手順

  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 サポートケースを作成する場合は、圧縮したログをケースに含めるようにしてください。

7.1.14. 追加リソース

  • OpenShift Container Platform のインストールタイプおよびプロセスについての詳細は、「インストールプロセス」を参照してください。