Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第40章 診断ツール

40.1. 概要

oc adm diagnostics コマンドは一連のチェックを実行し、ホストまたはクラスターのエラーの状態についてチェックします。とくに以下を実行します。

  • デフォルトのレジストリーおよびルーターが実行中であり、正しく設定されていることを確認します。
  • ClusterRoleBindings および ClusterRoles で、ベースポリシーとの整合性を確認します。
  • すべてのクライアント設定コンテキストが有効で接続可能であることを確認します。
  • SkyDNS が適切に機能しており、Pod に SDN 接続があることを確認します。
  • ホストのマスターおよびノード設定を検証します。
  • ノードが実行中で、利用可能であることを確認します。
  • 既知のエラーについてホストログを分析します。
  • systemd ユニットがホストに対して予想通りに設定されていることを確認します。

40.2. 診断ツールの使用

OpenShift Container Platform は複数の方法でデプロイできます。それらには以下が含まれます。

  • ソースからのビルド
  • VM イメージ内への組み込み
  • コンテナーイメージとしての使用
  • エンタープライズ RPM の使用

それぞれの方法は設定および環境に応じて適宜使い分けられます。環境についての想定内容を最小限にするために、診断ツールが openshift バイナリーに組み込まれており、OpenShift Container Platform サーバーまたはクライアント内で診断が実行されます。

診断ツールを使用するには (マスターホスト上で使用するのが望ましい)、クラスター管理者として以下を実行します。

# oc adm diagnostics

これは利用可能なすべての診断を実行し、環境に適用されない手順を省略します。

名前別に特定の診断を実行するか、または問題に対応する際に使用する特定の診断を実行することができます。以下は例になります。

$ oc adm diagnostics

診断ツールの各種オプションでは、有効な設定ファイルが必要になります。たとえば、NodeConfigCheck はノード設定が利用可能でない場合は実行されません。

診断ツールは、デフォルトで標準設定ファイルの場所を使用します。

  • クライアント:

    • $KUBECONFIG 環境変数で示される。
    • ~/.kube/config file
  • マスター:

    • /etc/origin/master/master-config.yaml
  • ノード:

    • /etc/origin/node/node-config.yaml

--config, --master-config、および --node-config オプションで標準以外の場所を指定できます。設定ファイルが指定されない場合、関連する診断は省略されます。

利用可能な診断には以下が含まれます。

診断名目的

AggregatedLogging

集約されたログ統合を使用して適切な設定および操作を確認します。

AnalyzeLogs

systemd サービスログで問題の有無を確認します。チェックの実行に設定ファイルは不要です。

ClusterRegistry

クラスターにビルドおよびイメージストリームの作業用のコンテナーイメージレジストリーがあることを確認します。

ClusterRoleBindings

デフォルトのクラスターロールバインディングが存在し、ベースポリシーに応じて予想されるサブジェクトが含まれることを確認します。

ClusterRoles

クラスターロールが存在し、ベースポリシーに応じて予想されるパーミッションが含まれることを確認します。

ClusterRouter

クラスター内に有効なデフォルトルーターがあることを確認します。

ConfigContexts

クライアント設定の各コンテキストが完成したものであり、その API サーバーへの接続があることを確認します。

DiagnosticPod

アプリケーションの観点で診断を実行する Pod を作成します。これは Pod 内の DNS が予想通りに機能しており、デフォルトサービスアカウントの認証情報がマスター API に対して正しく認証されることを確認します。

EtcdWriteVolume

一定期間における etcd に対する書き込みのボリュームを確認し、操作およびキー別にそれらを分類します。この診断は他の診断と同じ速度で実行されず、かつ etcd への負荷を増えることから、とくに要求される場合にのみ実行されます。

MasterConfigCheck

このホストのマスター設定ファイルで問題の有無を確認します。

MasterNode

このホストで実行されているマスターがノードも実行していることを確認し、それがクラスター SDN のメンバーであることを確認します。

MetricsApiProxy

統合 Heapster メトリクスがクラスター API プロキシー経由でアクセス可能であることを確認します。

NetworkCheck

複数のノードで診断 Pod を作成し、一般的なネットワークの問題をアプリケーションまたは Pod の観点で診断します。マスターが Pod をノードにスケジュールできるものの、Pod に接続の問題がある場合にこの診断を実行します。このチェックは、Pod がサービス、他の Pod および外部ネットワークに接続できることを確認します。

エラーがある場合は、この診断は詳細な分析用としてローカルディレクトリー (デフォルトで /tmp/openshift/) に結果および取得されたファイルを保存します。ディレクトリーは --network-logdir フラグで指定することができます。

NodeConfigCheck

このホストのノード設定ファイルで問題の有無を確認します。

NodeDefinitions

マスター API で定義されたノードが利用可能な状態にあり、Pod をスケジュールできることを確認します。

RouteCertificateValidation

すべてのルート証明書で、拡張される検証で拒否される可能性のあるものがあるかどうかを確認します。

ServiceExternalIPs

マスター設定に基づいて無効にされている外部 IP を指定する既存サービスの有無を確認します。

UnitStatus

OpenShift Container Platform に関連して、このホストでユニットについての systemd ステータスを確認します。チェックの実行に設定ファイルは不要です。

40.3. サーバー環境における診断の実行

Ansible でデプロイされるクラスターは、OpenShift Container Platform クラスター内のノードに診断に関する追加の利点を提供します。これらには以下が含まれます。

  • マスターおよびノード設定は標準的な場所にある設定ファイルに基づく。
  • systemd ユニットがサーバーを管理するように設定される。
  • マスターおよびノード設定ファイルはいずれも標準的な場所に置かれる。
  • Systemd ユニットがクラスターでノードを管理するために作成され、設定される。
  • すべてのコンポーネントが journald に対してログを記録する。

Ansible でデプロイされたクラスターで配置された設定ファイルのデフォルトの場所を維持することにより、フラグを使用せずに oc adm diagnostics を実行できます。設定ファイルにデフォルトの場所を使用していない場合は、--master-config および --node-config オプションを使用する必要があります。

# oc adm diagnostics --master-config=<file_path> --node-config=<file_path>

systemd ユニットおよび journald のログエントリーは現在のログ診断ロジックに必要です。他のデプロイメントタイプの場合、ログは単一ファイルに保存されるか、ノードとマスターを組み合わせるファイルに保存されるか、または標準出力 (stdout) に出力されます。ログエントリーで journald を使用しない場合、ログ診断は適切に機能せず、実行されません。

40.4. クライアント環境での診断の実行

診断ツールは通常のユーザーまたは cluster-admin として実行でき、これは実行の際に使用するアカウントに付与されたレベルのパーミッションを使って実行します。

通常のアクセスを持つクライアントはマスターへの接続を診断し、診断 Pod を実行することができます。複数のユーザーまたはマスターが設定されている場合、接続のテストはそれらすべてを対象に実行されますが、診断 Pod は現行ユーザー、サーバー、またはプロジェクトに対してのみ実行されます。

cluster-admin アクセスを持つクライアントは、ノード、レジストリー、およびルーターなどのインフラストラクチャーのステータスを診断できます。いずれの場合も、oc adm diagnostics を実行すると、標準の場所で標準のクライアント設定ファイルを検索し、利用可能な場合はこれを使用できます。

40.5. Ansible ベースのヘルスチェック

追加のヘルスチェックは、OpenShift Container Platform クラスターのインストールおよび管理に使用する Ansible ベースのツールで利用できます。このヘルスチェックでは、現行の OpenShift Container Platform インストールによくあるデプロイメントの問題を報告します。

これらのチェックは、ansible-playbook コマンドの使用 (クラスターインストールで使用されるのと同じ方式) によるか、または openshift-ansibleコンテナー化されたバージョンとして実行できます。ansible-playbook 方式については、チェックは openshift-ansible RPM パッケージを使って行われます。コンテナー化方式の場合は、openshift3/ose-ansible コンテナーイメージが Red Hat Container Registry 経由で配布されます。各方式の使用例については、後続のセクションで説明されます。|

以下のヘルスチェックは、デプロイされた OpenShift Container Platform クラスターを対象に、指定された health.yml playbook を使用して Ansible インベントリーファイルに対して実行されることが意図されている診断タスクのセットのこと指します。

警告

ヘルスチェック Playbook が環境に変更を加える可能性があるため、これらの Playbook は Ansible を使ってデプロイされたクラスターで、デプロイ時に使用したものと同じインベントリーファイルを使う場合にのみ使用できます。これらの変更には、チェックで必要な情報を収集できるように依存関係をインストールすることに関連するものです。そのような状況では、docker またはネットワーク設定などの追加のシステムコンポーネントは、現在の状態がインベントリーファイルの設定と異なる場合に変更される可能があります。これらのヘルスチェックは、使用するインベントリーファイルが既存のクラスター設定に変更を加えないことが予想される場合にのみ実行してください。

表40.1 正常性診断チェック

チェック名目的

etcd_imagedata_size

このチェックは、etcd クラスターの OpenShift Container Platform イメージデータの合計サイズを測定します。このチェックは計算されたサイズがユーザー定義の制限を超える場合に失敗します。制限が指定されない場合、このチェックはイメージデータのサイズが etcd クラスターで現在使用されている領域の 50 % 以上になる場合に失敗します。

このチェックに失敗することは、etcd の多くの領域が OpenShift Container Platform イメージデータによって使用されていることを示し、これにより、最終的には etcd クラスターがクラッシュする可能性があります。

ユーザー定義の制限は etcd_max_image_data_size_bytes 変数を渡すことで設定できます。たとえば、etcd_max_image_data_size_bytes=40000000000 を設定する場合、etcd に保存されるイメージデータの合計サイズが 40 GB を超えるとチェックが失敗します。

etcd_traffic

このチェックは、etcd ホストの通常よりも高いレベルのトラフィックを検知します。etcd 期間の警告と共に journalctl ログエントリーが見つかる場合に失敗します。

etcd パフォーマンスを強化する方法についての詳細は、「Recommended Practices for OpenShift Container Platform etcd Hosts」および Red Hat ナレッジベースを参照してください。

etcd_volume

このチェックにより、etcd クラスターのボリューム使用がユーザー指定の最大しきい値を超えないようにできます。最大しきい値が指定されていない場合、デフォルトは合計ボリュームサイズの 90% に設定されます。

ユーザー定義の制限は、etcd_device_usage_threshold_percent 変数を渡すことで設定できます。

docker_storage

docker デーモン (ノードおよびコンテナー化されたインストール) に依存するホストでのみ実行されます。docker の合計使用量がユーザー定義制限を超えないこと確認します。ユーザー定義の制限が設定されていない場合、docker 使用量の最大しきい値のデフォルトは利用可能な合計サイズの 90% になります。

合計パーセントの使用量についてのしきい値の制限は、max_thinpool_data_usage_percent=90 などのようにインベントリーファイルの変数で設定できます。

また、このチェックは docker のストレージがサポートされる設定を使用していることを確認します。

curatorelasticsearchfluentdkibana

この一連のチェックは、Curator、Kibana、Elasticsearch、および Fluentd Pod がデプロイされており、これらが running 状態であることを検証し、接続を制御ホストと公開される Kibana URL 間で確立できることを検証します。これらのチェックは、openshift_logging_install_logging インベントリー変数が true に設定されている場合にのみ実行され、それらが クラスターロギングが有効にされているデプロイメントで実行されるようにします。

logging_index_time

このチェックは、ロギングスタックデプロイメントにおけるログ作成から Elasticsearch によるログ集計までの通常の時間差よりも値が高くなるケースを検知します。新規のログエントリーがタイムアウト内 (デフォルトでは 30 秒内) に Elasticserach によってクエリーされない場合に失敗します。このチェックはロギングが有効にされている場合にのみ実行されます。

ユーザー定義のタイムアウトは、openshift_check_logging_index_timeout_seconds 変数を渡すことで設定できます。たとえば、openshift_check_logging_index_timeout_seconds=45 を設定すると、新規作成されるログエントリーが 45 秒を経過しても Elasticsearch でクエリーされない場合に失敗します。

sdn

このチェックは、OpenShift Container Platform SDN の以下のクラスターレベルの診断を実行します。

  • マスターホストが kubelets に接続できることを検証します。
  • ノードがパケットを相互にルート指定できることを検証します。
  • ノードアドレスを検証します。
  • HostSubnet オブジェクトを検証します。

openshift_checks_output_dir 変数を ansible-playbook コマンドで指定する場合、このチェックにより、OpenShift Container Platform API からのネットワーク関連のオブジェクトが、指定されるディレクトリーにあるログ、OVS フロー、iptables ルールその他のネットワーク設定情報と共に保存されます。変数の設定方法については、以下の ansible-playbook コマンドの使用例を参照してください。

このチェックは、oc adm diagnostics コマンドが診断 Pod をスケジュールできないか、または診断 Pod が問題のトラブルシューティングに必要な情報を十分に提供しない場合の Pod またはインフラストラクチャーの問題を診断するのに役立ちます。

注記

インストールプロセスの一部として実行されることが意図されている同様のチェックセットについては、「Configuring Cluster Pre-install Checks」を参照してください。証明書の有効期限をチェックするための別のチェックのセットについては、「Redeploying Certificates」を参照してください。

40.5.1. ansible-playbook によるヘルスチェックの実行

ansible-playbook コマンドを使用して openshift-ansible のヘルスチェックを実行するには、Playbook ディレクトリーに切り替え、クラスターのインベントリーファイルを指定し、health.yml Playbook を実行します。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
    playbooks/openshift-checks/health.yml

コマンドラインに変数を設定するには、key=value 形式の必要な変数に -e フラグを組み込みます。以下は例になります。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
    playbooks/openshift-checks/health.yml \
    -e openshift_check_logging_index_timeout_seconds=45 \
    -e etcd_max_image_data_size_bytes=40000000000

特定のチェックを無効にするには、Playbook を実行する前にインベントリーファイルのカンマ区切りのチェック名の一覧と共に変数 openshift_disable_check を組み込みます。以下は例になります。

openshift_disable_check=etcd_traffic,etcd_volume

または、ansible-playbook コマンドの実行時に -e openshift_disable_check=<check1>,<check2> で変数として無効にするチェックを設定します。

40.5.2. Docker CLI でのヘルスチェックの実行

コンテナーで openshift-ansible Playbook を実行し、Docker CLI で ose-ansible イメージを実行できるホストでの Ansible のインストールおよび設定の手間を省くことができます。

以下を、コンテナーを実行する権限を持つ root 以外のユーザーとして実行します。

# docker run -u `id -u` \ 1
    -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z,ro \ 2
    -v /etc/ansible/hosts:/tmp/inventory:ro \ 3
    -e INVENTORY_FILE=/tmp/inventory \
    -e PLAYBOOK_FILE=playbooks/openshift-checks/health.yml \ 4
    -e OPTS="-v -e openshift_check_logging_index_timeout_seconds=45 -e etcd_max_image_data_size_bytes=40000000000" \ 5
    openshift3/ose-ansible
1
これらのオプションにより、コンテナーは現行ユーザーと同じ UID で実行されます。これは SSH キーをコンテナー内で読み取られるようにするようにパーミッションで必要になります (SSH プライベートキーはその所有者によってのみ読み取り可能であることが予想されます)。
2
SSH キーは、コンテナーを非 root ユーザーとして実行するなどの通常の使用では /opt/app-root/src/.ssh の下にマウントします。
3
/etc/ansible/hosts は、異なる場合はクラスターのインベントリーファイルの場所に切り替えます。このファイルは、コンテナーの INVENTORY_FILE 環境変数に基づいて使用される /tmp/inventory にバインドおよびマウントされます。
4
PLAYBOOK_FILE 環境変数は、コンテナー内の /usr/share/ansible/openshift-ansible に関連して health.yml playbook の場所に設定されます。
5
-e key=value 形式で単一の実行に必要な変数を設定します。

上記のコマンドでは、SSH キーは :Z オプションを使ってマウントされ、コンテナーが SSH キーを制限付き SELinux コンテキストから読み取れるようにします。このオプションを追加することは、元の SSH キーファイルのラベルが system_u:object_r:container_file_t:s0:c113,c247 などに変更されることを意味しています。:Z についての詳細は、docker-run(1) man ページを参照してください。

重要

これらのボリュームマウント仕様に関連して予期しない影響が生じる可能性があります。たとえば、$HOME/.ssh ディレクトリーをマウント (したがってラベルを変更) する場合、sshd はパブリックキーにアクセスしてリモートログインを許可できなくなります。元のファイルラベルの変更を防ぐには、SSH キー (またはディレクトリー) のコピーをマウントします。

.ssh ディレクトリー全体をマウントすることは、以下に役立ちます。

  • キーをホストに一致させたり、他の接続パラメーターを変更したりするために SSH 設定を使用することを許可します。
  • ユーザーが known_hosts ファイルを指定し、SSH でホストキーを検証することを許可します。これはデフォルトの設定では無効にされていますが、-e ANSIBLE_HOST_KEY_CHECKING=Truedocker コマンドラインに追加することにより、環境変数を使用してこれを再度有効にできます。