minikube לא מגיע ל-API פרטי? בדקו קודם את הדרייבר
למארח, לצומת ול-Pod יש כל אחד נתיבים משלו ו-resolver משלו. תנו שם לדרייבר, בדקו את אותו endpoint מכל השלושה ואז תקנו את ההקשר שנכשל.
API פרטי עונה מהמחשב הנייד שלכם ו-Pod בתוך minikube לא מצליח להגיע אליו. לפני שאתם משנים משהו במארח, תנו שם לדרייבר שמאחורי הפרופיל הפעיל, כי העובדה האחת הזו קובעת מאיזו רשת הבקשה יוצאת בפועל. אחר כך בדקו את אותו endpoint מהמארח, מהצומת ומ-Pod. רק אחד משלושת אלה הוא מה שנכשל, וניחוש שגוי עולה אחר צהריים.
שלב 0: תנו שם לדרייבר ולמקור
שאלו את minikube איזה פרופיל פעיל ואיך הוא פועל. דרייבר קונטיינר מציב את הצומת בקונטיינר במחשב שלכם, דרייבר VM מציב אותו במכונה וירטואלית, ודרייבר מרוחק מציב אותו במקום אחר לגמרי.
minikube profile list
minikube status
kubectl config current-contextמזה, רשמו מאיפה הבקשה מגיעה. התשובה קובעת איזה resolver ואילו נתיבים חשובים, וזה לא תמיד של המארח. שני פרופילים באותו מחשב נייד יכולים להתנהג אחרת לגמרי עבור אותו URL.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
שלב 1: בדקו את אותו endpoint שלוש פעמים
השתמשו ב-endpoint לא מזיק ושמרו על שם המארח, הפורט ומשפחת הכתובות זהים בכל שלוש הבדיקות. אם תשנו אחד מהם בין הרצות, התוצאות לא יהיו בנות השוואה.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthמשיכת image מוצלחת על ידי הצומת לא מוכיחה דבר על פתרון שמות עבור מארח פרטי. בקשה ציבורית מוצלחת מוכיחה אפילו פחות. שמרו את התוצאות נפרדות לפי הקשר, כי דפוס על פני שלוש שורות הוא אבחנה וכשל בודד הוא רמז.
אם גם שורת המארח נכשלת, עצרו. יש לכם בעיית רשת במארח והאשכול הוא הסחה.
שלב 2: שמרו על הנתיב של המארח לאשכול
יש כיוון שני שאנשים שוכחים: המארח חייב להמשיך להגיע ל-API ולשירותים של האשכול עצמו. לקוח VPN יכול להתקין נתיבים שמתחרים בקידומות שבהן minikube משתמש עבור רשת הצמתים, טווח השירותים וטווח ה-Pod שלו.
כשזה קורה, התסמין מבלבל, כי המנהרה עובדת ו-kubectl מפסיק להגיב או ש-NodePort מסרב לחיבורים. זה נראה כמו תקלת אשכול וזו תקלת ניתוב של המחשב הנייד.
השוו את טבלת הניתוב של המארח לטווחים של minikube לפני שאתם מאשימים את המנהרה בכל דבר אחר. החפיפה נראית בדרך כלל כנתיב ספציפי יותר שמצביע על ממשק המנהרה עבור קידומת שהאשכול מצפה לבעלות עליה.
שלב 3: פתרו את החפיפה בלי לכבות את ה-VPN
מדריך ה-VPN וה-proxy של minikube עצמו דן בקונפליקטים האלה ומתייחס לטווחי הדוגמה שלו כדברים לבדיקה, לא כרשימה אוניברסלית. קראו אותו לצד הפרופיל שבאמת יש לכם.
איפה שיש חפיפה אמיתית, התשובה הנתמכת היא טווח לא חופף או מדיניות גישה מקומית מכוונת שאושרה על ידי בעל ה-VPN. שינוי טווח השירותים הוא לא אותו דבר כמו שינוי טווח ה-Pod, ואף אחד מהם לא זהה לשינוי רשת הצמתים.
כיבוי המנהרה הארגונית כדי שאשכול מקומי יעבוד אינו עוקף; זו החלטת מדיניות שמישהו אחר צריך לקבל. הביאו אותה לאותו אדם במקום לעשות זאת בשקט אחרי שכולם הלכו הביתה. אם כבר עשיתם זאת, החזירו אותה לפני שתשאלו.
שלב 4: הפרידו proxy, DNS וארבע צורות כשל
אם נדרש proxy, זהו איזה הקשר צריך אותו. הגדרת דפדפן במארח לא מגדירה תהליך בתוך הצומת, ו-Pod צריך את משתני הסביבה או תצורת proxy ברמת האשכול.
אחר כך סווגו את הכשל במקום לתאר אותו. שם שלא נפתר הוא DNS. שם שנפתר ומסרב לחיבור הוא ניתוב או listener. חיבור שנוצר ונכשל בזהות הוא TLS. חיבור מוצלח עם גוף שגיאה הוא היישום.
כל אחד מארבעת אלה שייך לתיקון אחר, ורק אחד מהם עוסק ב-VPN. רשמו איזה מהם ראיתם בכל הקשר, והאדם הבא יורש ראיות במקום סיפור.