שיטות מומלצות לרישות ב-GKE

במסמך הזה מפורטות שיטות מומלצות להגדרת אפשרויות הרישות באשכולות Google Kubernetes Engine‏ (GKE). המדריך הזה מיועד למומחי Cloud Architect ולמהנדסי רשתות, והוא כולל המלצות להגדרת אשכולות שרלוונטיות לרוב האשכולות של GKE. לפני שיוצרים את אשכולות ה-GKE, מומלץ לעיין בכל הקטעים בדף הזה כדי להבין את אפשרויות הרשת ש-GKE תומך בהן ואת ההשלכות שלהן.

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

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

במהלך העיון בשיטות המומלצות האלה, כדאי לשים לב לנקודות הבאות:

• איך אתם מתכננים לחשוף עומסי עבודה באופן פנימי לרשת של הענן הווירטואלי הפרטי (VPC), לעומסי עבודה אחרים באשכול, לאשכולות GKE אחרים או באופן חיצוני לאינטרנט.
• איך אתם מתכננים להרחיב את עומסי העבודה.
• באילו סוגים של שירותי Google אתם רוצים להשתמש.

רשימת משימות מסכמת של כל השיטות המומלצות זמינה בקטע סיכום רשימת המשימות.

שיטות מומלצות לתכנון VPC

בקטע הבא מפורטות כמה המלצות ספציפיות ל-GKE בנוגע לתכנון רשתות VPC.

שימוש באשכולות המותאמים ל-VPC

מומלץ להשתמש באשכולות מקוריים של VPC. באשכולות מקוריים של VPC נעשה שימוש בטווחים של כתובות IP עם כינוי בצמתים של GKE, והם נדרשים לאשכולות שמבוססים על קישור בין רשתות VPC שכנות (peering), לאשכולות בVPC משותף, ויש להם יתרונות רבים נוספים. במערכות של אשכולות שנוצרו במצב Autopilot, מצב VPC-native תמיד מופעל ואי אפשר להשבית אותו.

קל יותר לשנות את הגודל של אשכולות שמותאמים ל-VPC מאשר של אשכולות מבוססי-נתיבים, בלי לצרוך נתיבים, ולכן הם פחות רגישים להגעה למגבלות הניתוב. Cloud de Confiance by S3NS

היתרונות של שימוש באשכולות מקוריים של VPC קשורים לתמיכה בכתובות IP של כינוי. לדוגמה, אפשר להשתמש בקבוצות של נקודות קצה ברשת (NEGs) רק עם כתובות IP משניות, ולכן הן נתמכות רק באשכולות מקוריים של VPC.

שימוש ברשתות VPC משותפות

אשכולות GKE מחייבים תכנון קפדני של כתובות IP. לרוב הארגונים יש מבנה ניהול מרכזי עם צוות ניהול רשת שיכול להקצות מרחב של כתובות IP לאשכולות, ואדמין פלטפורמה להפעלת האשכולות. מבנה ארגוני מהסוג הזה מתאים לארכיטקטורת רשת VPC משותפת של Cloud de Confiance. בארכיטקטורת רשת ה-VPC המשותפת, אדמין רשת יכול ליצור רשתות משנה ולשתף אותן עם רשתות VPC. אפשר ליצור אשכולות GKE בפרויקט שירות ולהשתמש בתת-רשתות ששותפו מ-VPC משותף בפרויקט מארח. רכיב כתובת ה-IP נשאר בפרויקט המארח, ושאר רכיבי האשכול נמצאים בפרויקט השירות.

באופן כללי, רשת VPC משותפת היא ארכיטקטורה שנמצאת בשימוש תדיר ומתאימה לרוב הארגונים עם צוות ניהול מרכזי. מומלץ להשתמש ברשתות VPC משותפות כדי ליצור את תת-הרשתות עבור אשכולות GKE, וכדי למנוע התנגשויות בין כתובות IP בארגון. אפשר גם להשתמש ב-VPC משותף לניהול של פונקציות תפעוליות. לדוגמה, יכול להיות לכם צוות רשת שעובד רק על רכיבי רשת ואמינות, וצוות אחר שעובד על GKE.

אסטרטגיות לניהול כתובות IP

כל אשכולות Kubernetes, כולל אשכולות GKE, דורשים כתובת IP ייחודית לכל Pod. מידע נוסף זמין במאמר מודל הרשת של GKE.

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

תכנון הקצאת כתובות ה-IP הנדרשת

מומלץ להשתמש באשכולות מקוריים של VPC עם Private Service Connect‏ (PSC). אשכולות שמשתמשים בקישור בין רשתות VPC שכנות (peering) חייבים להיות אשכולות המותאמים ל-VPC.

באשכולות המותאמים ל-VPC נדרשים טווחי כתובות ה-IP הבאים:

• טווח כתובות ה-IP של מישור הבקרה: צריך להשתמש ברשת משנה מסוג ‎ /28 בתוך טווחי כתובות ה-IP הפרטיות שכלולים ב-RFC 1918. צריך לוודא שרשת המשנה הזו לא חופפת לאף רשת אחרת בפורמט Classless Inter-Domain Routing‏ (CIDR) ברשת ה-VPC.
• תת-רשת של הצומת: תת-הרשת עם טווח כתובות ה-IP הראשי שרוצים להקצות לכל הצמתים באשכול. שירותים מהסוג LoadBalancer שמשתמשים בהערה cloud.google.com/load-balancer-type: "Internal" משתמשים גם ברשת המשנה הזו כברירת מחדל. אפשר גם להשתמש בתת-רשת ייעודית למאזני עומסים פנימיים.
• טווח כתובות ה-IP של ה-Pods: טווח כתובות ה-IP שהקציתם לכל ה-Pods באשכול. ‫GKE מקצה את הטווח הזה ככתובת אימייל חלופית של רשת המשנה. מידע נוסף זמין במאמר בנושא טווחים של כתובות IP לאשכולות מקוריים של VPC
• טווח כתובות ה-IP של השירות: טווח כתובות ה-IP שמוקצה לכל השירותים באשכול. מערכת GKE מקצה את הטווח הזה ככינוי של רשת המשנה.

כשמגדירים את הרשת של האשכול, צריך להגדיר תת-רשת של צומת, טווח כתובות IP של Pod וטווח כתובות IP של שירות.

אם רוצים להשתמש במרחב כתובות ה-IP בצורה יעילה יותר, אפשר לעיין במאמר בנושא צמצום השימוש בכתובות IP פנימיות ב-GKE.

טווח כתובות ה-IP של מישור הבקרה מוקדש למישור הבקרה שמנוהל על ידי GKE, שנמצא בפרויקט דייר שמנוהל על ידי Google ומקושר באמצעות VPC ל-VPC שלכם. טווח כתובות ה-IP הזה לא יכול לחפוף לכתובות IP בקבוצת ה-VPC שלכם, כי GKE מייבא את המסלול הזה לפרויקט. המשמעות היא שאם יש לכם מסלולים לאותו CIDR בפרויקט, יכול להיות שתיתקלו בבעיות בניווט.

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

אפשר להשתמש בCluster Autoscaler כדי להגביל את המספר המקסימלי של הצמתים.

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

חשוב לבחור טווחים רחבים מספיק של כתובות IP כדי שתוכלו להקצות כתובות לכל הצמתים, ה-Pods והשירותים של האשכול.

כדאי להביא בחשבון את המגבלות הבאות:

• אפשר להרחיב את טווחי כתובות ה-IP הראשיות, אבל אי אפשר לצמצם אותם. טווחי כתובות ה-IP האלה לא יכולים להיות לא רציפים.
• אתם יכולים להרחיב את טווח ה-Pod על ידי הוספת טווחי Pod נוספים לאשכול או על ידי יצירת מאגרי צמתים חדשים עם טווחי Pod משניים אחרים.
• אי אפשר להרחיב או לשנות את טווח כתובות ה-IP המשני של שירותים במהלך חיי האשכול.
• בודקים את המגבלות של טווח כתובות ה-IP המשני עבור Pods ו-Services.

שימוש ביותר מכתובות IP פרטיות של RFC 1918

בסביבות מסוימות, יכול להיות שמרחב RFC 1918 כבר הוקצה בארגון בבלוקים גדולים ורציפים של CIDR. אתם יכולים להשתמש במרחב שאינו RFC 1918 בשביל CIDR נוספים לאשכולות GKE, אם הם לא חופפים לכתובות IP ציבוריות בבעלות Google. מומלץ להשתמש בחלק 100.64.0.0/10 של מרחב הכתובות של RFC, כי מרחב הכתובות של Class E עלול לגרום לבעיות תאימות עם חומרה מקומית. אפשר להשתמש בכתובות IP ציבוריות שנעשה בהן שימוש חוזר באופן פרטי (PUPI).

כשמשתמשים בכתובות IP ציבוריות לשימוש פרטי, צריך להשתמש באפשרות הזו בזהירות ולשקול שליטה בפרסום של נתיבים ברשתות מקומיות לאינטרנט.

לא מומלץ להשתמש בתרגום כתובות רשת של המקור (SNAT) באשכול עם תעבורה מ-Pod ל-Pod ומ-Pod לשירות. הפעולה הזו שוברת את מודל הרשת של Kubernetes.

מערכת Kubernetes מניחה שכל כתובות ה-IP שאינן RFC 1918 הן כתובות IP ציבוריות שנעשה בהן שימוש חוזר באופן פרטי, והיא משתמשת ב-SNAT לכל התעבורה שמקורה בכתובות האלה.

אם אתם משתמשים בכתובת IP שאינה RFC 1918 עבור אשכול GKE, באשכולות רגילים תצטרכו להשבית באופן מפורש את SNAT או להגדיר את סוכן הסוואת כתובות ה-IP כדי להחריג מ-SNAT את כתובות ה-IP של ה-Pod באשכול ואת טווחי כתובות ה-IP המשניות של השירותים. באשכולות של Autopilot, לא נדרשים שלבים נוספים.

שימוש במצב רשת משנה בהתאמה אישית

כשמגדירים את הרשת, בוחרים גם את מצב רשת המשנה: auto (ברירת מחדל) או custom (מומלץ). במצב auto, הקצאת רשתות המשנה נעשית על ידי Google, וזו אפשרות טובה להתחלה בלי תכנון של כתובות IP. עם זאת, מומלץ לבחור במצב custom, כי במצב הזה אפשר לבחור טווחי כתובות IP שלא חופפים לטווחי כתובות אחרים בסביבה שלכם. אם אתם משתמשים ב-VPC משותף, אדמין ארגוני או אדמין רשת יכולים לבחור במצב הזה.

בדוגמה הבאה נוצרת רשת בשם my-net-1 עם רשת משנה במצב מותאם אישית:

gcloud compute networks create my-net-1 --subnet-mode custom

צפיפות של Plan Pod לכל צומת

כברירת מחדל, באשכולות רגילים מוזמן טווח של ‎ /24 לכל צומת מתוך מרחב כתובות ה-Pod בתת-הרשת, ומאפשר עד 110‏ Pods לכל צומת. עם זאת, אפשר להגדיר אשכול Standard כך שיתמוך בעד 256 פודים לכל צומת, עם טווח של ‎ /23 ששמור לכל צומת. בהתאם לגודל הצמתים ולפרופיל האפליקציה של ה-Pods, יכול להיות שתפעילו הרבה פחות Pods בכל צומת.

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

אם אתם מתכננים להפעיל יותר מ-110 פודים לכל צומת (הערך שמוגדר כברירת מחדל), אתם יכולים להגדיל את מספר הפודים המקסימלי לכל צומת עד 256, כאשר ‎ /23 שמור לכל צומת. בסוג כזה של הגדרה עם צפיפות גבוהה של Pod, מומלץ להשתמש במופעים עם 16 ליבות CPU או יותר כדי להבטיח את יכולת ההתאמה והביצועים של האשכול.

בקטרי Autopilot המספר המקסימלי של Pods לכל צומת מוגדר ל-32, ומוקצה טווח של ‎ /26 לכל צומת. אי אפשר להגדיר את ההגדרה הזו באשכולות של Autopilot.

הימנעות מחפיפה עם כתובות IP שמשמשות בסביבות אחרות

אתם יכולים לחבר את רשת ה-VPC לסביבה מקומית או לספקי שירותי ענן אחרים באמצעות Cloud VPN או Cloud Interconnect. הסביבות האלה יכולות לשתף נתיבים, ולכן תוכנית ניהול כתובות ה-IP המקומיות חשובה בתכנון כתובות ה-IP ל-GKE. מומלץ לוודא שכתובות ה-IP לא חופפות לכתובות ה-IP שמשמשות בסביבות אחרות.

יצירת רשת משנה של מאזן עומסים

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

שימוש ברשת משנה נפרדת למאזן העומסים מאפשר גם לסנן את התנועה אל הצמתים של GKE וממנה בנפרד לשירותים שנחשפים על ידי איזון עומסים פנימי של TCP/UDP, וכך להגדיר גבולות אבטחה מחמירים יותר.

שמירת מספיק מרחב כתובות IP לשינוי גודל האוטומטי של האשכול

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

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

שיתוף כתובות IP בין אשכולות

יכול להיות שתצטרכו לשתף כתובות IP בין אשכולות אם יש לכם צוות מרכזי שמנהל את התשתית של האשכולות. כדי לשתף כתובות IP בין אשכולות GKE, אפשר לעיין במאמר בנושא שיתוף טווחי כתובות IP בין אשכולות GKE. אפשר לצמצם את התופעה של מיצוי כתובות IP על ידי יצירת שלושה טווחים – ל-Pods, לשירותים ולצמתים – ושימוש חוזר בהם או שיתוף שלהם, במיוחד במודל של VPC משותף. ההגדרה הזו גם יכולה להקל על מנהלי רשת לנהל כתובות IP, כי הם לא צריכים ליצור רשתות משנה ספציפיות לכל אשכול.

כמה נקודות שכדאי לחשוב עליהן:

• מומלץ להשתמש בתת-רשתות נפרדות ובטווחי כתובות IP נפרדים לכל האשכולות.
• אפשר לשתף את טווח כתובות ה-IP של ה-Pod המשני, אבל לא מומלץ לעשות את זה כי יכול להיות שאחד מהאשכולות ישתמש בכל כתובות ה-IP.
• אפשר לשתף טווחי כתובות IP משניים של שירותים, אבל התכונה הזו לא פועלת עם Cloud DNS בהיקף VPC ל-GKE.

אם נגמרות לכם כתובות ה-IP, אתם יכולים ליצור טווחי כתובות IP נוספים של Pod באמצעות CIDR של כמה Pods לא רציפים.

שיתוף כתובות IP לשירותי איזון עומסים פנימיים

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

מידע נוסף זמין במאמר בנושא כתובת IP משותפת.

שיטות מומלצות לאבטחת הרשת

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

שימוש ב-GKE Dataplane V2

‫GKE Dataplane V2 מבוסס על eBPF ומספק חוויה משולבת של אבטחת רשת ושקיפות. כשיוצרים אשכול באמצעות GKE Dataplane V2, לא צריך להפעיל במפורש מדיניות רשת כי GKE Dataplane V2 מנהל את ניתוב השירותים, את אכיפת מדיניות הרשת ואת הרישום ביומן. מפעילים את מישור הנתונים החדש באמצעות האפשרות --enable-dataplane-v2 ב-Google Cloud CLI כשיוצרים אשכול. אחרי שמגדירים את מדיניות הרשת, אפשר להגדיר אובייקט CRD של NetworkLogging כברירת מחדל כדי לרשום ביומן את חיבורי הרשת שאושרו ואת אלה שנדחו. מומלץ ליצור אשכולות עם GKE Dataplane V2 כדי לנצל את כל היתרונות של התכונות המובנות, כמו רישום ביומן של מדיניות הרשת.

מצמצמים את החשיפה של הצומת

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

בתרשים הזה מוצג אופן התקשורת באשכול עם צמתים פרטיים. לקוחות מקומיים יכולים להתחבר לאשכול באמצעות לקוח kubectl. הגישה לשירותי Google ניתנת דרך גישה פרטית ל-Google, והתקשורת עם האינטרנט זמינה רק באמצעות Cloud NAT.

מזעור החשיפה של מישור הבקרה של האשכול

למישור הבקרה יש שני סוגים של נקודות קצה לגישה לאשכול:

• נקודת קצה מבוססת DNS
• נקודות קצה מבוססות-IP

אפשר לגשת לנקודת הקצה של ה-DNS מכל רשת שאפשר להגיע אליה באמצעות ממשקי API, כולל רשתות מקומיות או רשתות ענן אחרות. Cloud de Confiance by S3NS כדי להפעיל את נקודת הקצה מבוססת ה-DNS, משתמשים בדגל --enable-dns-access.

שרת ה-API של GKE יכול להיחשף גם כנקודת קצה (endpoint) ציבורית או פרטית שמבוססת על כתובת IP. אתם יכולים להחליט באיזה נקודת קצה להשתמש כשאתם יוצרים את האשכול. אפשר לשלוט בגישה באמצעות רשתות מורשות, שבהן נקודות הקצה הציבוריות והפרטיות מוגדרות כברירת מחדל כך שכל התקשורת בין ה-Pod לבין כתובות ה-IP של הצומת באשכול מותרת. כדי להפעיל נקודת קצה פרטית כשיוצרים אשכול, משתמשים בדגל --enable-private-endpoint.

אישור גישה למישור הבקרה

רשתות מורשות יכולות לעזור לקבוע לאילו תת-רשתות של כתובות IP יש גישה לצמתים של מישור הבקרה של GKE. אחרי שמפעילים את הרשתות האלה, אפשר להגביל את הגישה לטווחים ספציפיים של כתובות IP של מקורות. אם נקודת הקצה הציבורית מושבתת, טווחי כתובות ה-IP של המקור צריכים להיות פרטיים. אם נקודת קצה ציבורית מופעלת, אפשר לאפשר טווחי כתובות IP ציבוריות או פנימיות. מגדירים פרסום של מסלולים בהתאמה אישית כדי לאפשר גישה לנקודת הקצה הפרטית של מישור הבקרה של האשכול מסביבה מקומית. אפשר להגדיר את נקודת הקצה הפרטית של GKE API כך שתהיה נגישה באופן גלובלי באמצעות האפשרות --enable-master-global-access כשיוצרים אשכול.

בתרשים הבא מוצגת קישוריות אופיינית של מישור הבקרה באמצעות רשתות מורשות:

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

התרת קישוריות של מישור הבקרה

חלק מה-Pods של המערכת בכל צומת עובד יצטרכו להגיע לשירותים כמו שרת Kubernetes API ‏ (kube-apiserver), Google APIs או שרת המטא-נתונים. kube-apiserverצריך גם לתקשר עם כמה פודים של המערכת, כמו event-exporter. התקשורת הזו מותרת כברירת מחדל. אם אתם פורסים כללי חומת אש של VPC בתוך הפרויקטים (פרטים נוספים זמינים בקטע בנושא הגבלת התעבורה של האשכול), חשוב לוודא שה-Pods האלה יכולים להמשיך לתקשר עם kube-apiserver וגם עם ממשקי API של Google.

פריסת שרתי proxy לגישה למישור הבקרה מרשתות שנוצרו באמצעות שירותי שילוב

אם באשכול שלכם נעשה שימוש בקישור (peering) בין רשתות VPC שכנות, לא תוכלו לגשת למישור הבקרה של האשכול מרשת שכנה אחרת.

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

הגבלת התנועה באשכול באמצעות מדיניות רשת

אפשר להגדיר כמה רמות של אבטחת רשת לעומסי עבודה של אשכולות, ולשלב ביניהן: כללי חומת אש של VPC, מדיניות חומת אש היררכית ומדיניות רשת של Kubernetes. כללי חומת אש של VPC ומדיניות חומת אש היררכית חלים ברמת המכונה הווירטואלית (VM), כלומר בצמתי העובדים שבהם נמצאים הפודים של אשכול GKE. כללי מדיניות של רשת Kubernetes חלים ברמת ה-Pod כדי לאכוף נתיבי תעבורה מ-Pod ל-Pod.

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

כללי מדיניות של רשת GKE מוגדרים באמצעות Kubernetes Network Policy API כדי לאכוף את התקשורת בין קבוצות Pod באשכול. אפשר להפעיל מדיניות רשת כשיוצרים אשכול באמצעות האפשרות gcloud container clusters create --enable-network-policy. כדי להגביל את התעבורה באמצעות מדיניות רשת, אפשר לפעול לפי מדריך ההטמעה של תוכנית הפעולה להגבלת התעבורה ב-Anthos.

הפעלת מדיניות אבטחה של Google Cloud Armor לתעבורת נתונים נכנסת (ingress)

באמצעות מדיניות האבטחה של Google Cloud Armor, אתם יכולים להגן על אפליקציות שמשתמשות במאזני עומסים חיצוניים של אפליקציות מפני מתקפות DDoS ומתקפות אחרות באינטרנט, על ידי חסימת תעבורה כזו בקצה הרשת. ב-GKE, כדי להפעיל את כללי מדיניות האבטחה של Google Cloud Armor לאפליקציות, צריך להשתמש ב-Ingress בשביל מאזני עומסים חיצוניים של אפליקציות ולהוסיף כללי מדיניות אבטחה ל-BackendConfig שמצורף לאובייקט Ingress.

שימוש בשרת proxy לאימות זהויות (IAP) כדי לספק אימות לאפליקציות עם משתמשי IAM

אם אתם רוצים לפרוס שירותים שרק משתמשים בארגון שלכם יכולים לגשת אליהם, בלי שהם יצטרכו להיות ברשת הארגונית, אתם יכולים להשתמש ב-שרת proxy לאימות זהויות (IAP) כדי ליצור שכבת אימות לאפליקציות האלה. כדי להפעיל שרת proxy לאימות זהויות (IAP) ב-GKE, צריך לפעול לפי שלבי ההגדרה כדי להוסיף שרת proxy לאימות זהויות כחלק מ-BackendConfig עבור שירות Ingress. אפשר לשלב שרת proxy לאימות זהויות (IAP) עם Google Cloud Armor.

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

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

התאמה לעומס (scaling) של קישוריות באשכול

בקטע הזה מוסבר על אפשרויות שניתנות להרחבה ל-DNS ולקישוריות יוצאת מהאשכולות שלכם לאינטרנט ולשירותי Google.

שימוש ב-Cloud DNS ל-GKE

אתם יכולים להשתמש ב-Cloud DNS for GKE כדי לספק פענוח DNS של Pod ושל שירות עם DNS מנוהל, ללא ספק DNS שמתארח באשכול. שירות Cloud DNS מסיר את התקורה של ניהול שרת DNS באירוח אשכול, ולא נדרש שינוי קנה מידה, מעקב או ניהול של מופעי DNS, כי זהו שירות Google באירוח.

הפעלת NodeLocal DNSCache

‫GKE משתמש ב-kube-dns כדי לספק את שירות ה-DNS המקומי של האשכול כתוסף ברירת מחדל לאשכול. הערך kube-dns משוכפל בכל האשכול כפונקציה של המספר הכולל של ליבות וצמתים באשכול.

אפשר לשפר את הביצועים של DNS באמצעות NodeLocal DNSCache. ‫NodeLocalDNSCache הוא תוסף שמוטמע כ-DaemonSet, ולא נדרשים שינויים בהגדרות של אף Pod. חיפושי DNS לשירות Pod המקומי לא יוצרים חיבורים פתוחים שצריך לעקוב אחריהם בצומת, מה שמאפשר קנה מידה גדול יותר. חיפושים של שמות מארחים חיצוניים מועברים ל-Cloud DNS, בעוד שכל שאילתות ה-DNS האחרות מועברות ל-kube-dns.

הפעלת NodeLocal DNSCache לזמני חיפוש עקביים יותר של שאילתות DNS ולשיפור קנה המידה של האשכול. באשכולות Autopilot, ‏ NodeLocal DNSCache מופעל כברירת מחדל ואי אפשר לשנות את ההגדרה הזו.

האפשרות הבאה ב-Google Cloud CLI מאפשרת להפעיל את NodeLocal DNSCache כשיוצרים אשכול: --addons NodeLocalDNS.

אם יש לכם שליטה בשם שהאפליקציות מחפשות לפתור, יש דרכים לשפר את קנה המידה של DNS. לדוגמה, אפשר להשתמש ב-FQDN (שם מארח שמסתיים בנקודה) או להשבית את הרחבת נתיב החיפוש באמצעות האפשרות Pod.dnsConfig במניפסט.

שימוש ב-Cloud NAT לגישה לאינטרנט מאשכולות

כברירת מחדל, לאשכולות שמופעלים בהם צמתים פרטיים אין גישה לאינטרנט. כדי לאפשר ל-Pods להגיע לאינטרנט, צריך להפעיל את Cloud NAT בכל אזור. לפחות, צריך להפעיל את Cloud NAT לטווחים הראשיים והמשניים בתת-הרשת של GKE. חשוב להקצות מספיק כתובות IP ל-Cloud NAT ויציאות לכל מכונה וירטואלית.

כשמשתמשים ב-Cloud NAT עבור אשכולות, מומלץ לפעול לפי השיטות המומלצות הבאות להגדרת שער Cloud NAT:

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

• שימוש בהקצאה של יציאות דינמית כדי להקצות מספרים שונים של יציאות לכל מכונה וירטואלית, על סמך השימוש במכונה הווירטואלית. מתחילים עם מינימום של 64 יציאות ומקסימום של 2,048 יציאות.

• אם אתם צריכים לנהל הרבה חיבורים בו-זמניים לאותו יעד 3-tuple, כדאי להקטין את ערך הזמן הקצוב לתפוגה של TCP TIME_WAIT מערך ברירת המחדל שלו 120s לערך 5s. מידע נוסף מופיע במאמר בנושא שינוי פסק זמן של NAT.

• כדי לבדוק יומנים שקשורים לבעיה, מפעילים את רישום השגיאות ביומן של Cloud NAT.

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

מומלץ להימנע מ-SNAT כפול לתעבורת נתונים של Pod (קודם SNAT בצומת GKE ואז שוב עם Cloud NAT). אלא אם אתם צריכים SNAT כדי להסתיר את כתובות ה-IP של ה-Pod ברשתות מקומיות שמחוברות באמצעות Cloud VPN או Cloud Interconnect, disable-default-snat ולהעביר את המעקב אחר SNAT ל-Cloud NAT לצורך יכולת הרחבה. הפתרון הזה מתאים לכל טווחי כתובות ה-IP של רשתות המשנה הראשיות והמשניות. אחרי שמפעילים את Cloud NAT, אפשר להשתמש במדיניות רשת כדי להגביל את התנועה החיצונית. לא צריך את Cloud NAT כדי לגשת לשירותי Google.

שימוש בגישה פרטית ל-Google כדי לגשת לשירותי Google

באשכולות עם צמתים פרטיים, ל-Pods אין כתובות IP ציבוריות כדי להגיע לשירותים ציבוריים, כולל Google APIs ושירותים של Google. גישה פרטית ל-Google מאפשרת לCloud de Confiance by S3NS משאבים פרטיים להגיע לשירותי Google.

גישה פרטית ל-Google מופעלת כברירת מחדל באשכולות עם צמתים פרטיים, למעט אשכולות של VPC משותף.

שיטות מומלצות לקביעת קנה מידה באפליקציות

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

שימוש באיזון עומסים שמקורם בקונטיינר

משתמשים באיזון עומסים מובנה בקונטיינרים כשחושפים שירותים באמצעות HTTP(S) באופן חיצוני. איזון עומסים שמקורם בקונטיינר מפחית את מספר הצעדים ברשת, מקצר את זמן האחזור ומספק פילוח תנועה מדויק יותר. היא גם משפרת את הנראות של זמן הלוך ושוב ומאפשרת להשתמש בתכונות של איזון עומסים כמו Google Cloud Armor.

בחירת משאב GKE מתאים לחשיפת האפליקציה

בהתאם להיקף הלקוחות שלכם (פנימיים, חיצוניים או אפילו פנימיים לאשכול), לאזוריות של האפליקציה ולפרוטוקולים שבהם אתם משתמשים, יש משאבי GKE שונים שבהם אתם יכולים להשתמש כדי לחשוף את האפליקציה. בסקירה הכללית של Service Networking מוסברות האפשרויות האלה, והיא יכולה לעזור לכם לבחור את המשאב הטוב ביותר לחשיפת כל חלק באפליקציה באמצעות אפשרויות איזון עומסים. Cloud de Confiance by S3NS

יצירת בדיקות תקינות על סמך BackendConfig

אם משתמשים ב-Ingress כדי לחשוף שירותים, צריך להשתמש בהגדרת בדיקת תקינות ב-CRD של BackendConfig כדי להשתמש בפונקציונליות של בדיקת התקינות של מאזן העומסים של אפליקציות (ALB) החיצוני. אתם יכולים להפנות את בדיקת התקינות לנקודת הקצה המתאימה ולהגדיר ספים משלכם. אם לא מציינים CRD של BackendConfig, בדיקות תקינות נגזרות מפרמטרים של בדיקת מוכנות או מפרמטרים שמוגדרים כברירת מחדל.

שימוש במדיניות תעבורה מקומית כדי לשמור על כתובות ה-IP המקוריות

כשמשתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם GKE, צריך להגדיר את האפשרות externalTrafficPolicy לערך Local כדי לשמור על כתובת ה-IP של המקור של הבקשות. כדאי להשתמש באפשרות הזו אם האפליקציה שלכם דורשת את כתובת ה-IP של המקור. עם זאת, האפשרות externalTrafficPolicy local עלולה להוביל לפיזור עומס פחות אופטימלי, ולכן כדאי להשתמש בתכונה הזו רק כשנדרש. בשירותי HTTP(S), אפשר להשתמש בבקרי Ingress ולקבל את כתובת ה-IP המקורית על ידי קריאת הכותרת X-Forwarded-For בבקשת ה-HTTP.

שימוש ב-Private Service Connect

אתם יכולים להשתמש ב-Private Service Connect כדי לשתף שירותים פנימיים של מאזן עומסים (LB) מסוג Network Load Balancer (מאזן עומסים לרשת) ברשתות VPC אחרות. האפשרות הזו שימושית לשירותים שמארחים באשכולות GKE אבל משרתים לקוחות שפועלים בפרויקטים שונים וב-VPC שונים.

אתם יכולים להשתמש ב-Private Service Connect כדי לצמצם את צריכת כתובות ה-IP על ידי יצירת קישוריות בין רשתות VPC עם כתובות IP חופפות.

שיטות מומלצות לתפעול

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

שימוש ב-IAM להרשאות GKE כדי לשלוט במדיניות ברשתות VPC משותפות

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

כדי להימנע מיצירה ידנית של כללי חומת אש, צריך להקצות לחשבון השירות של GKE בפרויקט המארח תפקיד בהתאמה אישית עם הרשאות מינימליות בשם service-HOST_PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

מחליפים את HOST_PROJECT_NUMBER במספר הפרויקט של הפרויקט המארח של ה-VPC המשותף.

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

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

בנוסף, לכללי חומת אש שנוצרו על ידי GKE תמיד יש עדיפות ברירת מחדל של 1000, כך שאפשר למנוע תנועה ספציפית על ידי יצירת כללי חומת אש בעדיפות גבוהה יותר.

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

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

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

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

אפשר גם להשתמש בPod anti-affinity כדי לוודא ש-Pods של שירות מסוים מתוזמנים בכמה אזורים.

שימוש ב-Cloud Logging וב-Cloud Monitoring והפעלה של רישום ביומן של מדיניות הרשת

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

באשכולות GKE בגרסה 1.14 ואילך, הרישום ביומן והמעקב מופעלים כברירת מחדל. Monitoring מספק לוח בקרה לאשכולות GKE. הרישום ביומן מאפשר גם הערות GKE ל-VPC Flow Logs. כברירת מחדל, Logging אוסף יומנים עבור כל עומסי העבודה שנפרסו באשכול, אבל קיימת גם אפשרות ליומנים של המערכת בלבד. אפשר להשתמש במרכז הבקרה של GKE כדי לצפות בהתראות ולהגדיר אותן. באשכולות שנוצרו במצב Autopilot, הניטור והרישום ביומן מופעלים באופן אוטומטי ואי אפשר להגדיר אותם.

שיטות מומלצות לפילוח שווה של התנועה

בקטע הזה מפורטות שיטות מומלצות לחלוקת תנועה שווה. לפני שמיישמים את ההמלצות האלה, חשוב לוודא שיש לכם מערכת מתאימה למעקב (לדוגמה, באמצעות Prometheus,‏ Cloud Monitoring או שירותי המעקב של ספק שירותי הענן שלכם) כדי לזהות דפוסי חלוקה לא אחידים ולאשר אותם.

השבתה או הגדרה זהירה של זיקה לסשן (session affinity)

כדי לפתור את הבעיה, צריך להשבית את הזיקה לסשן (session affinity), אלא אם היא נחוצה לחלוטין. מגדירים את התג Set sessionAffinity: None במניפסט של השירות. אם אתם חייבים להשתמש בהצמדה של סשנים, חשוב שתבדקו היטב את ההשלכות ותעקבו אחרי עומס ה-Pod. התכונה 'שיוך סשן' מוודאת שהמשתמש יישאר מחובר לאותו שרת קצה עורפי למשך הסשן.

שימוש באיזון עומסים משוקלל

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

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

• גרסת אשכול GKE: אשכול GKE צריך להשתמש בגרסה ‎1.31.0-gke.1506000 ואילך.
• התוסף HTTP Load Balancing: התוסף HttpLoadBalancing צריך להיות מופעל באשכול (הוא מופעל כברירת מחדל). אם האשכול שלכם הוא בגרסה 1.36 ומעלה, התוסף הזה לא נדרש לשירותי קצה עורפי.
• מאזן עומסים מבוסס-שירות לקצה העורפי: מגדירים את השדה spec.loadBalancerClass לערך networking.gke.io/l4-regional-external במניפסט השירות כדי לוודא ש-GKE יוצר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי. בשדה הזה נדרשת גרסה ‎1.33.1-gke.1779000 ואילך של GKE. מאזני עומסים שמבוססים על מאגרי יעד לא תומכים באיזון עומסים משוקלל.
• הערה לגבי איזון עומסים משוקלל: כוללים את ההערה networking.gke.io/weighted-load-balancing: pods-per-node במניפסט השירות.
• מדיניות תנועה חיצונית: במניפסט של השירות צריך להשתמש ב-externalTrafficPolicy: Local. למרות שאפשר להשתמש ב-externalTrafficPolicy: Cluster, הוא למעשה משבית את איזון העומסים המשוקלל, כי יכול להיות שהמנות ינותבו לצומת אחר אחרי החלוקה הראשונית של מאזן העומסים.

1. שומרים את קובץ המניפסט לדוגמה הבא בשם weighted-lb-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-weighted-service
  annotations:
    networking.gke.io/weighted-load-balancing: pods-per-node
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  externalTrafficPolicy: Local
  selector:
    app: my-app
  ports:
    -   protocol: TCP
      port: 80
      targetPort: 8080

1. מחילים את המניפסט על האשכול:

   kubectl apply -f weighted-lb-service.yaml
   

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

הקפדה על חלוקה שווה של ה-Pods בין הצמתים

כדי למנוע תזמון של Pods מאותו שירות באותו צומת, משתמשים ב-Pod anti-affinity. מגדירים כללים למניעת קרבה בין פודים במניפסטים של הפריסה.

בדוגמה הבאה מוצג מניפסט של פריסה עם אנטי-אפיניות של Pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: my-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          -   labelSelector:
              matchExpressions:
              -   key: app
                operator: In
                values:
                -   my-app
            topologyKey: "kubernetes.io/hostname"

בדיקת המדיניות בנושא תנועה חיצונית

משתמשים ב-Cluster בתור externalTrafficPolicy כדי לאפשר למאזן העומסים לפזר את התנועה לכל צומת באשכול. מגדירים את externalTrafficPolicy: Cluster במניפסט של השירות. משתמשים בהגדרה הזו אם רוצים לפזר את התנועה באופן שווה בין כל הצמתים.

אם משתמשים ב-Local, חשוב לוודא שהפודים מפוזרים באופן שווה בין הצמתים.

השבתת ההתאמה של הצומת

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

שימוש בבדיקות מוכנות

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

בדוגמה הבאה מוצג מניפסט של Pod עם בדיקת מוכנות:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  -   name: my-container
    image: my-image
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

שימוש באיזון עומסים שמקורם בקונטיינר

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

כדאי לשקול ניתוב שמודע לטופולוגיה

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

Cloud Service Mesh

כדי לקבל שליטה מדויקת יותר על חלוקת התעבורה, על מדיניות ניתוב מתקדמת ועל ניראות (observability), כדאי להטמיע Cloud Service Mesh כמו Istio. ‫Cloud Service Mesh פועל בשכבת האפליקציה ומספק יכולות מתקדמות של ניהול תנועה.

סיכום רשימת המשימות

המאמרים הבאים

• תובנות לגבי שיטות מומלצות ל-GKE
• שיטות מומלצות לשימוש ב-multi-tenancy בארגונים גדולים