第37章 診断ツール
37.1. 概要
oc adm diagnostics コマンドは一連のチェックを実行し、ホストまたはクラスターのエラーの状態についてチェックします。とくに以下を実行します。
- デフォルトのレジストリーおよびルーターが実行中であり、正しく設定されていることを確認します。
-
ClusterRoleBindingsおよびClusterRolesで、ベースポリシーとの整合性を確認します。 - すべてのクライアント設定コンテキストが有効で接続可能であることを確認します。
- SkyDNS が適切に機能しており、Pod に SDN 接続があることを確認します。
- ホストのマスターおよびノード設定を検証します。
- ノードが実行中で、利用可能であることを確認します。
- 既知のエラーについてホストログを分析します。
- systemd ユニットがホストに対して予想通りに設定されていることを確認します。
37.2. 診断ツールの使用
OpenShift Container Platform can be deployed in many ways: built from source, included in a VM image, in a container image, or as enterprise RPMs. Each method implies a different configuration and environment. To minimize environment assumptions, the diagnostics were added to the openshift binary so that wherever there is an OpenShift Container Platform server or client, the diagnostics can run in the exact same environment.
診断ツールを使用するには (マスターホスト上で使用するのが望ましい)、クラスター管理者として以下を実行します。
$ oc adm diagnostics
This runs all available diagnostics, skipping any that do not apply.
You can run one or multiple specific diagnostics by name, or run specific diagnostics by name as you work to address issues. For example:
$ oc adm diagnostics <name1> <name2>
The options mostly require working configuration files. For example, the NodeConfigCheck does not run unless a node configuration is available.
Diagnostics look for configuration files in standard locations:
クライアント:
-
As indicated by the
$KUBECONFIGenvironment variable variable - ~/.kube/config file
-
As indicated by the
マスター:
- /etc/origin/master/master-config.yaml
ノード:
- /etc/origin/node/node-config.yaml
Non-standard locations can be specified with flags (respectively, --config, --master-config, and --node-config). If a configuration file is not found or specified, related diagnostics are skipped.
利用可能な診断には以下が含まれます。
| 診断名 | 目的 |
|---|---|
|
|
集約されたログ統合を使用して適切な設定および操作を確認します。 |
|
|
systemd サービスログで問題の有無を確認します。チェックの実行に設定ファイルは不要です。 |
|
|
Check that the cluster has a working Docker registry for builds and image streams. |
|
|
デフォルトのクラスターロールバインディングが存在し、ベースポリシーに応じて予想されるサブジェクトが含まれることを確認します。 |
|
|
クラスターロールが存在し、ベースポリシーに応じて予想されるパーミッションが含まれることを確認します。 |
|
|
クラスター内に有効なデフォルトルーターがあることを確認します。 |
|
|
クライアント設定の各コンテキストが完成したものであり、その API サーバーへの接続があることを確認します。 |
|
|
アプリケーションの観点で診断を実行する Pod を作成します。これは Pod 内の DNS が予想通りに機能しており、デフォルトサービスアカウントの認証情報がマスター API に対して正しく認証されることを確認します。 |
|
|
一定期間における etcd に対する書き込みのボリュームを確認し、操作およびキー別にそれらを分類します。この診断は他の診断と同じ速度で実行されず、かつ etcd への負荷を増えることから、とくに要求される場合にのみ実行されます。 |
|
|
このホストのマスター設定ファイルで問題の有無を確認します。 |
|
|
このホストで実行されているマスターがノードも実行していることを確認し、それがクラスター SDN のメンバーであることを確認します。 |
|
|
統合 Heapster メトリクスがクラスター API プロキシー経由でアクセス可能であることを確認します。 |
|
|
Create diagnostic pods on multiple nodes to diagnose common network issues from an application standpoint. For example, this checks that pods can connect to services, other pods, and the external network.
エラーがある場合は、この診断は詳細な分析用としてローカルディレクトリー (デフォルトで /tmp/openshift/) に結果および取得されたファイルを保存します。ディレクトリーは |
|
|
このホストのノード設定ファイルで問題の有無を確認します。 |
|
|
マスター API で定義されたノードが利用可能な状態にあり、Pod をスケジュールできることを確認します。 |
|
|
すべてのルート証明書で、拡張される検証で拒否される可能性のあるものがあるかどうかを確認します。 |
|
|
マスター設定に基づいて無効にされている外部 IP を指定する既存サービスの有無を確認します。 |
|
|
OpenShift Container Platform に関連して、このホストでユニットについての systemd ステータスを確認します。チェックの実行に設定ファイルは不要です。 |
37.3. サーバー環境における診断の実行
Master and node diagnostics are most useful in an Ansible-deployed cluster. This provides some diagnostic benefits:
- マスターおよびノード設定は標準的な場所にある設定ファイルに基づく。
- systemd ユニットがサーバーを管理するように設定される。
- すべてのコンポーネントが journald に対してログを記録する。
Having configuration files where Ansible places them means that you will generally not need to specify where to find them. Running oc adm diagnostics without flags will look for master and node configurations in the standard locations and use them if found; this should make the Ansible-installed use case as simple as possible. Also, it is easy to specify configuration files that are not in the expected locations:
$ oc adm diagnostics --master-config=<file_path> --node-config=<file_path>
Systemd units and logs entries in journald are necessary for the current log diagnostic logic. For other deployment types, logs may be going into files, to stdout, or may combine node and master. At this time, for these situations, log diagnostics are not able to work properly and will be skipped.
37.4. クライアント環境での診断の実行
You may have access as an ordinary user, and/or as a cluster-admin user, and/or may be running on a host where OpenShift Container Platform master or node servers are operating. The diagnostics attempt to use as much access as the user has available.
A client with ordinary access should be able to diagnose its connection to the master and run a diagnostic pod. If multiple users or masters are configured, connections will be tested for all, but the diagnostic pod only runs against the current user, server, or project.
A client with cluster-admin access available (for any user, but only the current master) should be able to diagnose the status of infrastructure such as nodes, registry, and router. In each case, running oc adm diagnostics looks for the client configuration in its standard location and uses it if available.
37.5. Ansible ベースのヘルスチェック
Additional diagnostic health checks are available through the Ansible-based tooling used to install and manage OpenShift Container Platform clusters. They can report common deployment problems for the current OpenShift Container Platform installation.
These checks can be run either using the ansible-playbook command (the same method used during Advanced Installation) or as a containerized version of openshift-ansible. For the ansible-playbook method, the checks are provided by the atomic-openshift-utils RPM package. For the containerized method, the openshift3/ose-ansible container image is distributed via the Red Hat Container Registry. Example usage for each method are provided in subsequent sections.
以下のヘルスチェックは、デプロイされた OpenShift Container Platform クラスターを対象に、指定された health.yml playbook を使用して Ansible インベントリーファイルに対して実行されることが意図されている診断タスクのセットのこと指します。
Due to potential changes the health check playbooks could make to hosts, they should only be used on clusters that have been deployed using Ansible and using the same inventory file with which it was deployed. Changes mostly involve installing dependencies so that the checks can gather required information, but it is possible for certain system components (for example, docker or networking) to be altered if their current state differs from the configuration in the inventory file. Only run these health checks if you would not expect your inventory file to make any changes to your current cluster configuration.
| チェック名 | 目的 |
|---|---|
|
|
This check measures the total size of OpenShift Container Platform image data in an etcd cluster. The check fails if the calculated size exceeds a user-defined limit. If no limit is specified, this check will fail if the size of image data amounts to 50% or more of the currently used space in the etcd cluster. A failure from this check indicates that a significant amount of space in etcd is being taken up by OpenShift Container Platform image data, which can eventually result in your etcd cluster crashing.
A user-defined limit may be set by passing the |
|
|
このチェックは、etcd ホストの通常よりも高いレベルのトラフィックを検知します。etcd 期間の警告と共に For further information on improving etcd performance, see Recommended Practices for OpenShift Container Platform etcd Hosts and the Red Hat Knowledgebase. |
|
|
このチェックにより、etcd クラスターのボリューム使用がユーザー指定の最大しきい値を超えないようにできます。最大しきい値が指定されていない場合、デフォルトは合計ボリュームサイズの
ユーザー定義の制限は、 |
|
|
docker デーモン (ノードおよびコンテナー化されたインストール) に依存するホストでのみ実行されます。docker の合計使用量がユーザー定義制限を超えないこと確認します。ユーザー定義の制限が設定されていない場合、docker 使用量の最大しきい値のデフォルトは利用可能な合計サイズの 90% になります。
The threshold limit for total percent usage can be set with a variable in your inventory file, for example This also checks that docker's storage is using a supported configuration. |
|
|
This set of checks verifies that Curator, Kibana, Elasticsearch, and Fluentd pods have been deployed and are in a |
|
|
このチェックは、ロギングスタックデプロイメントにおけるログ作成から Elasticsearch によるログ集計までの通常の時間差よりも値が高くなるケースを検知します。新規のログエントリーがタイムアウト内 (デフォルトでは 30 秒内) に Elasticserach によってクエリーされない場合に失敗します。このチェックはロギングが有効にされている場合にのみ実行されます。
A user-defined timeout may be set by passing the |
A similar set of checks meant to run as part of the installation process can be found in Configuring Cluster Pre-install Checks. Another set of checks for checking certificate expiration can be found in Redeploying Certificates.
37.5.1. ansible-playbook によるヘルスチェックの実行
To run the openshift-ansible health checks using the ansible-playbook command, specify your cluster’s inventory file and run the health.yml playbook:
# ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/health.yml
コマンドラインに変数を設定するには、key=value 形式の必要な変数に -e フラグを組み込みます。以下は例になります。
# ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/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
Alternatively, set any checks you want to disable as variables with -e openshift_disable_check=<check1>,<check2> when running the ansible-playbook command.
37.5.2. Docker CLI でのヘルスチェックの実行
It is possible to run the openshift-ansible playbooks in a Docker container, avoiding the need for installing and configuring Ansible, on any host that can run the ose-ansible image via the Docker CLI.
To do so, specify your cluster’s inventory file and the health.yml playbook when running the following docker run command as a non-root user that has privileges to run containers:
# 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
- Change /etc/ansible/hosts to the location of your cluster’s inventory file, if different. This file will be bind-mounted to /tmp/inventory, which is used according to the
INVENTORY_FILEenvironment variable in the container. - 4
PLAYBOOK_FILE環境変数は、コンテナー内の /usr/share/ansible/openshift-ansible に関連して health.yml playbook の場所に設定されます。- 5
-e key=value形式で単一の実行に必要な変数を設定します。
In the above command, the SSH key is mounted with the :Z flag so that the container can read the SSH key from its restricted SELinux context; this means that your original SSH key file will be relabeled to something like system_u:object_r:container_file_t:s0:c113,c247. For more details about :Z, see the docker-run(1) man page.
Keep this in mind for these volume mount specifications because it could have unexpected consequences. For example, if you mount (and therefore relabel) your $HOME/.ssh directory, sshd will become unable to access your public keys to allow remote login. To avoid altering the original file labels, mounting a copy of the SSH key (or directory) is recommended.
You might want to mount an entire .ssh directory for various reasons. For example, this would allow you to use an SSH configuration to match keys with hosts or modify other connection parameters. It would also allow you to provide a known_hosts file and have SSH validate host keys, which is disabled by the default configuration and can be re-enabled with an environment variable by adding -e ANSIBLE_HOST_KEY_CHECKING=True to the docker command line.
