36.13. EFK のトラブルシューティング

以下のトラブルシューティングの問題は、通常は EFK スタックに適用されます。

デプロイメントが失敗し、ReplicationControllers が 0 にスケーリングされる

10 分のタイムアウトの前にインスタンスを正常に起動しないデプロイメントを実行する場合、OpenShift Container Platform はデプロイメントを失敗とみなし、ゼロインスタンスに縮小します。oc get pods コマンドはゼロ以外の終了コードを出して、デプロイされた Pod がない状態でデプロイヤー Pod を表示します。

以下の例では、Elasticsearch デプロイメントのデプロイヤー Pod が表示されています。 これは、DeploymentConfig logging-es-2e7ut0iq のデプロイメントである ReplicationController logging-es-2e7ut0iq-1 から取られています。

NAME                           READY     STATUS             RESTARTS   AGE
logging-es-2e7ut0iq-1-deploy   1/1       ExitCode:255       0          1m

デプロイメントの失敗は、イメージのプルに時間がかかりすぎたり、ノードが反応しないなどの数多くの一時的な理由によって生じる可能性があります。

デプロイヤー Pod で考えられる理由について調べるか、または再デプロイを試行します。

$ oc deploy --latest logging-es-2e7ut0iq

または、既存デプロイメントの拡大を試行します。

$ oc scale --replicas=1 logging-es-2e7ut0iq-1

問題が残る場合は、Pod、イベント、および systemd ユニットログを調べて問題の原因を判別します。

kubernetes.default.svc.cluster.local を解決できない

マスターのこの内部エイリアスは、マスター上の組み込まれている DNS サーバーによって解決可能でなければなりません。プラットフォームによっては、マスターに対して (たとえばコンテナー内で) dig コマンドを実行し、これを確認することができます。

$ dig kubernetes.default.svc.cluster.local @localhost
[...]
;; QUESTION SECTION:
;kubernetes.default.svc.cluster.local. IN A

;; ANSWER SECTION:
kubernetes.default.svc.cluster.local. 30 IN A   172.30.0.1

古いバージョンのクラスターロギングは、マスターのこの内部エイリアスを自動的に定義しませんでした。集計ロギングを使用するには、クラスターをアップグレードする必要がある場合があります。クラスターが最新の状態にある場合、Pod がマスターの SkyDNS リゾルバーに達する際に問題が生じているか、または Pod の実行がブロックされている可能性があります。この問題を解決してから再度デプロイする必要があります。

マスターまたはサービスに接続できない

DNS 解決が何も返さないか、またはアドレスが (fluentd Pod などの) Pod から接続できない場合、これはシステムのファイアウォール/ネットワークの問題があることを示している可能性があります。この問題はデバッグする必要があります。