פודי GKE איבדו גישה ל-VPN אחרי 1.14: שתי דרכים לתקן את המקור

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

מגיע עדכון, והמערכות בצד השני של המנהרה מתחילות לדחות תעבורת פודים שעבדה בשבוע הקודם. המנהרה פעילה, כללי חומת האש לא נגעו, ואף אחד לא ערך את מדיניות העמית. מה שהשתנה בלתי נראה ביומני האשכול: כתובת המקור שהמערכות האלה רואות כעת. הפער הזה מסביר תקלה שנראית כמו נפילת רשת ומתנהגת כמו בעיית הרשאות.

קיימות שתי תשובות תקפות, והן מובילות למקומות שונים. בחרו את חוזה המקור לפני עריכת ConfigMap.

כלל ברירת המחדל שהפסיקו להתקין

גרסאות GKE קודמות התקינו כלל masquerade שהחליף מקורות פודים בכתובת הצומת בכל פעם שהיעד היה מחוץ ל-10.0.0.0/8. שער VPN בתוך הטווח הזה ראה את כתובת הפוד, בעוד שכל דבר רחוק יותר נראה כאילו הגיע מהצומת. העמיתים בנו רשימות היתר ונתיבי חזור סביב כתובות צומת כי זה מה שהם צפו.

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

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

בחרו את המקור שהעמית אמור לראות

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

שמירה על כתובות צומת היא החוזה הזול יותר. הפעילו שוב masquerade ליעד הזה והעמית ימשיך לראות כתובת שהוא כבר סומך עליה.

שאלה אחת מכריעה ביניהם: מה העמית עושה עם המקור? אם הוא רושם יומן, מיישם מדיניות לפי מקור או כופה ניתוב חזור צר, כתובות פודים מצדיקות את התצורה הנוספת. אם הוא רק צריך לשלוח תגובות, masquerade עולה פחות ולא מבקש דבר מהצד השני. כל בחירה ניתנת להגנה כל עוד שני הצוותים כותבים אותה.

אפשרות שלישית היא בדרך כלל טעות: masquerade על הכול ולאבד את היכולת לייחס תעבורה. הימנעו ממנה אלא אם עמית באמת לא יכול לנתב דבר מלבד כתובות צומת.

כוונו את nonMasqueradeCIDRs לטווחים האמיתיים

GKE מריץ את ip-masq-agent ב-kube-system, וה-ConfigMap שלו מפרט את היעדים שמדלגים על masquerade. כדי לשמר מקורות פודים לכיוון המנהרה, טווח הפודים, תת-הרשת של הצומת והקידומת המקומית כולם שייכים לרשימה הזו.

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

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

רשומה של 0.0.0.0/0 משביתה masquerade לכל היעדים, מה שמשנה איך עומסי עבודה לא קשורים נראים לשירותים חיצוניים ולעיתים רחוקות מכוון. הסוכן קורא שוב את התצורה שלו ב-resyncInterval, כך שאתחול מחדש בדרך כלל אינו נחוץ. בדקו שפוד הסוכן פועל, ואז פתחו את הקובץ המורכב בתוכו. קריאת הקובץ הזה היא מה שמוכיח שהשינוי הגיע.

נתיב התגובה הוא החצי השני

masquerade משנה את מקור הבקשה ושום דבר אחר. יהיה אשר יהיה המקור שהעמית מקבל, הוא עדיין זקוק לנתיב חזרה אליו, והאשכול עדיין זקוק לנתיב לכיוון העמית.

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

בדקו שוב אחרי כל עדכון

התנהגות ברירת המחדל של masquerade כבר השתנתה פעם אחת, והחלפת מאגר צמתים יכולה לאפס את רשת האשכול. התייחסו לחוזה המקור כאל משהו שצריך לאמת ולא כאל משהו שמניחים.

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

מאמרים קשורים