115 lines
6.7 KiB
Markdown
115 lines
6.7 KiB
Markdown
---
|
||
title: クラスターのトラブルシューティング
|
||
content_type: concept
|
||
---
|
||
|
||
<!-- overview -->
|
||
|
||
このドキュメントはクラスターのトラブルシューティングに関するもので、あなたが経験している問題の根本原因として、アプリケーションをすでに除外していることを前提としています。
|
||
アプリケーションのデバッグのコツは、[application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application)をご覧ください。
|
||
また、[troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)にも詳しい情報があります。
|
||
|
||
<!-- 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ソフトウェア障害
|
||
|