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

このドキュメントはクラスターのトラブルシューティングに関するもので、あなたが経験している問題の根本原因として、アプリケーションをすでに除外していることを前提としています。 アプリケーションのデバッグのコツは、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ソフトウェア障害
最終更新 April 23, 2022 at 3:41 AM PST: [ja] Translate tasks/debug-application-cluster/debug-cluster into Japanese #30874 (#31087) (4b85c7b058)