AKS tidak bisa menarik image dari registry privat di balik VPN Anda
kubelet menarik lewat jaringan node, bukan lewat VPN pod. Putuskan berdasarkan rute node, DNS node, setiap endpoint yang disentuh penarikan, lalu TLS dan identitas.
Laptop Anda menarik image tanpa masalah, tetapi pod tertahan di ImagePullBackOff, dan seseorang mengusulkan menjalankan klien VPN korporat sebagai sidecar. Itu tidak akan membantu, karena penarikan terjadi sebelum container Anda ada: kubelet meminta container runtime di node mengambil image, dan runtime memakai namespace jaringan node. VPN di dalam workload tidak punya rute untuk jalur itu, dan image pembantunya sendiri harus ditarik lebih dulu.
Urutan operasi menentukan lapisannya
Pertama resolusi nama image. kubelet lewat runtime menyelesaikan nama registry, menyambung, mengautentikasi, mengunduh lapisan, dan baru setelah itu menjalankan container. Semua yang pod lakukan dengan VPN terjadi setelah urutan itu, jadi tunnel yang berfungsi di klaster bukan bukti soal penarikan.
Karena itu image yang ter-cache adalah kebohongan yang meyakinkan. Node yang menarik image berminggu-minggu lalu terus menyajikannya, deployment tampak sehat, dan kegagalan baru muncul saat penjadwal menempatkan replika di node yang lebih baru. Jika lini masa peristiwa memuat scale-up, penggantian node, atau peningkatan pool, perlakukan sebagai pemicu, bukan penyebab.
Tiga kondisi menentukan perbaikannya
Keterjangkauan registry privat dari node pool terkelola bergantung pada perutean, resolusi nama, dan himpunan endpoint. Jika subnet node tidak bisa merutekan ke jaringan registry, tidak ada kredensial yang menolong. Jika bisa merutekan tetapi nama registry tidak terselesaikan lewat jalur DNS node, koneksi tidak pernah dimulai. Jika keduanya berhasil untuk endpoint manifest tetapi tidak untuk endpoint blob yang dituju registry, penarikan gagal di tengah.
| 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 |
Peering VNet saja tidak otomatis memberi semua susunan gateway transit, dan rute yang ada di satu arah bukan rute yang berfungsi. Node butuh jalur yang didukung lewat VPN gateway yang dimaksud atau perangkat yang disetujui, dan sisi registry butuh rute balik ke subnet node.
Baca kegagalan sebelum memilih perbaikan
Mulailah dari peristiwa pod dan node tempat ia mendarat, dengan nama asli Anda: kubectl describe pod app-example -n team-example dan kubectl get pod app-example -n team-example -o wide. Teks peristiwa memisahkan nama host yang tak terselesaikan dari timeout, penolakan sertifikat dari image yang hilang, dan kegagalan otorisasi dari semuanya.
Autentikasi adalah tuas yang paling dilebih-lebihkan. imagePullSecret memberi runtime kredensial registry; ia tidak memasang rute, tidak mengubah resolver node, dan tidak membuat sertifikat tak tepercaya menjadi sah. Jika peristiwa menyebut penarikan tidak diotorisasi, periksa cakupan identitas. Jika menyebut koneksi habis waktu, kredensial tidak relevan.
Dokumentasi image Kubernetes adalah rujukan perilaku penarikan dan kredensial registry privat, dan layak dibaca sekali sebelum mengubah jaringan, karena menegaskan batas antara autentikasi dan transportasi.
Bangun jalur di bawah pod
Bekerjalah dalam urutan ini. Rutekan dulu jaringan node: pastikan subnet punya jalur yang didukung ke jaringan registry, periksa rute efektif di node, aturan keamanan di kedua ujung, dan rute balik di sisi registry.
Lalu selesaikan nama dari konteks node. Resolver node bukan konfigurasi DNS pod, dan keberhasilan di dalam pod bukan bukti soal runtime host. Gunakan DNS privat terkelola alih-alih entri hosts permanen; entri itu bertahan sampai node diganti lalu menghilang diam-diam.
Lalu buktikan setiap endpoint. Registry bisa memberi layanan autentikasi terpisah dan penyimpanan blob terpisah. Mencapai endpoint manifest hampir tidak membuktikan apa pun soal lapisan. Terakhir selesaikan TLS dan otorisasi: sertifikat yang sah untuk nama registry dan tepercaya lewat konfigurasi node yang didukung, plus identitas penarikan yang dibatasi membaca repositori itu.
Verifikasi di node yang tidak Anda perbaiki manual
Uji yang bermakna adalah penarikan baru dan unduhan penuh semua lapisan di node yang layak, idealnya yang dibuat oleh penskalaan atau penggantian. Itu mencakup semua pool yang bisa menempatkan workload, termasuk yang terlupa. Perbaikan manual di satu node bukan model penerapan, dan peristiwa autoscale berikutnya akan menemukan celahnya.
Membuat ulang klaster di VNet lain bisa mengubah jalur, tetapi itu upaya terakhir, bukan langkah diagnosis pertama. Bandingkan jaringan node yang ada dengan rute privat yang dibutuhkan dan kontrol jaringan AKS yang didukung sebelum mengusulkan migrasi, dan jaga konektivitas aplikasi setelah mulai sebagai verifikasi terpisah: pod yang berbicara dengan backend-nya adalah pemeriksaan berbeda dari node yang mengunduh image.