---
title: クラスターのトラブルシューティング
description: 一般的なクラスターの問題をデバッグします。
weight: 20
no_list: true
---

<!-- overview -->

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

<!-- body -->

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

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

```shell
kubectl get nodes
```

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

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

```shell
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のバックエンドストレージが失われる

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

- 対処法: apiserver PDs/EBS-volumesを定期的にスナップショットする
  - 異常: Apiserver のバックエンドストレージが失われる
  - 異常: 操作ミスが発生する場合がある
  - 異常: Kubernetesのソフトウェアに障害が発生する場合がある

- 対処法：レプリケーションコントローラーとServiceをPodの前に使用する
  - 異常: ノードのシャットダウン
  - 異常: Kubeletソフトウェア障害

- 対処法: 予期せぬ再起動に耐えられるように設計されたアプリケーション(コンテナ)
  - 異常: ノードのシャットダウン
  - 異常: Kubeletソフトウェア障害