Kubernetesポッド障害の分類およびトラブルシューティング方法

ポッドコンセプト

ポッドは協力的なスケジューリングを扱う最小のクラスタkubernetesの導入と管理、コラボレーションの基本単位です。
ポッドは、1つ以上の容器のセット、1またはサービスのセット（プロセス）抽象のセットです。
ポッド保管及び（仮想マシンは単に仮想マシン論理ではなく、として理解することができる）ネットワークを共有することができます。
一意に識別されたUIDを使用して作成された後のポッドは、ライフサイクルポッド、ポッドの端部は等価の代替である場合、UIDが再生しました。

DockerでKubernetes Pod最も一般的に使用されるコンテナが実行されているが、Podまた、RKT、podmanとしてなどに、他の容器の操作をサポートすることができます。

ポッドKubernetesクラスタは2つの主な目的のために使用することができます。

运行单个容器的 Pod。「各ポッド容器は、」例Kubernetesに使用される最も一般的なモデルであり、この場合には、単一の容器ポッドラッパーと見なすことができ、ポッドKubernetes直接管理ではなく、容器。
运行多个协同工作的容器的 Pod。ポッドはしっかりリソースの複数の容器共存組成アプリケーションを共有する必要性によって結合包装することができます。これらの共位置サービス単位容器は、単一の凝集を形成することができる、コンテナファイルは、パブリックに共有ボリュームから供給され、別々の「予告編」容器又はリフレッシュ更新、これらのファイルの他のれます。ポッドのストレージリソースと管理エンティティとしてパッケージ化され、これらのコンテナ。

ポッドコントローラ

コントローラは、作成および管理する複数のポッド、コピーをし、ライン上の管理、およびクラスタ内で自己修復機能を提供することができます。ノードに障害が発生した場合、例えば、コントローラは自動的にPODが異なるノード上にアバター同じスケジュールを置き換えることができます。

一つ以上のポッドを含むコントローラいくつかの例を含みます。

Deployment オペレーティングステートレスのためkubernetesは、最も一般的に使用されるコントローラアプリケーション
StatefulSet ステートフルなアプリケーションを実行するための
DaemonSet お使いのコンピュータ上のデーモンのような行為は、それがクラスタストレージ、ログ収集と監視「デーモン」を実行することができます

コントローラは、通常、それはあなたが提供するテンプレートを使用するための責任があるポッドポッドを作成しています。

ポッド障害の分類

保留状態は、ポッドにありました
ポッドは待ちの状態になっています
ポッドは、状態ContainerCreatingにありました
ImagePullBackOffにおけるポッドステータス
CrashLoopBackOffにおけるポッドステータス
エラーでポッドステータス
ポッドは、状態の終端にありました
ポッドの状態は不明です

上記のすべて、私を許してくださいされていない場合、個々の要約です！

ポッドのトラブルシューティングコマンド

kubectl get pod <pod-name> -o yaml ＃ビューポッドが正しく設定されています
kubectl describe pod <pod-name> ポッド＃ビューは、イベントの詳細情報を
kubectl logs <pod-name> [-c <container-name>] ＃ビューコンテナのログ

ポッド障害の問題やトラブルシューティング方法

ポッドにあったPending状態

保留状態、YAMLドキュメントのポッドがKubernetesに提出されている、手段は、APIオブジェクトが作成され、Etcdそれらに保存されています。しかし、何らかの理由で、いくつかのコンテナ内のポッドが正常に作成することができません。例えば、失敗したスケジューリングが（できkubectl describe podないスケジュールが存在しない理由を決定現在ポッド入射コマンドを表示する、など）。考えられる原因：;のHostPortは、（一般的に推奨されるサービスのオープンサービスポート）を占有しているリソース不足は、（クラスタ内のすべてのノードのCPU、メモリ、GPUおよびポッド要求の他のリソースを満たされていません）。
ポッドにされているWaitingかContainerCreatingの状態

まずであるkubectl describe pod現在のコマンドの表示Podイベントのを。考えられる原因は次のとおりです。

1は镜像拉取失败、例えば、ミラーのアドレス構成エラーが外国引っ張るミラー元（gcr.io）、秘密鍵設定エラーミラーを取ることができない、ミラーは、引き出しには大きすぎる（適宜--imageプルprogress-のkubeletを調整することができます締め切りと--runtime要求-timeoutオプション）など。

あなたが割り当てたIPアドレスことはできませんが、ポッドは、ネットワークを構成することはできません：2、CNIネットワーク・エラーは、一般的に次のような、設定CNIネットワークプラグインをチェックする必要があります。

3、コンテナが起動できません、あなたは正しいパッケージが正しく設定またはコンテナのパラメータをミラーリングしていることを確認する必要があります。

失敗4は、ポッドサンドボックスを作成し、おそらくディスクに不良セクタ（入力/出力エラー）に、kubeletログを参照してください。
ポッドにあったImagePullBackOff状態

通常、镜像名称配置错误または私有镜像的密钥配置错误导致。この状況は、使用することができdocker pull、ミラーが適切に引くことができることを確認するために。

プライベートキー画像が構成されるか、または誤って設定されていない場合は、次のように確認してください。

1、クエリドッキングウィンドウ・レジストリの秘密のタイプ
```
# 查看 docker-registry Secret 
$ kubectl  get secrets my-secret -o yaml | grep 'dockerconfigjson:' | awk '{print $NF}' | base64 -d
```
ドッキングウィンドウ、レジストリタイプシークレットを作成します。2.
```
# 首先创建一个 docker-registry 类型的 Secret
$ kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

# 然后在 Deployment 中引用这个 Secret
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: my-secret
```
ポッドにあったCrashLoopBackOff状態

CrashLoopBackOffステータス説明コンテナが開始しますが、予期せず終了しました。この時点では、最初のログの容器で見ることができます。

コマンドkubectl logsとkubectl logs --previous猫の/ var -見つからない場合は、コンテナへの手がかりも終了理由（kubectlのexecカサンドラをチェックするためのコマンドを実行することができ、ヘルスチェックが失敗して終了、コンテナプロセスが終了：のような、終了にはいくつかのコンテナの理由で見つけることができますあなたはまだ見当もつかない場合/log/cassandra/system.log）、それはポッドは、ビューノードにログインするためにSSHに必要があるだろうKubeletか、Dockerさらに調査をログに記録します。
ポッドError状態

通常、エラーステータスに説明ポッドエラーが起動中に発生しました。依存：一般的な原因はConfigMap、SecretまたはPV存在しない、;要求されたリソースは、以上のように、管理者によって制限セットを超えているLimitRangeなど、セキュリティポリシーのクラスタの違反等違反などPodSecurityPolicyのような、コンテナのリソースがクラスタ内で動作する権利、などを持っていませんオープンRBAC、あなたがする必要がServiceAccount結合文字を設定します。
ポッドで終端するか不明な状態

開始からV1.5は、Kubernetesノードが削除ポッドにし、その実行に失われることはありませんが、としてマークされますTerminatingかUnknown状態。ポッドは、これらの状態を削除する3つの方法があります。

クラスタからのノードの削除1.。パブリッククラウドを使用する場合は、KUBE-コントローラ・マネージャーは自動的にVM内の対応するノードを削除削除させていただきます。物理マシン配備クラスタでは、手動での管理者のニーズは、ノード（例えばkubectlノード削除など）を削除します。

2、通常のノードバック。Kubeletはその後、削除またはポッドを実行し続けることを決定することができ、通信のKUBE-apiserverポッドでこれらの期待の状態を再確認します。ユーザーが削除することを余儀なく。ユーザーが実行できるkubectl delete pods pod-name --grace-period=0 --force強制的にポッドを削除します。明示的に（例えばVMまたは物理マシンがオフになっているノードなど）停止状態で実際にポッドを知っている限り、この方法を使用することはお勧めできません。特に、StatefulSetポッドの管理は、簡単にデータの損失やスプリットブレインの問題につながるの削除を強制します。

図3に示すように、ポッド異常行動、異常行動は、ここに述べたポッドを意味するよう動作していないように、予想される動作として実行されないpodSpecコマンドライン引数セット内を。これは、一般的にpodSpec YAMLファイルの内容の誤りである、あなたが使用して試すことができます--validate次のようなパラメータを再構成コンテナを、

kubectl delete pod mypodそしてkubectl create --validate -f mypod.yaml、あなたはまたのような、podSpecポストが作成されたかどうかを確認することができます：kubectl get pod mypod -o yaml静的ポッドを変更Manifest--pod-マニフェストパスのKubeletでの/ etc / kubernetes /マニフェストディレクトリを（inotifyを検出しないように自動的に再構築し、Kubeletが使用メカニズムの後オプションは、静的ポッドに変更し、ファイルの変更後に適切なポッドを再作成）が指定されています。しかし、時には、それは自動的に新しいシナリオを作成しませんがマニフェストポッドポッドはまだ行われます、今回は簡単な修正がKubeletを再起動することで変更しました。

Unknown これは異常な状態であり、状態はPODがkubelet KUBE-apiserverに報告され続けることができないことを意味し、それは可能性が高いから、マスターノード（マスターとKubelet）との間の通信の問題が存在することです。