AKS לא יכול למשוך תמונה מ-registry פרטי מאחורי ה-VPN
ה-kubelet מושך דרך רשת ה-node, לא דרך ה-VPN של ה-pod. הכריעו לפי המסלולים של ה-node, ה-DNS שלו, כל endpoint שהמשיכה נוגעת בו, ואז TLS וזהות.
המחשב הנייד שלך מושך את התמונה בלי בעיה, אבל ה-pod נשאר ב-ImagePullBackOff. הצעה להריץ את לקוח ה-VPN הארגוני כ-sidecar לא תעזור, כי המשיכה מתרחשת לפני שהקונטיינר קיים: ה-kubelet מבקש מה-container runtime שעל ה-node להביא את התמונה, וה-runtime משתמש ברשת של ה-node.
סדר הפעולות קובע את השכבה
קודם מפענחים את שם ה-registry, מתחברים, מאמתים ומורידים שכבות, ורק אז מפעילים את הקונטיינר. כל מה שה-pod עושה עם VPN קורה אחרי הרצף הזה, ולכן מנהרה שעובדת באשכול אינה הוכחה לגבי המשיכה.
לכן תמונה מה-cache משכנעת כל כך: node שמשך אותה לפני שבועות ממשיך להגיש אותה, וה-deployment נראה בריא עד שהמתזמן מציב replica על node חדש יותר. אם ציר הזמן כולל scale-up או החלפת node, אלה טריגר ולא סיבה.
שלושה תנאים קובעים את התיקון
הנגישות ל-registry פרטי תלויה בניתוב, בפתרון שמות ובקבוצת ה-endpoint. בלי ניתוב לרשת ה-registry שום אישור לא יעזור; בלי פענוח שם דרך ה-DNS של ה-node החיבור לא יתחיל; ואם רק ה-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 peering לבדו אינו נותן כל תצורת gateway transit, ומסלול בכיוון אחד אינו מסלול שעובד. נדרש נתיב נתמך דרך ה-VPN gateway המיועד, ומסלול חזרה בצד ה-registry.
קראו את הכשל לפני בחירת תיקון
התחילו באירועי ה-pod וב-node שאליו נחת, עם השמות האמיתיים שלכם: kubectl describe pod app-example -n team-example ו-kubectl get pod app-example -n team-example -o wide. האירוע מבדיל בין שם מארח שלא נפתר ל-timeout, בין דחיית תעודה לתמונה חסרה, ובין כשל הרשאה לכל אלה.
אימות הוא המנוף המוערך מדי. imagePullSecret נותן אישורי registry ל-runtime; הוא אינו מתקין מסלול, אינו משנה את ה-resolver ואינו מכשיר תעודה לא מהימנה. אם האירוע אומר שהמשיכה לא אושרה, בדקו את הזהות; אם החיבור פג, האישורים אינם רלוונטיים.
תיעוד התמונות של Kubernetes הוא המקור להתנהגות המשיכה ולאישורי registry פרטי, וכדאי לקרוא אותו לפני שינוי הרשת, כי הוא מבהיר את הגבול בין אימות לתעבורה.
בנו את הנתיב מתחת ל-pod
עבדו בסדר הזה, כי כל שלב חסר משמעות עד שהקודם מתקיים. תחילה נתבו את רשת ה-node: בדקו את המסלולים האפקטיביים, את כללי האבטחה בשני הקצוות ואת מסלול החזרה בצד ה-registry.
פתרו את השם מההקשר של ה-node. ה-resolver שלו אינו תצורת ה-DNS של ה-pod, והצלחה בתוך pod אינה הוכחה לגבי ה-runtime של המארח. השתמשו ב-DNS פרטי מנוהל ולא ברשומת hosts קבועה, שנעלמת בשקט לאחר החלפת ה-node.
הוכיחו כל endpoint. registry יכול להפנות לאימות נפרד ולאחסון blob נפרד. הגעה ל-endpoint של ה-manifest אינה מוכיחה דבר על השכבות. השלימו TLS והרשאה: תעודה תקפה לשם ה-registry וזהות משיכה מוגבלת לקריאת אותו מאגר.
אמתו זאת על node שלא תיקנתם ביד
המבחן הקובע הוא משיכה חדשה והורדה מלאה של כל השכבות על node מתאים, כזה שנוצר ב-scale או בהחלפה. זה מכסה את כל ה-pool שעשויים לשבץ את ה-workload, גם אלו ששכחתם. תיקון ידני על node אחד אינו מודל פריסה.
יצירת האשכול מחדש ב-VNet אחרת היא המוצא האחרון ולא צעד האבחון הראשון. השוו את הרשת הקיימת למסלול הפרטי הנדרש ולבקרות הנתמכות, והפרידו בין קישוריות האפליקציה לבדיקת הורדת התמונה.