|
| 1 | +--- |
| 2 | +title: クラスターのトラブルシューティング |
| 3 | +content_type: concept |
| 4 | +--- |
| 5 | + |
| 6 | +<!-- overview --> |
| 7 | + |
| 8 | +このドキュメントはクラスターのトラブルシューティングに関するもので、あなたが経験している問題の根本原因として、アプリケーションをすでに除外していることを前提としています。 |
| 9 | +アプリケーションのデバッグのコツは、[application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application)をご覧ください。 |
| 10 | +また、[troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)にも詳しい情報があります。 |
| 11 | + |
| 12 | +<!-- body --> |
| 13 | + |
| 14 | +## クラスターのリストアップ |
| 15 | + |
| 16 | +クラスターで最初にデバッグするのは、ノードがすべて正しく登録されているかどうかです。 |
| 17 | + |
| 18 | +```shell |
| 19 | +kubectl get nodes |
| 20 | +``` |
| 21 | + |
| 22 | +そして、期待するノードがすべて存在し、それらがすべて `Ready` 状態であることを確認します。 |
| 23 | + |
| 24 | +クラスター全体の健全性に関する詳細な情報を得るには、以下を実行します。 |
| 25 | + |
| 26 | +```shell |
| 27 | +kubectl cluster-info dump |
| 28 | +``` |
| 29 | +## ログの確認 |
| 30 | + |
| 31 | +今のところ、クラスターをより深く掘り下げるには、関連するマシンにログインする必要があります。 |
| 32 | +以下は、関連するログファイルの場所です。 |
| 33 | +(systemdベースのシステムでは、代わりに `journalctl` を使う必要があるかもしれないことに注意してください) |
| 34 | + |
| 35 | +### マスターノード |
| 36 | + |
| 37 | + * `/var/log/kube-apiserver.log` - APIの提供を担当するAPIサーバーのログ |
| 38 | + * `/var/log/kube-scheduler.log` - スケジューリング決定責任者であるスケジューラーのログ |
| 39 | + * `/var/log/kube-controller-manager.log` - レプリケーションコントローラーを管理するコントローラーのログ |
| 40 | + |
| 41 | +### ワーカーノード |
| 42 | + |
| 43 | + * `/var/log/kubelet.log` - ノード上でコンテナの実行を担当するKubeletのログ |
| 44 | + * `/var/log/kube-proxy.log` - サービスのロードバランシングを担うKube Proxyのログ |
| 45 | + |
| 46 | +## クラスター障害モードの一般的な概要 |
| 47 | + |
| 48 | +これは、問題が発生する可能性のある事柄と、問題を軽減するためにクラスターのセットアップを調整する方法の不完全なリストです。 |
| 49 | + |
| 50 | +### 根本的な原因 |
| 51 | + |
| 52 | + - VMのシャットダウン |
| 53 | + - クラスター内、またはクラスターとユーザー間のネットワークパーティション |
| 54 | + - Kubernetesソフトウェアのクラッシュ |
| 55 | + - データの損失や永続的ストレージ(GCE PDやAWS EBSボリュームなど)の使用不能 |
| 56 | + - Kubernetesソフトウェアやアプリケーションソフトウェアの設定ミスなど、オペレーターのミス |
| 57 | + |
| 58 | +### 具体的なシナリオ |
| 59 | + |
| 60 | + - apiserver VMのシャットダウンまたはapiserverのクラッシュ |
| 61 | + - 新しいPod、サービス、レプリケーションコントローラの停止、更新、起動ができない |
| 62 | + - Kubernetes APIに依存していない限り、既存のPodやサービスは正常に動作し続けるはずです |
| 63 | + - apiserverのバックアップストレージが失われた |
| 64 | + - apiserverが立ち上がらない |
| 65 | + - kubeletsは到達できなくなりますが、同じPodを実行し、同じサービスのプロキシを提供し続けます |
| 66 | + - apiserverを再起動する前に、手動でapiserverの状態を回復または再現する必要がある |
| 67 | + - サポートサービス(ノードコントローラ、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ |
| 68 | + - 現在、これらはapiserverとコロケーションしており、使用できない場合はapiserverと同様の影響があります |
| 69 | + - 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります |
| 70 | + - 独自の永続的な状態を持っていない。 |
| 71 | + |
| 72 | + - 個別ノード(VMまたは物理マシン)のシャットダウン |
| 73 | + - そのノード上のPodの実行を停止 |
| 74 | + - ネットワークパーティション |
| 75 | + - パーティションAはパーティションBのノードがダウンしていると考え、パーティションBはapiserverがダウンしていると考えています。(マスターVMがパーティションAで終了したと仮定) |
| 76 | + - Kubeletソフトウェア障害 |
| 77 | + - クラッシュしたkubeletがノード上で新しいPodを起動できない |
| 78 | + - kubeletがPodを削除するかどうか |
| 79 | + - ノードが不健全と判定される |
| 80 | + - レプリケーションコントローラーが別の場所で新しいPodを起動する |
| 81 | + - クラスターオペレーターエラー |
| 82 | + - PodやServiceなどの損失 |
| 83 | + - apiserverのバックエンドストレージの紛失 |
| 84 | + - ユーザーがAPIを読めなくなる |
| 85 | + - その他 |
| 86 | + |
| 87 | +### 軽減策 |
| 88 | + |
| 89 | +- 対処法: IaaSプロバイダーの自動VM再起動機能をIaaS VMに使用する |
| 90 | + - 異常: Apiserver VMのシャットダウンまたはApiserverのクラッシュ |
| 91 | + - 異常: サポートサービスのVMシャットダウンまたはクラッシュ |
| 92 | + |
| 93 | +- 対処法: IaaSプロバイダーの信頼できるストレージ(GCE PDやAWS EBSボリュームなど)をapiserver+etcdを使用するVMに使用する |
| 94 | + - 異常: Apiserverのバックエンドストレージが失われる |
| 95 | + |
| 96 | +- 対処法: [高可用性](/docs/setup/production-environment/tools/kubeadm/high-availability/)構成を使用します |
| 97 | + - 異常: コントロールプレーンノードのシャットダウンまたはコントロールプレーンコンポーネント(スケジューラー、APIサーバー、コントローラーマネージャー)のクラッシュ |
| 98 | + - 1つ以上のノードまたはコンポーネントの同時故障に耐えることができる |
| 99 | + - 異常: APIサーバーのバックアップストレージ(etcdのデータディレクトリーなど)が消失 |
| 100 | + - HA(高可用性) etcdの構成を想定しています |
| 101 | + |
| 102 | +- 対処法: apiserver PDs/EBS-volumesを定期的にスナップショットする |
| 103 | + - 異常: Apiserver のバックエンドストレージが失われる |
| 104 | + - 異常: 操作ミスが発生する場合がある |
| 105 | + - 異常: Kubernetesのソフトウェアに障害が発生する場合がある |
| 106 | + |
| 107 | +- 対処法：レプリケーションコントローラーとServiceをPodの前に使用する |
| 108 | + - 異常: ノードのシャットダウン |
| 109 | + - 異常: Kubeletソフトウェア障害 |
| 110 | + |
| 111 | +- 対処法: 予期せぬ再起動に耐えられるように設計されたアプリケーション(コンテナ) |
| 112 | + - 異常: ノードのシャットダウン |
| 113 | + - 異常: Kubeletソフトウェア障害 |
| 114 | + |
0 commit comments