AKS nie może pobrać obrazu z prywatnego registry za VPN
kubelet pobiera przez sieć node, a nie przez VPN poda. Decyduj po trasach node, DNS node, każdym endpoint, którego dotyka pobieranie, potem TLS i tożsamość.
Twój laptop pobiera obraz bez problemu, ale pod wisi w ImagePullBackOff i ktoś proponuje uruchomienie firmowego klienta VPN jako sidecara. To nie pomoże, bo pobieranie odbywa się, zanim istnieje kontener: kubelet prosi container runtime na node o pobranie obrazu, a runtime korzysta z przestrzeni nazw sieci node.
Kolejność operacji decyduje o warstwie
Najpierw rozwiązywanie nazwy, potem połączenie, uwierzytelnienie, pobranie warstw i dopiero start kontenera. Wszystko, co pod robi z VPN, dzieje się później, więc działający tunel w klastrze nie jest dowodem w sprawie pobierania.
Dlatego obraz z cache jest tak przekonującym kłamstwem: node, który pobrał go tygodnie temu, nadal go serwuje, deployment wygląda zdrowo, a awaria pojawia się dopiero, gdy scheduler umieści replikę na nowszym node. scale-up lub wymiana node to wyzwalacz, nie przyczyna.
Trzy warunki decydują o naprawie
Dostępność sprowadza się do routingu, rozwiązywania nazw i zestawu endpointów. Jeśli podsieć node nie może routować do sieci registry, żadne dane logowania nie pomogą. Jeśli nazwa nie rozwiązuje się przez DNS node, połączenie nie zacznie się. Jeśli działa tylko manifest, a blob nie, pobieranie załamie się w połowie.
| 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 |
Sam VNet peering nie daje wszystkich układów gateway transit, a trasa w jedną stronę nie jest trasą działającą. Node potrzebuje obsługiwanej ścieżki przez docelowy VPN gateway, a strona registry trasy powrotnej do podsieci node.
Przeczytaj błąd, zanim wybierzesz naprawę
Zacznij od zdarzeń poda i node, na którym wylądował, z prawdziwymi nazwami: kubectl describe pod app-example -n team-example i kubectl get pod app-example -n team-example -o wide. Treść zdarzenia odróżnia nierozwiązaną nazwę od timeoutu, odrzucenie certyfikatu od brakującego obrazu i błąd autoryzacji od tego wszystkiego.
Uwierzytelnianie to najbardziej przeceniana dźwignia. imagePullSecret daje runtime dane logowania do registry; nie instaluje trasy, nie zmienia resolvera node i nie czyni niezaufanego certyfikatu ważnym. Jeśli zdarzenie mówi, że pobieranie nie było autoryzowane, sprawdź zakres tożsamości; jeśli mówi, że połączenie wygasło, dane logowania są nieistotne.
Dokumentacja Kubernetes o obrazach to źródło o zachowaniu pobierania i danych logowania do prywatnych registry, i warto ją raz przeczytać przed zmianą sieci, bo jasno pokazuje granicę między uwierzytelnianiem a transportem.
Zbuduj ścieżkę pod podem
Pracuj w tej kolejności. Najpierw routuj sieć node: potwierdź, że podsieć ma obsługiwaną ścieżkę do sieci registry, sprawdź efektywne trasy na node, reguły bezpieczeństwa po obu stronach i trasę powrotną po stronie registry.
Potem rozwiąż nazwę z kontekstu node. Resolver node to nie konfiguracja DNS poda, a sukces wewnątrz poda nie jest dowodem dla runtime hosta. Używaj zarządzanego prywatnego DNS zamiast stałego wpisu w hosts; wpis żyje do wymiany node, a potem po cichu znika.
Potem udowodnij każdy endpoint. Registry może dać klientowi osobną usługę uwierzytelniania i osobny magazyn blob. Dotarcie do manifestu nie dowodzi prawie niczego o warstwach. Na koniec dokończ TLS i autoryzację: certyfikat ważny dla nazwy registry i zaufany przez obsługiwaną konfigurację node oraz tożsamość pobierania ograniczona do czytania tego repozytorium.
Sprawdź na node, którego nie naprawiałeś ręcznie
Prawdziwy test to świeże pobranie i pełne ściągnięcie wszystkich warstw na odpowiednim node, najlepiej utworzonym przez skalowanie lub wymianę. To pokrywa wszystkie pule, które mogą umieścić workload, także zapomniane. Ręczna naprawa na jednym node to nie model wdrożenia, a następne zdarzenie autoskalowania znajdzie lukę.
Odtworzenie klastra w innym VNet może zmienić ścieżkę, ale to ostateczność, a nie pierwszy krok diagnostyczny. Porównaj istniejącą sieć node z wymaganą trasą prywatną i obsługiwanymi mechanizmami sieci AKS, zanim zaproponujesz migrację, i trzymaj łączność aplikacji po starcie jako osobną weryfikację: rozmowa poda z backendem to inna kontrola niż pobieranie obrazu przez node.