Komputer riba anda menarik imej tanpa masalah, tetapi pod kekal dalam ImagePullBackOff dan seseorang mencadangkan menjalankan klien VPN korporat sebagai sidecar. Itu tidak membantu, kerana tarikan berlaku sebelum kontena anda wujud: kubelet meminta container runtime pada node mengambil imej, dan runtime menggunakan namespace rangkaian node.

Urutan operasi menentukan lapisan

Pertama resolusi nama, kemudian sambungan, pengesahan, muat turun lapisan, dan barulah kontena dimulakan. Semua yang pod lakukan dengan VPN berlaku selepas urutan itu, jadi terowong yang berfungsi dalam kluster bukan bukti tentang tarikan.

Sebab itu imej dalam cache ialah pembohongan yang meyakinkan: node yang menarik imej berminggu lalu terus menyajikannya, deployment kelihatan sihat, dan kegagalan hanya muncul apabila penjadual meletakkan replika pada node yang lebih baharu. scale-up atau penggantian node ialah pencetus, bukan punca.

Tiga syarat menentukan pembaikan

Kebolehcapaian bergantung pada penghalaan, resolusi nama dan set endpoint. Jika subnet node tidak boleh menghalakan ke rangkaian registry, tiada kelayakan membantu. Jika nama tidak diselesaikan melalui DNS node, sambungan tidak bermula. Jika hanya manifest tercapai tetapi blob tidak, tarikan gagal di tengah jalan.

ConditionTypical symptomWhere to look
Node subnet has no route to the registry networkTimeout, no connectionEffective routes on the node NIC, gateway transit, return path on-premises
Node resolver cannot see the private zoneName resolution failure in eventsVNet DNS settings and the resolver the node actually uses
Only the manifest endpoint is reachableAuth succeeds, layer download failsEvery hostname the registry hands out during the pull
TLS or identity is wrongCertificate error, 401 or 403Server certificate name and trust, scoped pull identity

VNet peering sahaja tidak memberikan semua susunan gateway transit, dan laluan satu arah bukan laluan yang berfungsi. Node memerlukan laluan disokong melalui VPN gateway yang dimaksudkan, dan pihak registry memerlukan laluan balik ke subnet node.

Baca kegagalan sebelum memilih pembaikan

Mulakan dengan peristiwa pod dan node tempat ia mendarat, dengan nama sebenar anda: kubectl describe pod app-example -n team-example dan kubectl get pod app-example -n team-example -o wide. Teks peristiwa membezakan nama hos tidak diselesaikan daripada timeout, penolakan sijil daripada imej hilang, dan kegagalan kebenaran daripada semuanya.

Pengesahan ialah tuas yang paling terlebih nilai. imagePullSecret memberikan runtime kelayakan registry; ia tidak memasang laluan, tidak menukar resolver node dan tidak menjadikan sijil tidak dipercayai sah. Jika peristiwa menyatakan tarikan tidak dibenarkan, lihat skop identiti; jika ia menyatakan sambungan tamat masa, kelayakan tidak relevan.

Dokumentasi imej Kubernetes ialah rujukan untuk tingkah laku tarikan dan kelayakan registry peribadi, dan wajar dibaca sekali sebelum menukar rangkaian, kerana ia menjelaskan sempadan antara pengesahan dan pengangkutan.

Bina laluan di bawah pod

Bekerja dalam urutan ini. Mula-mula halakan rangkaian node: sahkan subnet mempunyai laluan disokong ke rangkaian registry, semak laluan berkesan pada node, peraturan keselamatan di kedua-dua hujung dan laluan balik di pihak registry.

Kemudian selesaikan nama dari konteks node. Resolver node bukan konfigurasi DNS pod, dan kejayaan dalam pod bukan bukti tentang runtime hos. Gunakan DNS peribadi terurus dan bukan entri hosts kekal; entri itu hidup sehingga node diganti dan kemudian hilang secara senyap.

Kemudian buktikan setiap endpoint. Registry boleh memberikan klien perkhidmatan pengesahan berasingan dan storan blob berasingan. Mencapai manifest hampir tidak membuktikan apa-apa tentang lapisan. Akhir sekali lengkapkan TLS dan kebenaran: sijil sah untuk nama registry dan dipercayai melalui konfigurasi node yang disokong, serta identiti tarikan terhad kepada membaca repositori itu.

Sahkan pada node yang tidak anda baiki secara manual

Ujian yang bermakna ialah tarikan baharu dan muat turun penuh semua lapisan pada node yang sesuai, sebaiknya yang dicipta melalui penskalaan atau penggantian. Ia meliputi semua pool yang boleh meletakkan workload, termasuk yang terlupa. Pembaikan manual pada satu node bukan model penggunaan, dan peristiwa autoscale seterusnya akan menemui jurang itu.

Mencipta semula kluster dalam VNet lain boleh mengubah laluan, tetapi itu jalan terakhir dan bukan langkah diagnostik pertama. Bandingkan rangkaian node sedia ada dengan laluan peribadi yang diperlukan dan kawalan rangkaian AKS yang disokong sebelum mencadangkan migrasi, dan kekalkan ketersambungan aplikasi selepas permulaan sebagai pengesahan berasingan: pod yang bercakap dengan backendnya ialah pemeriksaan berbeza daripada node yang memuat turun imej.

Artikel berkaitan