VPN 뒤 프라이빗 registry에서 AKS가 이미지를 받지 못할 때
kubelet은 Pod의 VPN이 아니라 노드 네트워크로 이미지를 받습니다. 노드 라우트, 노드 DNS, 이미지 받기가 닿는 모든 endpoint, 그다음 TLS와 ID로 판단하세요.
노트북에서는 이미지를 잘 받는데 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 이벤트와 그 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의 통신은 노드의 이미지 다운로드와 다른 확인입니다.