Kubernetesクラスタは、コンテナイメージをプルしようとしているときにいくつかの問題が発生する可能性があります。エラーが発生すると、ポッドはImagePullBackOffに入ります 州。この一般的だが不可解なメッセージをデバッグして、サービスをオンラインで利用できるようにする方法は次のとおりです。
Kubernetesは、新しいデプロイを作成するとき、または既存のデプロイを別のタグ参照で更新するときに、イメージをフェッチする必要があります。イメージをプルする責任は、各ワーカーノードのKubeletプロセスにあります。ポッドのマニフェストによって参照されるすべての画像は、クラスタ内のすべてのノードにアクセスできる必要があります。これにより、ノードのいずれかがコンテナのスケジューリング要求を満たすことができます。
画像パスが正しくない場合、認証が不適切な場合、またはネットワークがダウンしている場合は、ダウンロードが失敗する可能性があります。これが発生すると、Kubernetesは「プルバック」し、別のダウンロード試行をスケジュールします。次のプルまでの遅延は、試行が失敗するたびに指数関数的に増加し、最大5分になります。
ポッドにImagePullBackOffが表示されている場合 状態では、Kubernetesは複数の連続したイメージプルの失敗を経験しており、再試行する前に待機しています。イメージが利用可能になるまで、コンテナは起動できません。
問題がネットワークの状態または別の一時的なエラーが原因であることがわかっている場合は、ポッドをこの状態のままにしておくことができます。 Kubernetesは最終的に別の再試行を完了し、イメージを正常に取得します。そうでない場合は、ポッドを起動できるようにデバッグを開始する方法を次に示します。
まず第一に、非常に基本的なことを確認する価値があります。リソースマニフェストは、実際に存在する有効な画像を参照していますか？単純なタイプミスがないか、レジストリパスとイメージタグを確認してください。
describe podを使用して、Kubernetesの内部状態を調べることができます。 Kubectlのコマンド。これにより、get podよりも多くの情報が得られます とKubernetesダッシュボードが提供します。
kubectl describe pod my-pod --namespace my-namespace
ポッドのライフサイクルの変更は、「イベント」の見出しの下に表示されます。最初のイベントはScheduledになります;その後にPullingを続ける必要があります 最初のプル試行のイベント。この後、Failedが表示されます またはBackOff プルが成功しなかった場合のイベント。 Kubernetesがまだバックオフして再試行サイクルにある場合、これらはリストの後半で繰り返されます。
Messageを読む これらのイベントに関連付けられていることが、問題の根本的な原因となることがよくあります。 manifest for image:tag not foundのマニフェスト メッセージは、画像は有効ですが、無効なタグを指定したことを意味します。 does not exist or no pull accessが表示された場合 、レジストリとイメージパスが正しいことを確認してください。それらが正しいと確信できる場合、問題は誤った認証に関連しています。
プライベートイメージをプルする前に、ログインする必要があります。 Kubernetesでは、これは2段階のメカニズムです。クレデンシャルを含むシークレットを作成し、ポッド定義でそのシークレットを参照します。
ポッドフィールドはimagePullSecretsと呼ばれます 。レジストリにログイントークンを提供するKubernetesシークレットを示す必要があります。このシークレットには、Docker互換のJSON値を保存する必要があります。
apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
name: image-pull-secret
data:
.dockerconfigjson: {{ "{"auths": {"registry.example.com": {"username": "demo-user", "password": "my-password"}}}" | b64enc }}
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: registry.example.com/my-image:latest
imagePullSecrets:
- name: image-pull-secret
このマニフェストは、registry.example.comにログインするシークレットを作成する方法を示しています demo-userとして パスワードmy-passwordを使用 。ポッドはその名前で秘密を参照します。クラスタのノード上のKubeletプロセスには、Docker config.jsonが含まれます レジストリから画像を取得するときのスニペット。
有効なKubernetesシークレット値であるためには、スニペットをBase64でエンコードする必要があります。事前にエンコードされた値を使用するか、YAMLのb64encを介してプレーンテキストをパイプすることができます 、上記のマニフェストに示されているように。
使用する資格情報の種類は、レジストリによって異なります。多くの場合、password 実際には、個人用アクセストークンまたはAPIキーになります。アカウントで2要素認証を有効にしている場合、DockerHubではアカウント設定で生成されたアクセストークンが必要です。
レジストリのURL、画像タグ名、ログイン資格情報を確認した場合は、ImagePullBackOffが表示されている可能性があります レジストリレートの制限のため。 Docker Hubでは、6時間ごとに100個のコンテナープルに制限されるようになりました。ログインクレデンシャルを指定すると、これは6時間あたり200プルに増加します。頻繁に展開されるポッドが多数あるアクティブなクラスターでは、この上限にすぐに達する可能性があります。
レート制限によるプルの失敗は、認証の問題と同じように現れます。上限が切れるのに十分な時間が経過するまで待つ必要があります。その後、Kubernetesは画像を正常にプルし、ポッドを表示します。
長期的な緩和策として、独自のクラスター内レジストリまたはプロキシを実行してイメージをキャッシュすることを検討してください。これにより、Dockerのサーバーにアクセスする頻度を大幅に減らすことができ、レート制限内にとどまることができます。
KubernetesポッドはImagePullBackOffを入力します ノードがイメージのプルに失敗したときの状態。 Kubeletは定期的にプルを再試行するため、一時的なエラーに対処するために手動で介入する必要はありません。
ImagePullBackOffが確実な場合 単なる一時的なブリップではありません。まず、ポッドの画像パスが有効であることを確認します。それがチェックアウトする場合は、間違ったログイン資格情報または使い果たされたレート制限許容値を疑ってください。 kubectl describeを使用する 失敗につながった一連のイベントを公開します。
最後のオプションとして、別のマシンから自分でイメージをプルして、リモートレジストリサーバーが実際に稼働していることを確認できます。イメージをプルできるがクラスタがプルできない場合は、より一般的なネットワークの問題が発生し、ノードがレジストリに到達できない可能性があります。