障害分析 | Kubernetes 障害診断プロセス

1. この記事の概要と主な用語

1.1 概要

この記事は、 Pod、Service、Ingress の3 つのモジュールに基づいて分割されており、Kubernetes で日常的に発生する可能性のある障害について、より具体的なトラブルシューティング手順が提供され、関連するソリューションやリファレンスが添付されています。

1.2 重要な用語

1. ポッド: Kubernetes で作成および管理される、展開可能な最小のコンピューティング ユニット。はコンテナのグループ (1 つ以上) であり、これらのコンテナはストレージ、ネットワーク、およびそれらの実行方法の宣言を共有します。

2. ポートフォワード: ポートフォワーディングを通じて、ローカルポートを指定されたアプリケーションポートにマッピングします。

3. サービス: Kubernetes サービスは、ポッドの論理コレクションとそれらにアクセスするためのポリシーを定義する抽象概念であり、マイクロサービスとも呼ばれます。

4. Ingress: クラスターの外部から内部 HTTP および HTTPS サービスへのルーティング通信を提供します。トラフィック ルーティングは、Ingress リソースで定義されたルールによって制御されます。

2. 故障診断プロセス

2.1 Podsモジュールのチェック

• 次のプロセスが成功した場合は下に進み、失敗した場合はプロンプトに従ってジャンプします。

2.1.1 PENDING 状態のポッドがあるかどうかを確認する

1. kubectl get pods: PENDING 状態のポッドがある場合は下を調べ、そうでない場合は 2.1.5 に進みます。

[root@10-186-65-37 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-55b54d55b8-5msx8 0/1 Pending 0 5m
 

2 kubectl description pod <pod-name>: 指定した1つ以上のリソースの詳細情報が正しく出力されていれば、クラスタリソースが不足しているかどうかを判断し、不足していれば拡張し、不足していれば2.1.2へ進みます。

2.1.2 ResourceQuota 制限がトリガーされているかどうかを確認する

1. kubectl description resourcequota -n <名前空間>:

 

2 制限がある場合は、対応するリソースを解放または拡張します。https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources を参照してください。

それ以外の場合は、2.1.3 に進みます。

2.1.3 PENDING 状態の PVC があるかどうかを確認する

1. 永続ボリューム (PersistentVolume、PV) はクラスター内のストレージの一部であり、管理者が事前にプロビジョニングすることも、ストレージ クラス (Storage Class) を使用して動的にプロビジョニングすることもできます。永続ボリューム要求 (Persistent VolumeClaim、PVC) は、ストレージに対するユーザーの要求を表します。

2. kubectl description pvc <pvc-name>: STATUS が保留中の場合

 

次に、次のリンクを参照して解決します: https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/

それ以外の場合は、2.1.4 に進みます。

2.1.4 ポッドがノードに割り当てられているかどうかを確認する

1. kubectl get pods -o Wide: ノードに割り当てられている場合

 

これはスケジューラの問題です。解決するには次のリンクを参照してください: https://kubernetes.io/zh/docs/concepts/scheduling-eviction/kube-scheduler/

それ以外の場合は Kubectl の問題です。

2.1.5 ポッドが実行状態であるかどうかを確認する

1. kubectl get pods -o Wide: ポッドが RUNNING 状態の場合は 2.1.10 に進み、それ以外の場合は 2.1.6 に進みます。

2.1.6 ポッドログの確認

1. kubectl ログ <ポッド名>:

ログが正しく取得できた場合は、ログに従って関連する問題を修正してください。

1. ログが取得できない場合は、コンテナがすぐに停止するかどうかを判断し、すぐに停止する場合は kubectl logs <pod-name> --previous を実行します。

2. ログが取得できず、コンテナがすぐに停止しない場合は、2.1.7へお進みください。

2.1.7 PodのステータスがImagePullBackOffかどうか

1. kubectl description pod <pod-name>: ステータスが ImagePullBackOff かどうかを確認しますか? ImagePullBackOff でない場合は、2.1.8 に進みます。

2. イメージ名が正しいか確認し、エラーを修正してください。

3. イメージ タグが存在し、検証されているかどうかを確認します。

4. プライベート レジストリからミラーを取得しますか? その場合は、構成情報が正しいことを確認してください。

5. イメージがプライベート レジストリから取得されていない場合は、CRI (Container Runtime Interface) または kubectl に問題がある可能性があります。

2.1.8 PodのステータスがCrashLoopBackOffかどうか

1. kubectl description pod <pod-name>: ステータスが CrashLoopBackOff かどうかを確認しますか? それ以外の場合は、2.1.9 に進みます。

2. その場合は、ログを確認してアプリのクラッシュを修正してください。

3. Dockerfile に CMD コマンドがありませんか? Docker 履歴 < image-id > (--no-trunc を追加して完全な出力を表示できます)

 

 

1. ポッドの状態が頻繁に再起動され、状態が実行中と CrashLoopBackOff の間で切り替わっていますか? その場合は、liveness プローブ (survival プローブ) を修正する必要があります。次のリンクを参照してください: https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

2.1.9 PodのステータスがRunContainerErrorかどうか

1. kubectl description pod <pod-name>: ステータスが RunContainerError かどうかを確認します。

2. ステータスが RunContainerError の場合は、ボリューム (ボリューム) のマウントが問題の原因である可能性があります。次のリンクを参照してください: https://kubernetes.io/zh/docs/concepts/storage/volumes/

3. それ以外の場合は、StackOverflow などのサイトでヘルプを求めてください。

2.1.10 ポッドが READY 状態であるかどうかを確認する

1. READY状態の場合はマッピング設定を継続して実行します。

 

READY 状態のポッドがない場合は、2.1.11 に進みます。

2. kubectl port-forward <ポッド名> 8080:<ポッドポート> 

3. マッピングが正常に完了すると、2.2 に進みます。

a) マップする

 b) マッピングが成功したことを確認します。

 

失敗した場合は、プログラムがすべてのアドレスで監視できることを確認する必要があります。

 

すべてのアドレスで監視できない場合は、不明な状態(Unknown state)となります。

2.1.11 準備状況の確認 (Readiness Probe)

1. kubectl 説明ポッド <ポッド名>

2. 通常の出力の場合は、ログに従って対応する問題を修正し、次のリンクを参照してください https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

3. 障害は不明な状態 (Unknown state) です。

2.2 サービスモジュールの検査

2.2.1 サービスの現状確認

1. kubectl description service <service-name> の正常な出力は次のとおりです。

 

2 [エンドポイント] 列が表示され、正常な出力が表示されますか? 異常な出力については、2.2.2 に進みます。

3 kubectl port-forward service/<service-name> 8080:<service-port> 成功した出力は次のとおりです。

 

4 成功した場合は 2.3 に進み、失敗した場合は 2.2.4 に進みます。

2.2.2 セレクターとポッドラベルの比較

1. ポッドのラベル情報を表示します。 kubectl description pod <pod-name>

 

2 サービスのセレクター情報を表示します。 kubectl description service <service-name>

3 2 つを比較して正しく一致するかどうかを確認し、間違っている場合は修正し、正しい場合は 2.2.3 に進みます。

2.2.3 ポッドに IP が割り当てられているかどうかを確認する

1. ポッドの IP 情報を表示する kubectl description pod <pod-name>

2. IP が正しく割り当てられている場合、問題の原因は kubectl です。

 

 

3 IP が割り当てられていない場合、問題の原因はコントローラ マネージャです。

2.2.4 サービスの TargetPort と Pod ContainerPort を確認する

1. サービスの TargetPort 情報を表示します: kubectl description service <service-name>

 

2 ポッドの ContainerPort 情報を表示します: kubectl description pod <pod-name>

 

3 上記 2 つが一致する場合、問題の原因は kube-proxy です。一致しない場合は、情報を修正します。

2.3 Ingressモジュールのチェック

2.3.1 イングレスの現在のステータスの確認

1. kubectl description ingress <ingress-name> の正常な出力は次のとおりです。

 

2 バックエンド列が表示され、通常の出力が得られますか? 通常の出力は 2.3.4 に進み、それ以外の場合は 2.3.2 に進みます。

2.3.2 ServiceName と ServicePort を確認する

1. kubectl description ingress <ingress-name>

2. kubectl 説明サービス <サービス名>

 

3 最初の 2 つの ServiceName と ServicePort が正しいかどうかを確認し、正しい場合は 2.3.3 に進み、エラーを修正してください。

2.3.3 Ingress コントローラーのドキュメント

1. この問題は Ingress コントローラーが原因で発生します。解決策を見つけるにはドキュメントを参照してください: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

2.3.4 ポートフォワード入力の確認

1. kubectl port-forward <ingress-pod-name> 8080:<ingress-port> 正常にアクセスできるかどうかをテストします:curl localhost:8080

通常のアクセスの場合は 2.3.5 に進み、それ以外の場合は 2.3.3 に進みます。

2.3.5 外部ネットワークのIngress経由でアクセスできるか確認する

1. 外部ネットワークからは正常にアクセスでき、トラブルシューティングは終了です。

2. 外部ネットワークからアクセスできない場合は、インフラストラクチャまたはクラスターの露出が原因で問題が発生しているため、トラブルシューティングを行ってください。

参考文献 

障害分析 | Kubernetes 障害診断プロセス (qq.com)