Kubernetes のトラブルシューティングのためのビジュアル ガイド

ノート。 翻訳。: この記事は、パブリック ドメインで公開されているプロジェクト資料の一部です。 学ぶ8s、企業や個人の管理者が Kubernetes を使用できるようにトレーニングします。 その中で、プロジェクト マネージャーの Daniele Polencic は、K8s クラスター上で実行されているアプリケーションで一般的な問題が発生した場合にとるべき手順について、視覚的な手順を共有しています。

TL;DR: これは、Kubernetes でのデプロイメントのデバッグに役立つ図です。

クラスター内のエラーを見つけて修正するためのフローチャート。 原文（英語）は以下から入手できます。 PDF и 絵として.

アプリケーションを Kubernetes にデプロイする場合、通常、次の XNUMX つのコンポーネントを定義する必要があります。

• 展開 - これは、ポッドと呼ばれる、アプリケーションのコピーを作成するための一種のレシピです。
• カスタマーサービス — ポッド間でトラフィックを分散する内部ロード バランサー。
• 進入 — トラフィックが外部の世界からサービスにどのように到達するかの説明。

以下に簡単な図を示します。

1) Kubernetes では、アプリケーションは内部と外部の XNUMX つのロード バランサー層を介して外部からトラフィックを受信します。

2) 内部バランサーはサービスと呼ばれ、外部バランサーはイングレスと呼ばれます。

3) デプロイメントによりポッドが作成され、それらが監視されます (手動では作成されません)。

単純なアプリケーションを独自にデプロイしたいとします。 こんにちは世界。 その YAML 構成は次のようになります。

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

定義は非常に長いため、コンポーネントが相互にどのように関連しているかについて混乱しやすいです。

たとえば、次のように

• いつポート 80 を使用し、いつ 8080 を使用する必要がありますか?
• 競合しないようにサービスごとに新しいポートを作成する必要がありますか?
• レーベル名は重要ですか? どこでも同じであるべきでしょうか?

デバッグに焦点を当てる前に、XNUMX つのコンポーネントが相互にどのように関係しているかを思い出してください。 導入とサービスから始めましょう。

導入とサービスの関係

驚かれるかもしれませんが、デプロイメントとサービスはまったく関連していません。 代わりに、サービスはデプロイメントをバイパスして、ポッドを直接ポイントします。

したがって、ポッドとサービスが互いにどのように関係しているかに興味があります。 覚えておくべき XNUMX つのこと:

1. セレクター (selector) サービスの場合は、少なくとも XNUMX つのポッド ラベルと一致する必要があります。
2. targetPort 一致している必要があります containerPort ポッド内のコンテナ。
3. port サービスは何でも構いません。 異なるサービスは異なる IP アドレスを持っているため、同じポートを使用できます。

次の図は、上記のすべてをグラフ形式で表したものです。

1) サービスがトラフィックを特定のポッドに転送すると想像してください。

2) ポッドを作成するときは、次のように指定する必要があります。 containerPort ポッド内の各コンテナーに対して:

3) サービスを作成するときは、次のことを指定する必要があります。 port и targetPort. しかし、コンテナへの接続にはどれが使用されるのでしょうか?

4) 経由 targetPort。 一致する必要があります containerPort.

5) コンテナ内でポート 3000 が開いているとします。 targetPort 同じはずです。

YAML ファイルでは、ラベルと ports / targetPort 一致している必要があります：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

ラベルはどうですか track: canary 「展開」セクションの上部にあるのは? 合わせるべきでしょうか？

このラベルはデプロイメント固有であり、サービスがトラフィックをルーティングするために使用されるものではありません。 つまり、削除したり、別の値を割り当てたりすることができます。

セレクターはどうでしょうか matchLabels?

常にポッドのラベルと一致する必要がありますこれは、デプロイメントによってポッドを追跡するために使用されるためです。

正しい編集が行われたと仮定しましょう。 それらを確認するにはどうすればよいですか?

次のコマンドを使用してポッドのラベルを確認できます。

kubectl get pods --show-labels

または、ポッドが複数のアプリケーションに属している場合は、次のようになります。

kubectl get pods --selector any-name=my-app --show-labels

どこ any-name=my-app ラベルです any-name: my-app.

何か困難は残っていますか？

ポッドに接続できる！ これを行うには、次のコマンドを使用する必要があります port-forward kubectlで。 サービスに接続して接続を確認できます。

kubectl port-forward service/<service name> 3000:80

ここに：

• service/<service name> - サービス名; 私たちの場合はそうです my-service;
• 3000 はコンピュータ上で開く必要があるポートです。
• 80 - フィールドで指定されたポート port サービス。

接続が確立されていれば、設定は正しいです。

接続が失敗した場合は、ラベルに問題があるか、ポートが一致していません。

サービスとIngressの関係

アプリケーションへのアクセスを提供する次のステップには、Ingress のセットアップが含まれます。 Ingress は、サービスを見つけて、ポッドを見つけてそこにトラフィックを誘導する方法を知る必要があります。 Ingress は、名前と開いているポートによって必要なサービスを見つけます。

Ingress と Service の説明では、次の XNUMX つのパラメータが一致する必要があります。

1. servicePort Ingress のパラメータは一致する必要があります port サービス中。
2. serviceName Ingress ではフィールドと一致する必要があります name サービス中。

次の図は、ポート接続をまとめたものです。

1) すでにご存知のとおり、サービスは特定の意見を聞きます。 port:

2) Ingress には次のパラメータがあります。 servicePort:

3) このパラメータ (servicePort) は常に一致する必要があります port サービス定義内:

4) サービスでポート 80 が指定されている場合は、次のことが必要です。 servicePort も 80 に等しかった:

実際には、次の行に注意する必要があります。

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

Ingress が実行中かどうかを確認するにはどうすればよいですか?

メソッドを使用できます kubectl port-forwardただし、サービスの代わりに Ingress コントローラーに接続する必要があります。

まず、Ingress コントローラーを使用してポッドの名前を確認する必要があります。

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Ingress ポッドを見つけて (別の名前空間にある可能性があります)、コマンドを実行します。 describeポート番号を確認するには:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最後に、ポッドに接続します。

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

これで、コンピューターのポート 3000 にリクエストを送信するたびに、Ingress コントローラーを使用してポッドのポート 80 に転送されるようになります。 に行くことで http://localhost:3000、アプリケーションによって生成されたページが表示されるはずです。

ポートの概要

どのポートとラベルが一致する必要があるかをもう一度思い出してください。

1. サービス定義内のセレクターはポッドのラベルと一致する必要があります。
2. targetPort 定義ではサービスは一致する必要があります containerPort ポッド内のコンテナ。
3. port 定義では、サービスは何でもかまいません。 異なるサービスは異なる IP アドレスを持っているため、同じポートを使用できます。
4. servicePort イングレスは一致する必要があります port サービスの定義において。
5. サービス名はフィールドと一致する必要があります serviceName イングレスで。

残念ながら、YAML 構成を適切に構築する方法を知るだけでは十分ではありません。

物事がうまくいかない場合はどうなりますか?

ポッドが起動しないか、クラッシュする可能性があります。

Kubernetes でアプリケーションの問題を診断する 3 つのステップ

デプロイメントのデバッグを開始する前に、Kubernetes がどのように機能するかをよく理解する必要があります。

K8s にダウンロードされた各アプリケーションには XNUMX つのコンポーネントがあるため、一番下から始めて特定の順序でデバッグする必要があります。

1. まずポッドが動作していることを確認してから...
2. サービスがポッドにトラフィックを供給しているかどうかを確認してから...
3. Ingress が正しく設定されているかどうかを確認します。

視覚的表現:

1) 問題を根本から探し始める必要があります。 まずポッドにステータスがあることを確認します Ready и Running:

2) ポッドの準備ができている場合 (Ready)、サービスがポッド間でトラフィックを分散するかどうかを確認する必要があります。

3) 最後に、サービスと Ingress の間の接続を分析する必要があります。

1. ポッドの診断

ほとんどの場合、問題はポッドに関連しています。 ポッドが次のようにリストされていることを確認してください Ready и Running。 これは、次のコマンドを使用して確認できます。

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

上記のコマンド出力では、最後のポッドは次のようにリストされています。 Running и Readyただし、他の XNUMX つは当てはまりません。

何が間違っていたのかをどのように理解すればよいでしょうか?

ポッドの診断に役立つコマンドが XNUMX つあります。

1. kubectl logs <имя pod'а> ポッド内のコンテナからログを抽出できます。
2. kubectl describe pod <имя pod'а> ポッドに関連付けられたイベントのリストを表示できます。
3. kubectl get pod <имя pod'а> Kubernetes に保存されているポッドの YAML 構成を取得できます。
4. kubectl exec -ti <имя pod'а> bash ポッド コンテナの XNUMX つで対話型コマンド シェルを起動できます。

どれを選ぶべきですか?

実際のところ、普遍的なコマンドは存在しません。 これらを組み合わせて使用​​する必要があります。

典型的なポッドの問題

ポッド エラーには、起動エラーと実行時エラーの XNUMX つの主なタイプがあります。

起動エラー:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

実行時エラー:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

一部のエラーは他のエラーよりも一般的です。 ここでは、最も一般的なエラーとその修正方法をいくつか紹介します。

画像プルバックオフ

このエラーは、Kubernetes がポッド コンテナーの XNUMX つのイメージを取得できない場合に発生します。 その最も一般的な理由は次の XNUMX つです。

1. 画像の名前が間違っています。たとえば、画像を間違えたか、画像が存在しません。
2. 存在しないタグが画像に指定されました。
3. イメージはプライベート レジストリに保存されており、Kubernetes にはそれにアクセスする権限がありません。

最初の XNUMX つの理由は簡単に排除できます。イメージ名とタグを修正するだけです。 後者の場合、Secret に閉じられたレジストリの認証情報を入力し、ポッドにそのレジストリへのリンクを追加する必要があります。 Kubernetes ドキュメント内 例があります どのようにしてこれができるのか。

クラッシュ ループ バックオフ

Kubenetes がエラーをスローする CrashLoopBackOffコンテナが起動できない場合。 これは通常、次の場合に発生します。

1. アプリケーションには起動を妨げるバグがあります。
2. コンテナ 正しく構成されていない;
3. Liveness テストが何度も失敗しました。

失敗の理由を調べるには、コンテナからログにアクセスする必要があります。 コンテナーの再起動が速すぎるためにログにアクセスすることが難しい場合は、次のコマンドを使用できます。

kubectl logs <pod-name> --previous

コンテナの前の状態からのエラー メッセージが表示されます。

RunContainerError

このエラーは、コンテナーの起動に失敗した場合に発生します。 アプリケーションが起動される直前の瞬間に相当します。 これは通常、次のような誤った設定が原因で発生します。

• ConfigMap や Secrets などの存在しないボリュームをマウントしようとしました。
• 読み取り専用ボリュームを読み取り/書き込みとしてマウントしようとします。

チームはそのようなエラーを分析するのに適しています kubectl describe pod <pod-name>.

ポッドは保留状態です

ポッドは作成されると、その状態のままになります。 Pending.

なぜこれが起こっているのですか？

考えられる理由は次のとおりです (スケジューラーが正常に動作していると想定しています)。

1. クラスターには、ポッドを実行するための十分なリソース (処理能力やメモリなど) がありません。
2. オブジェクトは適切な名前空間にインストールされます ResourceQuota ポッドを作成すると、名前空間がクォータを超えてしまいます。
3. ポッドは保留中にバインドされています PersistentVolumeClaim.

この場合、コマンドを使用することをお勧めします kubectl describe そしてセクションを確認してください Events:

kubectl describe pod <pod name>

関連するエラーの場合 ResourceQuotas、コマンドを使用してクラスターのログを表示することをお勧めします。

kubectl get events --sort-by=.metadata.creationTimestamp

ポッドの準備ができていません

ポッドが次のようにリストされている場合 Running状態ではありませんが、 Ready、準備が整っているかどうかを確認することを意味します (レディネスプローブ) 失敗します。

これが発生すると、ポッドはサービスに接続せず、そこにトラフィックが流れなくなります。 準備テストの失敗は、アプリケーションの問題が原因で発生します。 この場合、エラーを見つけるには、セクションを分析する必要があります。 Events コマンド出力で kubectl describe.

2. サービス診断

ポッドが次のようにリストされている場合 Running и Ready, それでもアプリケーションからの応答がない場合は、サービスの設定を確認する必要があります。

サービスは、ラベルに応じてポッドにトラフィックをルーティングする責任があります。 したがって、最初に行う必要があるのは、サービスで動作するポッドの数を確認することです。 これを行うには、サービス内のエンドポイントを確認します。

kubectl describe service <service-name> | grep Endpoints

エンドポイントは次の形式の値のペアです。 <IP-адрес:порт>であり、少なくとも XNUMX つのそのようなペアが出力に存在する必要があります (つまり、少なくとも XNUMX つのポッドがサービスで動作します)。

If セクション Endpoins 空の場合は、次の XNUMX つのオプションが可能です。

1. 正しいラベルを持つポッドがありません (ヒント: 名前空間が正しく選択されているかどうかを確認してください)。
2. セレクタ内のサービスラベルに誤りがあります。

エンドポイントのリストが表示されてもアプリケーションにアクセスできない場合、おそらく原因は次のバグです。 targetPort サービスの説明に記載されています。

サービスの機能を確認するにはどうすればよいですか?

サービスの種類に関係なく、次のコマンドを使用できます。 kubectl port-forward それに接続するには:

kubectl port-forward service/<service-name> 3000:80

ここに：

• <service-name> - サービス名;
• 3000 はコンピュータ上で開くポートです。
• 80 - サービス側のポート。

3. イングレス診断

ここまで読んだ方は次のことを行ってください。

• ポッドは次のようにリストされます Running и Ready;
• サービスはトラフィックをポッド間で正常に分散します。

ただし、依然としてアプリにアクセスできません。

これは、Ingress コントローラーが正しく構成されていない可能性が高いことを意味します。 Ingress コントローラーはクラスター内のサードパーティ コンポーネントであるため、そのタイプに応じて異なるデバッグ方法があります。

ただし、特別なツールを使用して Ingress を構成する前に、非常に簡単な操作を行うことができます。 イングレスでの使用 serviceName и servicePort サービスに接続します。 正しく構成されているかどうかを確認する必要があります。 これは、次のコマンドを使用して実行できます。

kubectl describe ingress <ingress-name>

If 列 Backend 空の場合、構成エラーの可能性が高くなります。 バックエンドが配置されているにもかかわらずアプリケーションにアクセスできない場合、問題は次のことに関連している可能性があります。

• 公共のインターネットからのイングレス アクセシビリティ設定。
• パブリックインターネットからクラスターのアクセシビリティ設定を変更します。

Ingress ポッドに直接接続することで、インフラストラクチャの問題を特定できます。 これを行うには、まず Ingress Controller ポッドを見つけます (別の名前空間にある場合があります)。

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

コマンドを使用する describeポートを設定するには:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

最後に、ポッドに接続します。

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

これで、コンピューター上のポート 3000 へのすべてのリクエストがポッドのポート 80 にリダイレクトされます。

今は機能しますか？

• 「はい」の場合、問題はインフラストラクチャにあります。 トラフィックがクラスターにどのようにルーティングされるかを正確に調べる必要があります。
• そうでない場合は、Ingress コントローラーに問題があります。

Ingress コントローラーを動作させることができない場合は、デバッグする必要があります。

Ingress コントローラーにはさまざまな種類があります。 最も人気のあるものは、Nginx、HAProxy、Traefik などです。 (既存のソリューションの詳細については、「 私たちのレビュー — 約翻訳） 関連するコントローラのドキュメントにあるトラブルシューティング ガイドを参照してください。 なぜなら Ingress Nginx は最も人気のある Ingress コントローラーです。この記事には、それに関連する問題を解決するためのヒントがいくつか含まれています。

Ingress Nginx コントローラーのデバッグ

Ingress-nginx プロジェクトには公式の kubectl 用プラグイン。 チーム kubectl ingress-nginx 次の用途に使用できます。

• ログ、バックエンド、証明書などの分析。
• Ingress への接続。
• 現在の構成を検討中です。

次の XNUMX つのコマンドはこれに役立ちます。

• kubectl ingress-nginx lint — 小切手 nginx.conf;
• kubectl ingress-nginx backend — バックエンドを探索します（と同様） kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — ログをチェックします。

場合によっては、フラグを使用して Ingress コントローラーの正しい名前空間を指定する必要があることに注意してください。 --namespace <name>.

サマリー

どこから始めればよいか分からない場合、Kubernetes のトラブルシューティングは困難になる可能性があります。 問題には常にボトムアップで取り組む必要があります。ポッドから始めて、サービスと Ingress に進みます。 この記事で説明するデバッグ手法は、次のような他のオブジェクトにも適用できます。

• アイドル ジョブと Cron ジョブ。
• StatefulSet と DaemonSet。

感謝の意を表します ゲルゲリー・リスコ, ダニエル・ワイベル и チャールズ・クリスティラージ 貴重なコメントや追加をお待ちしております。

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes ポッドでデバッグするための kubectl-debug プラグイン";
• «Kubernetes の運用における 6 つの興味深いシステム バグ [およびその解決策]";
• «Kubernetes 上で実行されるアプリケーションの開発者向けのツール";
• «SRE の日常生活から得た 6 つの実践的なストーリー '。

出所： habr.com