47- 第11章：コマンドの実行-3：トラブルシューティングコマンドの実行の説明

type

status

date

slug

summary

トラブルシューティングコマンドの実行

目的

このセクションを完了すると、学生は一般的な問題のトラブルシューティングに役立つコマンドを実行できるようになります。

一般的な環境情報

Red Hat OpenShift Container PlatformをRPMインストール方法でインストールした場合、マスターとノードのコンポーネントはRed Hat Enterprise Linuxサービスとして実行されます。マスターとノードからのデータ収集の出発点として、標準のsosreportユーティリティを使用できます。このユーティリティは、環境に関する情報と、DockerやOpenShift関連の情報を収集します。

このコマンドは、Red Hat Enterprise Linuxシステムおよびインストールされたアプリケーションに関する診断および構成情報を収集します。実行中に情報が収集され、最終的に次のような圧縮アーカイブが作成されます：

作成されたアーカイブファイルは、Red Hatサポートに送信できます。

もう1つの有用な診断ツールは、oc adm diagnosticsコマンドです。このコマンドを使用すると、OpenShiftクラスターのネットワーク、集約ログ、内部レジストリ、マスターおよびノードのサービスチェックなど、さまざまな診断チェックを実行できます。詳細な診断リストを確認するには、oc adm diagnostics --helpコマンドを実行します。

OpenShiftトラブルシューティングコマンド

ocコマンドラインクライアントは、OpenShiftクラスターの管理者が問題を検出し、診断し、修正するための主要なツールです。このツールには、マスターとノード、サービス、クラスタ内のリソースの問題を特定するためのさまざまなオプションがあります。必要な権限がある場合は、クラスタで管理されているリソースの設定を直接編集することもできます。

`oc get events` コマンド

oc get eventsコマンドは、OpenShiftの名前空間内のイベント情報を提供します。イベントには、以下のような情報が含まれます：

ポッドの作成と削除

ポッドの配置スケジューリング

マスターおよびノードのステータス

イベントはトラブルシューティングに役立ちます。クラスター内での失敗や問題に関する高レベルの情報を取得し、その後、ログファイルや他のocサブコマンドを使用して調査を進めることができます。

特定のプロジェクトでイベントのリストを取得するには、次のコマンドを実行します：

Web コンソールからイベントを確認する

プロジェクトのイベントは、Web コンソールの「Monitoring → Events」ページからも確認できます。また、ポッドやデプロイメントなど、その他の多くのオブジェクトにも「Events」タブがあり、そのオブジェクトに関連するイベントが表示されます。

図 11.1: Web コンソールでイベントを確認する

OpenShift Container Platform 3.9 の包括的なイベントのリストは、こちらで確認できます。

`oc logs` コマンド

oc logs コマンドは、特定のビルド、デプロイメント、またはポッドのログ出力を取得します。このコマンドは、ビルド、ビルド構成、デプロイメント構成、ポッドに対して使用できます。

ポッドのログを確認するには、次のようにコマンドを実行します：

ビルドのログを確認するには：

oc logs コマンドに -f オプションを付けて実行すると、リアルタイムでログ出力を追跡できます。これは、ビルドの進行状況を継続的に監視したり、エラーをチェックする際に便利です。

Web コンソールからも、ポッド、ビルド、デプロイメントのログ情報を確認できます。

`oc rsync` コマンド

oc rsync コマンドは、実行中のポッドのディレクトリ間でコンテンツをコピーします。ポッドが複数のコンテナを持っている場合は、-c オプションを使用してコンテナ ID を指定できます。指定しない場合は、デフォルトでポッド内の最初のコンテナが対象となります。このコマンドは、コンテナからログファイルや設定ファイルを転送する際に便利です。

ポッドのディレクトリからローカルディレクトリにコンテンツをコピーするには：

ローカルディレクトリからポッドのディレクトリにコンテンツをコピーするには：

`oc port-forward` コマンド

oc port-forward コマンドを使用すると、ローカルポートをポッドに転送できます。これにより、ローカルで特定のポートまたはランダムなポートをリスンし、そのポートをポッド内の指定したポートにデータ転送できます。

このコマンドの形式は次のとおりです：

例えば、ローカルのポート 3306 をポッド内の 3306 に転送するには、次のコマンドを実行します：

一般的な問題のトラブルシューティング

OpenShift のデプロイメントでよく見られるエラーや問題、そしてそれらをトラブルシュートするためのツールについて説明します。

リソース制限およびクォータの問題

プロジェクトにリソース制限やクォータが設定されている場合、リソースの不適切な設定はデプロイメントの失敗を引き起こします。oc get events や oc describe コマンドを使用して、失敗の原因を調査できます。

例えば、ポッド数に制限があるプロジェクトで、許可されているポッド数を超えて作成しようとした場合、oc get events コマンドを実行すると、次のような出力が表示されます：

Source-to-Image (S2I) ビルドの失敗

S2I ビルドの失敗を確認するには、oc logs コマンドを使用します。例えば、hello というビルド構成のログを表示するには、次のコマンドを実行します：

ビルドログの詳細度は、ビルド構成戦略で BUILD_LOGLEVEL 環境変数を指定することで調整できます。例えば：

`ErrImagePull` と `ImgPullBackOff` エラー

これらのエラーは、デプロイメント構成の誤り、デプロイメント中に参照されたイメージが間違っているか不足している、または不適切な Docker 設定によって発生します。例えば：

これらのエラーを解決するには、oc get events や oc describe コマンドを使用して詳細を確認し、oc edit dc/<deploymentconfig> コマンドでデプロイメント構成を修正します。

不正な Docker 設定

マスターやノードでの不正な Docker 設定は、デプロイメント中に多くのエラーを引き起こす原因となります。特に、ADD_REGISTRY、INSECURE_REGISTRY、BLOCK_REGISTRY の設定が正しいか確認する必要があります。これらの設定を確認するには、systemctl status、oc logs、oc get events、oc describe コマンドを使用して問題をトラブルシュートします。

Docker サービスのログレベルは、/etc/sysconfig/docker にある設定ファイルの OPTIONS 変数で --log-level パラメータを追加することで変更できます。例えば、ログレベルを debug に設定する場合：

マスターおよびノードサービスの障害

atomic-openshift-master、atomic-openshift-node、etcd、docker サービスに関する問題をトラブルシュートするためには、systemctl status コマンドを実行します。サービスに関するシステムログは、journalctl -u <unit-name> コマンドで確認できます。

また、atomic-openshift-node、atomic-openshift-master-controllers、atomic-openshift-master-api サービスのログレベルを上げるためには、対応する設定ファイルの --loglevel 変数を編集し、関連サービスを再起動します。

例えば、OpenShift マスターコントローラーのログレベルを debug に設定するには、次の行を /etc/sysconfig/atomic-openshift-master-controllers ファイルに追加します：

OpenShift ノードのログレベルも、/etc/sysconfig/atomic-openshift-node ファイルで変更できます。