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

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

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

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

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

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

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

לסקירה כללית של כל השיטות המומלצות ל-GKE, קראו את המאמר שיטות מומלצות ל-GKE.

שיטות מומלצות לתכנון 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 לשירותים פנימיים של LoadBalancer.

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

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

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

  • טווח כתובות ה-IP של מישור הבקרה: צריך להשתמש ברשת משנה (subnet) מסוג ‎ /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 בקבוצת רשתות שכנות (peering) של ה-VPC שלכם, כי GKE מייבא את המסלול הזה לפרויקט שלכם. כלומר, אם יש לכם מסלולים לאותו CIDR בפרויקט, יכול להיות שתיתקלו בבעיות בניווט.

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

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

טווח כתובות ה-IP של ה-Pod ושל השירות מיוצג כטווח משני נפרד של רשת המשנה, שמוטמע ככתובות 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, באשכולות Standard תצטרכו להשבית במפורש את 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

תכנון צפיפות הפודים לכל צומת

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

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

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

במערכות Autopilot המספר המקסימלי של Pods לכל צומת מוגדר באופן דינמי עד 256 (עם הקצאה של עד טווח ‎ /23 לכל צומת). אי אפשר להגדיר את ההגדרה הזו באשכולות של 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 נוספים לפודים באמצעות CIDR לא רציף לכמה פודים.

שיתוף כתובות IP לשירותי LoadBalancer פנימיים

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

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

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

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

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

שימוש ב-GKE Dataplane V2
צמצום החשיפה של הצומת.
צמצום החשיפה של מישור הבקרה של האשכול.
אישור גישה למישור הבקרה.
הפעלת קישוריות של מישור הבקרה.
פריסת שרתי proxy לגישה למישור הבקרה מרשתות שנוצרו בהן קשרי עמיתים.
הגבלת התנועה באשכול באמצעות מדיניות רשת ב-Kubernetes.
הפעלת כללי מדיניות האבטחה של 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 כשיוצרים אשכול. אחרי שמגדירים את מדיניות הרשת ב-Kubernetes, אפשר להגדיר אובייקט CRD של NetworkLogging כברירת מחדל כדי לתעד חיבורי רשת שאושרו ונדחו. מומלץ ליצור אשכולות עם GKE Dataplane V2 כדי לנצל את כל היתרונות של התכונות המובנות, כמו רישום ביומן של מדיניות רשת ב-Kubernetes.

מזעור החשיפה של הצומת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הפעלת מדיניות האבטחה של Google Cloud Armor ל-Ingress

באמצעות כללי מדיניות האבטחה של Google Cloud Armor, אתם יכולים להגן על אפליקציות שמשתמשות במאזני עומסים חיצוניים של אפליקציות (ALB) מפני מתקפות DDoS ומתקפות מבוססות-אינטרנט אחרות, על ידי חסימת תנועה כזו בקצה הרשת. ב-GKE, כדי להפעיל כללי מדיניות אבטחה של Google Cloud Armor לאפליקציות, משתמשים ב-Ingress עבור מאזני עומסים חיצוניים של אפליקציות ומוסיפים כללי מדיניות אבטחה ל-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. ‫NodeLocal DNSCache הוא תוסף שמוטמע כ-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 כפול לתנועה של Pods (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) חיצוני. איזון עומסים שמקורם בקונטיינר מפחית את מספר הקפיצות ברשת, מקצר את זמן האחזור ומספק חלוקה מדויקת יותר של תעבורת הנתונים. היא גם משפרת את הנראות של זמן הלוך ושוב ומאפשרת להשתמש בתכונות של איזון עומסים כמו Google Cloud Armor.

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

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

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

אם משתמשים ב-Ingress כדי לחשוף שירותים, צריך להשתמש בהגדרת בדיקת תקינות ב-BackendConfig CRD כדי להשתמש בפונקציונליות של בדיקת התקינות של מאזן עומסים של אפליקציות (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 חופפות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השבתה או הגדרה זהירה של זיקה לסשן

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

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

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

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

  • גרסת אשכול GKE: אשכול GKE צריך להשתמש בגרסה ‎1.31.0-gke.1506000 ואילך.
  • תוסף לאיזון עומסים ב-HTTP: התוסף HttpLoadBalancing צריך להיות מופעל באשכול (הוא מופעל כברירת מחדל). אם האשכול שלכם הוא בגרסה 1.36 ומעלה, התוסף הזה לא נדרש לשירותי קצה עורפי.
  • מאזן עומסים שמבוסס על שירות לקצה העורפי: מגדירים את השדה spec.loadBalancerClass לערך networking.gke.io/l4-regional-external במניפסט של השירות כדי לוודא ש-GKE יוצר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי. בשדה הזה נדרשת גרסת GKE‏ 1.33.1-gke.1779000 ואילך. מאזני עומסים שמבוססים על מאגר יעדים לא תומכים באיזון עומסים משוקלל.
  • הערה לגבי איזון עומסים משוקלל: כוללים את ההערה 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

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

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

כדי למנוע תזמון של Pods מאותו שירות באותו צומת, משתמשים ב-Pod 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 מפוזרים באופן שווה בין הצמתים.

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

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

שימוש בבדיקות מוכנות (readiness probes)

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

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

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

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