Kubernetes (K8s) のデプロイメントでは、ポッド、サービス、イングレス、応答しないクラスター、コントロール プレーン、高可用性セットアップなど、さまざまな観点から課題が生じることがよくあります。 Kubernetesポッドは、Kubernetes エコシステム内でデプロイ可能な最小単位であり、リソースとネットワークを共有する 1 つ以上のコンテナをカプセル化します。ポッドは、アプリケーションまたはプロセスの単一インスタンスを実行するように設計されており、必要に応じて作成および破棄されます。ポッドは、K8s 環境でアプリケーションをスケーリング、更新、保守するために不可欠です。
「Master Kubernetes Pods: Advanced Troubleshooting Strategies 」 (著者なし)から翻訳。
この記事では、Kubernetes ポッドが直面する課題と実行するトラブルシューティングの手順について説明します。 Kubernetes ポッドの実行時に発生するエラー メッセージには、次のようなものがあります。
- 画像プルバックオフ
- ErrImagePull
- 無効な画像名
- クラッシュループバックオフ
場合によっては、リストされているエラーさえ発生しないにもかかわらず、ポッドが失敗していることがわかります。まず、Kubernetes リソースをデバッグするときは、API リファレンスを理解する必要があることに注意することが重要です。さまざまな Kubernetes API がどのように定義されているか、およびポッド/デプロイメント内の複数のオブジェクトがどのように機能するかについて説明します。このドキュメントは、 Kubernetes Web サイトの API リファレンスで明確に定義されています。この場合、ポッドをデバッグするときに、API リファレンスからポッド オブジェクトを選択して、ポッドの動作の詳細を確認します。ポッドに入るフィールド、つまりバージョン、タイプ、メタデータ、仕様、ステータスを定義します。 Kubernetes には、必要なコマンドのガイドを記載したチートシートも提供されています。
前提条件
この記事は、読者が次のような状況にあることを前提としています。
Kubernetes ポッド エラー - ImagePullBackoff
このエラーは、次の 3 つの異なる理由で表示されます。
- 無効な画像です
- 無効なタグ
- 無効な権限
このような状況は、画像に関する正しい情報がない場合に発生します。また、リポジトリ (プライベート リポジトリ) からイメージをプルする権限がない場合もあります。以下の例でこれを示すために、nginx デプロイメントを作成します。
➜ ~ kubectl create deploy nginx --image=nginxdeployment.apps/nginx created
ポッドが実行されたら、ポッド名を取得します。
➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-8f458dc5b-hcrsh 1/1 Running 0 100s
実行中のポッドの名前をコピーし、それに関する詳細情報を取得します。
➜ ~ kubectl describe pod nginx-8f458dc5b-hcrsh
Name: nginx-8f458dc5b-hcrsh
hable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m43s default-scheduler Successfully assigned default/nginx-8f458dc5b-hcrsh to k8s-troubleshooting-control-plane
Normal Pulling 2m43s kubelet Pulling image "nginx"
Normal Pulled 100s kubelet Successfully pulled image "nginx" in 1m2.220189835s
Normal Created 100s kubelet Created container nginx
Normal Started 100s kubelet Started container nginx
イメージは正常に取得されました。 Kubernetes ポッドはエラーなしで実行されています。
ImagePullBackoff をデモンストレーションするには、デプロイメント YAML ファイルを編集し、存在しないイメージを指定します。
➜ kubectl edit deploy nginx
containers:
-image: nginxdoestexist
imagePullPolicy: Always
name: nginx
新しいポッドは正常にデプロイされませんでした
➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-5b847fdb95-mx4pq 0/1 ErrImagePull 0 3m40s
nginx-8f458dc5b-hcrsh 1/1 Running 0 38m
ImagePullBackoff エラーが表示される
➜ ~ kubectl describe pod nginx-6f46cbfbcb-c92bl
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 88s default-scheduler Successfully assigned default/nginx-6f46cbfbcb-c92bl to k8s-troubleshooting-control-plane
Normal Pulling 40s (x3 over 88s) kubelet Pulling image "nginxdoesntexist"
Warning Failed 37s (x3 over 85s) kubelet Failed to pull image "nginxdoesntexist": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/nginxdoesntexist:latest": failed to resolve reference "docker.io/library/nginxdoesntexist:latest": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
Warning Failed 37s (x3 over 85s) kubelet Error: ErrImagePull
Normal BackOff 11s (x4 over 85s) kubelet Back-off pulling image "nginxdoesntexist"
Warning Failed 11s (x4 over 85s) kubelet Error: ImagePullBackOff
Kubernetes ポッド エラー - イメージはプルされましたが、ポッドは保留中のステータスになっています。
K8s を運用環境で実行するときは常に、K8s 管理者は、クラスター内で実行されている名前空間の要件に基づいて、各名前空間にリソース クォータを割り当てます。ネームスペースは、クラスター内の論理的な分離に使用されます。
「イメージはプルされましたが、ポッドはまだ保留中です」エラーは、リソース クォータの仕様がポッド内のアプリケーションの最小要件を満たしていない場合にスローされます。次の例では、payments という名前空間を作成します。
➜ ~ kubectl create ns payments
namespace/payments created
関連する仕様を使用してリソース クォータを作成する
➜ ~ cat resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 4Gi
名前空間の支払いにリソース割り当てを割り当てる
➜ ~ kubectl apply -f resourcequota.yaml -n paymentsresourcequota/compute-resources created
作成されたリソース クォータ/コンピューティング リソース
リソース クォータ制限のある名前空間内に新しいデプロイメントを作成します。
kubectl create deploy nginx --image=nginx -n paymentsdeployment.apps/nginx created
デプロイメントは正常に作成されましたが、ポッドが存在しません。
➜ ~ kubectl get pods -n payments
No resources found in payments namespace
デプロイメントは作成されましたが、準備完了状態のポッド、更新するポッド、および使用可能なポッドがありません。
➜ ~ kubectl get deploy -n payments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 0/1 0 0 7m4s
さらにデバッグするには、nginx のデプロイメントについて説明します。ポッドの作成に失敗しました:
➜ ~ kubectl describe deploy nginx -n payments
Name: nginx
Namespace: payments
CreationTimestamp: Wed, 24 May 2023 21:37:55 +0300
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx
Replicas: 1 desired | 0 updated | 0 total | 0 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
ReplicaFailure True FailedCreate
Progressing False ProgressDeadlineExceeded
OldReplicaSets: <none>
NewReplicaSet: nginx-8f458dc5b (0/1 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 10m deployment-controller Scaled up replica set nginx-8f458dc5b to 1
Kubernetes イベントからのさらなる分析により、ポッドの作成に必要なメモリが不十分であることが判明しました。
➜ ~ kubectl get events --sort-by=/metadata.creationTimestamp
このエラーは、イメージが正常にプルされ、コンテナーが作成されたものの、ランタイム構成が失敗した場合に発生します。たとえば、動作中の Python アプリケーションが存在しないフォルダーに書き込もうとしている場合、またはフォルダーへの書き込み権限がない場合です。最初にアプリケーションが実行され、その後エラーが発生します。アプリケーション ロジックでパニックが発生すると、コンテナーが停止します。コンテナは CrashLoopBackOff に入ります。最終的に、デプロイメントにポッドがないことがわかります。つまり、ポッドは存在しますが、実行されておらず、CrashLoopbackoff エラーがスローされます。
liveness プローブと readiness プローブが失敗しました
活性検出は、Pod が破損した状態になり、トラフィックを提供できなくなったかどうかを検出します。 Kubernetes がポッドを再起動します。 Readiness プローブは、アプリケーションがトラフィックを処理する準備ができているかどうかを確認します。 Readiness プローブは、アプリケーションが構成マップから必要な構成をすべてフェッチし、スレッドを開始することを保証します。このプロセスを完了した後でのみ、アプリケーションはトラフィックを受信できるようになります。このプロセス中にアプリケーションでエラーが発生した場合も、CrashLoopBackoff に入ります。
トラブルシューティングを開始してください!
この記事では、Kubernetes ポッドのトラブルシューティング手法の概要を説明します。ポッドのデプロイ時に発生する一般的なエラーに対処し、これらのエラーを解決するための実用的なソリューションを提供します。また、Kubernetes の仕組みを理解し、問題を効果的に特定して解決する際に重要なリファレンス ページとチート シートに関する洞察も提供します。この記事で提供されるガイダンスに従うことで、読者はトラブルシューティング スキルを向上させ、Kubernetes ポッドのデプロイと管理を簡素化できます。
私はオープンソース紅蒙を諦めることにしました 、オープンソース紅蒙の父である王成露氏：オープンソース紅蒙は 中国の基本ソフトウェア分野における唯一の建築革新産業ソフトウェアイベントです - OGG 1.0がリリースされ、ファーウェイがすべてのソースコードを提供します。 Google Readerが「コードクソ山」に殺される Ubuntu 24.04 LTSが正式リリース Fedora Linux 40の正式リリースを前に、 Microsoft開発者ら：Windows 11のパフォーマンスは「ばかばかしいほど悪い」、 馬化騰氏と周宏毅氏が握手し「恨みを晴らす」 有名ゲーム会社が新たな規定を発行：従業員の結婚祝いは10万元を超えてはならない 拼多多は不正競争で有罪判決 賠償金500万元この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。