クラスターのトラブルシューティング

このドキュメントはクラスターのトラブルシューティングに関するもので、あなたが経験している問題の根本原因として、アプリケーションをすでに除外していることを前提としています。 アプリケーションのデバッグのコツは、application troubleshooting guideをご覧ください。 また、troubleshooting documentにも詳しい情報があります。

クラスターのリストアップ

クラスターで最初にデバッグするのは、ノードがすべて正しく登録されているかどうかです。

kubectl get nodes

そして、期待するノードがすべて存在し、それらがすべて Ready 状態であることを確認します。

クラスター全体の健全性に関する詳細な情報を得るには、以下を実行します。

kubectl cluster-info dump

ログの確認

今のところ、クラスターをより深く掘り下げるには、関連するマシンにログインする必要があります。 以下は、関連するログファイルの場所です。 (systemdベースのシステムでは、代わりに journalctl を使う必要があるかもしれないことに注意してください)

マスターノード

• /var/log/kube-apiserver.log - APIの提供を担当するAPIサーバーのログ
• /var/log/kube-scheduler.log - スケジューリング決定責任者であるスケジューラーのログ
• /var/log/kube-controller-manager.log - レプリケーションコントローラーを管理するコントローラーのログ

ワーカーノード

• /var/log/kubelet.log - ノード上でコンテナの実行を担当するKubeletのログ
• /var/log/kube-proxy.log - サービスのロードバランシングを担うKube Proxyのログ

クラスター障害モードの一般的な概要

これは、問題が発生する可能性のある事柄と、問題を軽減するためにクラスターのセットアップを調整する方法の不完全なリストです。

根本的な原因

• VMのシャットダウン
• クラスター内、またはクラスターとユーザー間のネットワークパーティション
• Kubernetesソフトウェアのクラッシュ
• データの損失や永続的ストレージ(GCE PDやAWS EBSボリュームなど)の使用不能
• Kubernetesソフトウェアやアプリケーションソフトウェアの設定ミスなど、オペレーターのミス

具体的なシナリオ

• apiserver VMのシャットダウンまたはapiserverのクラッシュ

  • 新しいPod、サービス、レプリケーションコントローラの停止、更新、起動ができない
  • Kubernetes APIに依存していない限り、既存のPodやサービスは正常に動作し続けるはずです

• apiserverのバックアップストレージが失われた

  • apiserverが立ち上がらない
  • kubeletsは到達できなくなりますが、同じPodを実行し、同じサービスのプロキシを提供し続けます
  • apiserverを再起動する前に、手動でapiserverの状態を回復または再現する必要がある

• サポートサービス(ノードコントローラ、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ

  • 現在、これらはapiserverとコロケーションしており、使用できない場合はapiserverと同様の影響があります
  • 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります
  • 独自の永続的な状態を持っていない。

• 個別ノード(VMまたは物理マシン)のシャットダウン

  • そのノード上のPodの実行を停止

• ネットワークパーティション

  • パーティションAはパーティションBのノードがダウンしていると考え、パーティションBはapiserverがダウンしていると考えています。(マスターVMがパーティションAで終了したと仮定)

• Kubeletソフトウェア障害

  • クラッシュしたkubeletがノード上で新しいPodを起動できない
  • kubeletがPodを削除するかどうか
  • ノードが不健全と判定される
  • レプリケーションコントローラーが別の場所で新しいPodを起動する

• クラスターオペレーターエラー

  • PodやServiceなどの損失
  • apiserverのバックエンドストレージの紛失
  • ユーザーがAPIを読めなくなる
  • その他

軽減策

• 対処法: IaaSプロバイダーの自動VM再起動機能をIaaS VMに使用する

  • 異常: Apiserver VMのシャットダウンまたはApiserverのクラッシュ
  • 異常: サポートサービスのVMシャットダウンまたはクラッシュ

• 対処法: IaaSプロバイダーの信頼できるストレージ(GCE PDやAWS EBSボリュームなど)をapiserver+etcdを使用するVMに使用する

  • 異常: Apiserverのバックエンドストレージが失われる

• 対処法: 高可用性構成を使用します

  • 異常: コントロールプレーンノードのシャットダウンまたはコントロールプレーンコンポーネント(スケジューラー、APIサーバー、コントローラーマネージャー)のクラッシュ
    • 1つ以上のノードまたはコンポーネントの同時故障に耐えることができる
  • 異常: APIサーバーのバックアップストレージ(etcdのデータディレクトリーなど)が消失
    • HA(高可用性) etcdの構成を想定しています

• 対処法: apiserver PDs/EBS-volumesを定期的にスナップショットする

  • 異常: Apiserver のバックエンドストレージが失われる
  • 異常: 操作ミスが発生する場合がある
  • 異常: Kubernetesのソフトウェアに障害が発生する場合がある

• 対処法：レプリケーションコントローラーとServiceをPodの前に使用する

  • 異常: ノードのシャットダウン
  • 異常: Kubeletソフトウェア障害

• 対処法: 予期せぬ再起動に耐えられるように設計されたアプリケーション(コンテナ)

  • 異常: ノードのシャットダウン
  • 異常: Kubeletソフトウェア障害