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

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

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

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

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

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

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

שיטות מומלצות לעיצוב VPC

כשמתכננים את רשתות ה-VPC, מומלץ לפעול לפי השיטות המומלצות לתכנון VPC.

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

שיטות מומלצות:

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

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

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

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

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

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

אשכולות GKE מחייבים תכנון קפדני של כתובות IP. לרוב הארגונים יש מבנה ניהול מרכזי עם צוות ניהול רשת שיכול להקצות מרחב של כתובות IP לאשכולות, ואדמין פלטפורמה להפעלת האשכולות. מבנה ארגוני מהסוג הזה מתאים לארכיטקטורת רשת VPC משותפת של Google Cloud. בארכיטקטורה של רשת 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 הנדרשת.
אם צריך, אפשר להשתמש במרחב שאינו RFC 1918.
שימוש במצב רשת משנה מותאם אישית.
תכנון צפיפות של Pod לכל צומת.
מומלץ להימנע מחפיפה עם כתובות IP שנעשה בהן שימוש בסביבות אחרות.
יצירת רשת משנה של מאזן עומסים.
שמירת מספיק מקום לכתובות IP למידרוג אוטומטי של אשכולות.
שיתוף כתובות IP בין אשכולות.
שיתוף כתובות IP לשירותי איזון עומסים פנימיים.

תכנון הקצאת כתובות ה-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 של ה-Pod: טווח כתובות ה-IP שהקציתם לכל ה-Pods באשכול. ‫GKE מקצה את הטווח הזה ככתובת אימייל חלופית של רשת המשנה. מידע נוסף זמין במאמר בנושא טווחים של כתובות IP לאשכולות מקוריים של VPC
  • טווח כתובות ה-IP של השירות: טווח כתובות ה-IP שמוקצה לכל השירותים באשכול. מערכת GKE מקצה את הטווח הזה ככינוי של רשת המשנה.

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

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

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

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

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

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

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

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

שימוש ביותר מכתובות 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 כדי לא לכלול את כתובות ה-IP של ה-Pod באשכול ואת טווחי כתובות ה-IP המשניים של השירותים מ-SNAT. באשכולות של 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 של כמה Pod לא רציפים.

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

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

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

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

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

שיטות מומלצות:

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

שימוש ב-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, כמו שמתואר בקטע קישוריות של אשכולות במסמך הזה. התרשים הבא מציג הגדרה כזו:

דיאגרמה 1: תקשורת בין צמתים פרטיים

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

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

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

  • נקודת קצה מבוססת DNS
  • נקודות קצה מבוססות-IP
שיטה מומלצת:

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

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

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

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

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

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

תרשים 2: קישוריות של מישור הבקרה באמצעות רשתות מורשות

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

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

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

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

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

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

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

אפשר להגדיר כמה רמות של אבטחת רשת לעומסי עבודה של אשכולות, ולשלב ביניהן: כללי חומת אש של VPC, מדיניות היררכית של חומת אש ומדיניות רשת של Kubernetes. כללי חומת אש של VPC ומדיניות חומת אש היררכית חלים ברמת המכונה הווירטואלית (VM), כלומר בצמתי העובדים שבהם נמצאים ה-Pods של אשכול 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 for external Application Load Balancers ומוסיפים כללי מדיניות אבטחה ל-BackendConfig שמצורף לאובייקט Ingress.

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

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

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

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

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

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

שיטות מומלצות:

שימוש ב-Cloud DNS ל-GKE
מפעילים את NodeLocal DNSCache.
שימוש ב-Cloud NAT לגישה לאינטרנט מאשכולות.
משתמשים בגישה פרטית ל-Google כדי לגשת לשירותי 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 יש בפרויקט.

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

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

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

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

מומלץ להימנע מ-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 מאפשרת לGoogle Cloud משאבים פרטיים לגשת לשירותי Google.

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

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

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

שיטות מומלצות:

שימוש באיזון עומסים שמקורם בקונטיינר.
בוחרים את משאב GKE הנכון לחשיפת האפליקציה.
יצירת בדיקות תקינות שמבוססות על BackendConfig
שימוש במדיניות תנועה מקומית כדי לשמור על כתובות ה-IP המקוריות.
שימוש ב-Private Service Connect

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

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

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

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

יצירת בדיקות תקינות על סמך 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 כדי לשתף שירותים פנימיים של מאזן עומסי רשת מסוג Network Load Balancer ברשתות VPC אחרות. האפשרות הזו שימושית לשירותים שמארחים באשכולות GKE אבל משרתים לקוחות שמפעילים פרויקטים שונים ורשתות VPC שונות.

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

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

שיטות מומלצות:

שימוש ב-IAM להרשאות GKE כדי לשלוט במדיניות ברשתות VPC משותפות.
שימוש באשכולות אזוריים וחלוקת עומסי העבודה לזמינות גבוהה.
משתמשים ב-Cloud Logging וב-Cloud Monitoring ומפעילים רישום ביומן של מדיניות הרשת.

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

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

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

כדי להימנע מיצירה ידנית של כללי חומת אש, צריך להקצות לחשבון השירות של GKE בפרויקט המארח תפקיד בהתאמה אישית עם הרשאות מינימליות בשם service-HOST_PROJECT_NUMBER@container-engine-robot.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 של שירות מסוים מתוזמנים בכמה אזורים.

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

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

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

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

חשוב לדעת שיש עלויות שקשורות ל-Google Cloud Observability.

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

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

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

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

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

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

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

  • גרסת אשכול GKE: באשכול GKE צריך להשתמש בגרסה ‎1.31.0-gke.1506000 ואילך.
  • התוסף HTTP Load Balancing: התוסף HttpLoadBalancing צריך להיות מופעל באשכול (הוא מופעל כברירת מחדל).
  • מאזן עומסים שמבוסס על שירות לקצה העורפי: צריך לכלול את ההערה cloud.google.com/l4-rbs: "enabled" במניפסט של השירות כדי לוודא ש-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:
    cloud.google.com/l4-rbs: "enabled"
    networking.gke.io/weighted-load-balancing: pods-per-node
spec:
  type: LoadBalancer
  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. מגדירים כללי anti-affinity של Pod במניפסטים של הפריסה.

בדוגמה הבאה מוצג מניפסט של פריסה עם אנטי-אפיניות של 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, חשוב לוודא שהפודים מחולקים באופן שווה בין הצמתים.

השבתת זיקה של צומת

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

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

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

בדוגמה הבאה מוצג מניפסט של 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 פועל בשכבת האפליקציה ומספק יכולות מתקדמות של ניהול תנועה.

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

אזור תרגל
VPC design
שיטות לניהול כתובות IP
אפשרויות אבטחה ברשת
שינוי גודל
הצגת אפליקציות
פעולות וניהול
חלוקת תנועה שווה

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