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

OpenShift Container Platform は数多くの方法でデプロイできます (ソースからのビルド、VM イメージ、コンテナーイメージの使用、またはエンタープライズ RPM の使用など)。それぞれの方法には異なる設定および環境が想定されます。環境について想定される相違を最小限にするために診断は openshift バイナリーに追加されており、OpenShift Container Platform サーバーまたはクライアントがどこに置かれていても、診断を全く同じ環境で実行できるようになっています。

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

$ oc adm diagnostics

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

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

$ oc adm diagnostics <name1> <name2>

ほとんどの場合、このオプションには機能する設定ファイルが必要になります。たとえば NodeConfigCheck は、ノード設定が利用可能でない場合は実行されません。

診断では標準的な場所にある設定ファイルを検索します。

標準以外の場所もフラグ (--config、--master-config および --node-config) で指定できます。設定ファイルが見つからないか、または指定されない場合、関連する診断は省略されます。

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

マスターおよびノードの診断は、Ansible でデプロイされるクラスターで最も役立ちます。この場合、いくつかの診断上のメリットがあります。

Ansibleが指定する場所に設定ファイルが置かれるため、それらを検索する場所を指定する必要がなくなります。フラグなしで oc adm diagnostics を実行すると、標準的な場所にあるマスターおよびノード設定ファイルを検索でき、それらが見つかり次第使用することができます。これにより、Ansible を使用してインストールする場合のされるユースケースをできる限り単純にすることができます。さらに、予想される場所にない設定ファイルを指定することも容易になります。

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

systemd ユニットおよび journald のログエントリーは現在のログ診断ロジックに必要です。他のデプロイメントタイプの場合、ログはファイルに記録されるか、標準出力に出力されるか、またはノードとマスターを組み合わせる可能性もあります。このような場合にログ診断は適切に機能せず、省略されます。

通常のユーザーまたは cluster-admin ユーザーとしてのアクセスを持つ場合、OpenShift Container Platform マスターまたはノードが動作するホストでの実行が可能です。診断はユーザーが利用できるアクセスをできるだけ多く使用することを試みます。

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

(すべてのユーザーが利用できるが、現行マスターのみで) 利用可能な cluster-admin アクセスを持つクライアントは、ノード、レジストリー、ルーターなどのインフラストラクチャーのステータスを診断できます。いずれの場合も、oc adm diagnostics を実行すると、標準的な場所にあるクライアント設定を検索でき、利用可能な場合はこれを使用できます。

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

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

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

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

# 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

openshift_disable_check=etcd_traffic,etcd_volume

# 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