צמתים פרטיים של GKE לא קובעים באיזה API kubectl משתמש

הצמתים פרטיים, ה-VPN מגיע אליהם, ובכל זאת kubectl לא מצליח לדבר עם האשכול. שתי העובדות האלה לא קשורות זו לזו. הכתובת ש-kubectl משתמש בה מגיעה מכתובת ה-URL של השרת שנשמרה ב-kubeconfig כשנשלפו פרטי ההזדהות, ואף נתיב שתוסיפו לא משנה אותה. בינתיים, הצמתים הם בכלל לא מה ש-kubectl מנסה להגיע אליו.

חמישה בדיקות, נתחיל בערך היחיד שחשוב.

בדיקה 1: קראו את כתובת ה-URL של השרת ב-kubeconfig

הדפיסו את נקודת הקצה בלי לשפוך את פרטי ההזדהות: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". המחרוזת האחת הזו אומרת לכם אם הלקוח מצביע לכתובת IP, לשם DNS או לכתובת חיצונית שלא התכוונתם לה. כל השאר בחקירה הזו נובע ממנה.

אם כתובת ה-URL אינה נקודת הקצה שחשבתם שהגדרתם, שאר האבחון הוא הסחת דעת.

בדיקה 2: התאימו את כתובת ה-URL לסוג נקודת הקצה

GKE הנוכחי תומך בגישה למישור הבקרה גם מבוססת IP וגם מבוססת DNS, ופרטי ההזדהות ששולפים בוחרים באחת מהן. gcloud container clusters get-credentials NAME --location REGION --internal-ip כותב את נקודת הקצה של ה-IP הפנימי, ואילו --dns-endpoint בוחר גישה מבוססת DNS. אף אחד מהדגלים לא מספק נתיב רשת, מה שמפתיע אנשים שמצפים שהשליפה תתקן את הקישוריות. חזרו על השליפה במכוון ואז קראו שוב את כתובת ה-URL.

החלפת דגלים בלי לקרוא שוב את כתובת ה-URL היא הדרך שבה מחשב נייד נשאר עם פרטי הזדהות של שני אשכולות ושגיאה אחת מבלבלת.

רשומה ברשת מורשית קובעת מי רשאי להגיע לנקודת קצה חיצונית ואינה חלה על הפנימית. הרחבתה כדי לבדוק נתיב פרטי משנה את החשיפה שלכם, לא את האבחון.

בדיקה 3: הוכיחו את הנתיב לנקודת הקצה הזו

אם כתובת ה-URL היא IP פנימי, אמתו את הנתיב מהרשת שהלקוח באמת נמצא בה, את טווח המקור המותר ואת הגדרת הגישה האזורית או הגלובלית של האשכול. טווח מישור הבקרה ותת-הרשת של הצמתים אינם אותו יעד, ולכן נתיב שעובד אל הצמתים אינו מוכיח דבר על נקודת הקצה. עבור גישה מבוססת DNS, הנתיב הוא קישוריות ל-Google API עם הסדר המתועד של Private Google Access, ולא נתיב לתת-הרשת של העובדים. בדקו את נקודת הקצה בחיבור TCP פשוט לפני שאתם מאשימים את kubectl.

פסק זמן הוא בעיית נתיב. 403 הוא בעיית מדיניות. אין להם תיקון משותף.

בדיקה 4: הפרידו יומנים ו-exec מקריאות API

אם בקשות API רגילות מצליחות ו-kubectl logs או kubectl exec נכשל, כבר עברתם את בחירת נקודת הקצה. הפעולות האלה דורשות את הרשאות Kubernetes המתאימות ותלויות בתקשורת ממישור הבקרה אל הצמתים, והכשל יכול להיות תגובת Forbidden ולא פסק זמן. גישת SSH לצומת בודקת שירות אחר לגמרי ואינה מבססת אותן.

קראו את מחלקת השגיאה לפני שתפתחו מחדש את כרטיס ה-VPN, כי שתי המחלקות גרות במקומות שונים.

בדיקה 5: שמרו שלוש תצפיות לאדם הבא

רשמו את כתובת ה-API שנבחרה, אם בקשת API מורשית אחת עובדת, ואיזו פעולה מאוחרת בדיוק נכשלת, יחד עם טקסט השגיאה. שלושת השורות האלה מפרידים בין בחירת נקודת הקצה לבין גישת הצמתים, והם מונעים האשמה של נתיב VPN טוב לגמרי בבקשה שהוא מעולם לא נשא.

המהנדס הבא ישאל אם המנהרה שבורה. ההערה שלכם אמורה כבר לענות על זה.