AKS VPN arxasındakı özəl registry-dən obraz çəkə bilmir
kubelet obrazı pod-un VPN-i ilə deyil, node şəbəkəsi ilə çəkir. Node marşrutları, node DNS-i, çəkmənin toxunduğu hər endpoint, sonra TLS və kimliklə qərar verin.
Noutbukunuz obrazı problemsiz çəkir, pod isə ImagePullBackOff vəziyyətində qalır və kimsə korporativ VPN müştərisini sidecar kimi işə salmağı təklif edir. Bu kömək etməyəcək, çünki çəkmə konteyneriniz yaranmadan əvvəl baş verir: kubelet node-dakı container runtime-dan obrazı gətirməsini istəyir, runtime isə node-un şəbəkə ad məkanından istifadə edir. workload daxilində VPN bu yola marşrut verə bilməz və onun öz köməkçi obrazı əvvəlcə çəkilməlidir.
Əməliyyatların sırası təbəqəni müəyyən edir
Əvvəlcə obrazın adı həll olunur. kubelet runtime vasitəsilə registry adını həll edir, qoşulur, autentifikasiya edir, təbəqələri endirir və yalnız bundan sonra konteyneri başladır. Pod-un VPN ilə etdiyi hər şey bu ardıcıllıq bitdikdən sonra baş verir, buna görə cluster daxilində işləyən tunel çəkmə barədə sübut deyil.
Buna görə keşlənmiş obraz elə inandırıcı yalançıdır. Obrazı həftələr əvvəl çəkmiş bir node onu verməyə davam edir, deployment sağlam görünür və nasazlıq yalnız scheduler replikanı daha yeni node-a yerləşdirəndə üzə çıxır. Hadisələrin zaman xəttində scale-up, node dəyişdirmə və ya pool yüksəltmə varsa, bunları səbəb deyil, tətikləyici sayın.
Üç şərt təmiri müəyyən edir
İdarə olunan node pool-undan özəl registry-yə çatmaq marşrutlaşdırma, ad həlli və endpoint çoxluğuna bağlıdır. Node alt şəbəkəsi registry şəbəkəsinə marşrut verə bilmirsə, heç bir etimadnamə kömək etməz. Marşrut varsa, lakin node-un DNS yolu ilə registry adını həll edə bilmirsə, bağlantı heç başlamır. Hər ikisi manifest endpoint-i üçün işləyir, amma registry-nin yönləndirdiyi blob endpoint-i üçün işləmirsə, çəkmə yarıda qırılır.
| 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 |
Tək VNet peering sizə bütün gateway-transit variantlarını avtomatik vermir və bir istiqamətdə mövcud olan marşrut işləyən marşrut deyil. Node nəzərdə tutulan VPN gateway və ya təsdiqlənmiş cihaz üzərindən dəstəklənən yol tələb edir, registry tərəfi isə node alt şəbəkəsinə qayıdış marşrutuna ehtiyac duyur.
Düzəlişi seçməzdən əvvəl nasazlığı oxuyun
Pod hadisələrindən və onun düşdüyü node-dan başlayın, öz real adlarınızla: kubectl describe pod app-example -n team-example və kubectl get pod app-example -n team-example -o wide. Hadisə mətnində həll olunmamış host adı timeout-dan, sertifikat rəddi itkin obrazdan, avtorizasiya uğursuzluğu isə hamısından ayrılır. Bu dördün dörd fərqli sahibi var.
Autentifikasiya ən çox şişirdilən rıçaqdır. imagePullSecret runtime-a registry etimadnamələri verir; o, marşrut quraşdırmır, node-un resolverini dəyişmir və etibarsız sertifikatı etibarlı etmir. Hadisə çəkmənin icazəsiz olduğunu deyirsə, kimliyin əhatə dairəsinə baxın. Bağlantının vaxtının bitdiyini deyirsə, etimadnamələr əlaqəsizdir.
Kubernetes obraz sənədləri çəkmə davranışı və özəl registry etimadnamələri üçün mənbədir və şəbəkəni dəyişməzdən əvvəl bir dəfə oxumağa dəyər, çünki autentifikasiya ilə nəql arasındakı sərhədi aydın göstərir.
Yolu pod-un altında qurun
Bu sıra ilə işləyin, çünki əvvəlki addım yerinə yetməyəndə hər növbəti mənasızdır. Əvvəlcə node şəbəkəsini marşrutlaşdırın: node alt şəbəkəsinin registry şəbəkəsinə dəstəklənən yolu olduğunu təsdiqləyin, node-dakı effektiv marşrutları, hər iki tərəfin təhlükəsizlik qaydalarını və registry tərəfində qayıdış marşrutunu yoxlayın.
Sonra adı node-un kontekstindən həll edin. Node-un resolveri pod-un DNS konfiqurasiyası deyil və pod daxilində uğur host runtime üçün sübut deyil. Daimi hosts faylı qeydi əvəzinə idarə olunan özəl DNS istifadə edin; qeyd node dəyişdirilənə qədər qalır və sonra səssizcə yox olur.
Sonra hər endpoint-i sübut edin. Registry müştəriyə ayrı autentifikasiya xidməti və ayrı blob saxlama yeri verə bilər. manifest endpoint-inə çatmaq təbəqələr barədə demək olar ki, heç nə sübut etmir. Sonda TLS və avtorizasiyanı tamamlayın: registry adı üçün etibarlı və dəstəklənən node konfiqurasiyası ilə etimad qazanmış sertifikat, həmçinin həmin repozitoriyanı oxumaqla məhdud çəkmə kimliyi.
Əl ilə təmir etmədiyiniz node-da yoxlayın
Sayılan sınaq uyğun node-da təzə çəkmə və bütün təbəqələrin tam endirilməsidir, ən yaxşısı scale və ya dəyişdirmə ilə yaradılmış node. Bu, workload-u yerləşdirə biləcək bütün pool-ları, unutduqlarınız da daxil olmaqla əhatə edir. Bir node-da əl ilə düzəliş deployment modeli deyil və növbəti avtomatik scale hadisəsi boşluğu tapacaq.
Cluster-i başqa VNet-də yenidən qurmaq yolu dəyişə bilər, lakin bu ilk diaqnostik addım deyil, son çıxış yoludur. Miqrasiya təklif etməzdən əvvəl mövcud node şəbəkəsini tələb olunan özəl marşrut və dəstəklənən AKS şəbəkə nəzarətləri ilə müqayisə edin, başlamadan sonra tətbiq bağlantısını ayrı yoxlama kimi saxlayın: pod-un backend ilə danışması node-un obrazı endirməsindən fərqli yoxlamadır.