VPN の内側にあるプライベート registry から AKS がイメージを取得できない
kubelet は Pod の VPN ではなくノードのネットワーク経由で取得します。ノードのルート、ノードの DNS、取得が触れる各 endpoint、そして TLS と ID で判断してください。
手元のノート PC ではイメージを取得できるのに、Pod は ImagePullBackOff のままです。VPN クライアントを sidecar で動かす案は無意味です。取得はコンテナが存在する前に起き、kubelet がノード上の container runtime に取得を指示し、runtime はノードのネットワーク名前空間を使うからです。
処理の順序が層を決める
まず名前解決があり、接続・認証・レイヤーのダウンロードを経て、ようやくコンテナが起動します。Pod の VPN はすべてその後です。クラスタ内でトンネルが通っていても、取得の証拠にはなりません。
キャッシュされたイメージは説得力のある嘘です。数週間前に取得したノードは配信を続け、Deployment は健全に見え、新しいノードに replica が置かれた瞬間に失敗します。scale-up やノード入れ替えは原因ではなく引き金と捉えてください。
三つの条件が修復を決める
到達性はルーティング、名前解決、endpoint の集合に還元されます。ノードのサブネットが registry のネットワークへルーティングできなければ資格情報は無力です。ノードの DNS で名前が解けなければ接続は始まりません。manifest だけ届いて blob に届かなければ途中で失敗します。
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
VNet ピアリングだけでは gateway transit の構成は揃わず、片方向のルートは機能するルートではありません。ノードには想定した VPN gateway 経由のサポートされた経路が、registry 側にはノードのサブネットへの戻り経路が必要です。
修正を選ぶ前に失敗を読む
Pod のイベントと落ちたノードから始め、実際の名前で確認します: kubectl describe pod app-example -n team-example と kubectl get pod app-example -n team-example -o wide。イベント文は名前解決の失敗とタイムアウト、証明書の拒否とイメージ不在、認可の失敗を区別します。
認証は最も過大評価される手段です。imagePullSecret は runtime に registry の資格情報を与えるだけで、ルートを張らず、resolver を変えず、信頼されない証明書を有効にしません。未認可なら ID の範囲を、タイムアウトなら資格情報は無関係です。
Kubernetes のイメージに関するドキュメント は取得動作とプライベート registry の資格情報の一次情報で、ネットワークを変える前に一度読む価値があります。認証と転送の境界が明確になるからです。
Pod の下の経路を作る
この順序で進めます。まずノードのネットワークを通し、サブネットから registry への経路、ノードの実効ルート、両端のセキュリティ規則、registry 側の戻り経路を確認します。
次にノードの文脈で名前を解決します。ノードの resolver は Pod の DNS 設定ではなく、Pod 内の成功はホスト runtime の証拠になりません。恒久的な hosts 追記ではなく管理されたプライベート DNS を使います。追記はノード入れ替えまで残り、その後静かに消えます。
続いて各 endpoint を証明します。registry は認証サービスと blob 保管場所を別に返せます。manifest に届いてもレイヤーは保証されません。最後に TLS と認可を完了します。registry 名に有効でサポートされたノード構成で信頼される証明書と、そのリポジトリの読み取りに限定した取得 ID です。
手作業で直していないノードで検証する
意味のある試験は、適格なノードでの新規取得と全レイヤーの完全ダウンロードです。できれば scale や入れ替えで作られたノードが望ましく、忘れていた pool も含めて網羅できます。一台の手作業修正は運用モデルではなく、次の autoscale で隙間が見つかります。
別の VNet でクラスタを作り直せば経路は変わりますが、それは最初の診断ではなく最後の手段です。移行を提案する前に、既存のノードネットワークを必要なプライベート経路とサポートされる AKS のネットワーク制御と比較し、起動後のアプリ接続は別の検証として扱ってください。Pod と backend の通信は、ノードのイメージ取得とは別の確認です。