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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

היתרונות של שימוש באשכולות המותאמים ל-VPC קשורים לתמיכה בכתובות IP חלופיות. לדוגמה, אפשר להשתמש בקבוצות של נקודות קצה ברשת (NEG) רק עם כתובות 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 שכנות חייבים להיות אשכולות שמותאמים ל-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, שנמצא בפרויקט דייר (tenant) שמנוהל על ידי Google ומקושר באמצעות VPC ל-VPC שלכם. טווח כתובות ה-IP הזה לא יכול לחפוף לאף כתובת IP בקבוצת הרשתות השכנות (peering) של ה-VPC, כי GKE מייבא את הנתיב הזה לפרויקט. כלומר, אם יש לכם נתיבים לאותו CIDR בפרויקט, יכול להיות שתיתקלו בבעיות בניתוב.

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

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

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

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

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

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

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

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

לא מומלץ להשתמש בתרגום כתובת רשת של מקור (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 לכל צומת. עם זאת, אפשר להגדיר אשכול רגיל כך שיתמוך בעד 512 Pods לכל צומת, עם טווח ‎/22 ששמור לכל צומת. בהתאם לגודל הצמתים ולפרופיל האפליקציה של ה-Pods, יכול להיות שתפעילו הרבה פחות Pods בכל צומת.

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

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

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

כדאי להשתמש בהקצאת צמתים אוטומטית (NAP) עם הכלי להתאמה אוטומטית של גודל האשכול, במיוחד אם אתם משתמשים באשכולות המותאמים ל-VPC. מידע נוסף זמין במאמר טווחי הגבלת צמתים.

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

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-GKE Dataplane V2

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

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

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

תרשים 1: תקשורת בין צמתים פרטיים

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

צמצום החשיפה של מישור הבקרה של האשכול

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

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

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

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

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

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

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

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

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

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

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

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

פריסת שרתי proxy לגישה למישור הבקרה מרשתות שכנות (peered)

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

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

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

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

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

מדיניות הרשת ב-GKE מוגדרת באמצעות Network Policy API ב-Kubernetes, כדי לאכוף את התקשורת של 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 ל-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 לגישה לאינטרנט מאשכולות

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

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

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

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

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

שיטות מומלצות להתאמה לעומס (scaling) של אפליקציות

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

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

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

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

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

בחירת המשאב הנכון ב-GKE לחשיפת האפליקציה

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

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

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

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

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

שימוש ב-Private Service Connect

אתם יכולים להשתמש ב-Private Service Connect כדי לשתף שירותים של מאזני עומסי רשת פנימיים ב-Passthrough בין רשתות 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..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת בדיקות מוכנות ב-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

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

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

שימוש בניתוב לפי טופולוגיה

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

Cloud Service Mesh

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

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

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

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