שליטה בתקשורת בין Pods ושירותים באמצעות מדיניות רשת

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

אפשר גם לשלוט בתעבורת הנתונים היוצאת (egress) של ה-Pods לכל נקודת קצה או שירות מחוץ לאשכול באמצעות מדיניות רשת ב-Kubernetes של שם דומיין מוגדר במלואו (FQDN). מידע נוסף זמין במאמר שליטה בתקשורת בין Pods לשירותים באמצעות FQDN.

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

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

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

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

תוספים של NetworkPolicy ב-GKE

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

• ‫GKE Dataplane V2, שמבוסס על Cilium. GKE Dataplane V2 הוא תוסף הרשת המומלץ לכל האשכולות, והוא ברירת המחדל לאשכולות Autopilot.
• תוסף מדיניות רשת ב-Kubernetes Calico, שזמין רק באשכולות רגילים.

אם לא מגדירים פלאגין של רשת מנוהלת באשכול, צריך פלאגין בניהול עצמי כדי לאכוף את מדיניות רשת ב-Kubernetes. אם לא מוגדר פלאגין לרשת, לא נאכפת מדיניות רשת.

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

דרישות ומגבלות

הדרישות והמגבלות הבאות חלות על אשכולות Autopilot ועל אשכולות רגילים:

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

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

• אם משתמשים במדיניות רשת עם איחוד זהויות של עומסי עבודה ל-GKE, צריך לאפשר יציאה לשרת המטא-נתונים.
• הפעלת האכיפה של מדיניות רשת ב-Kubernetes מגדילה את הזיכרון שבשימוש בתהליך kube-system בכ-128MB, ודורשת כ-300 מילי-ליבות של מעבד (CPU). המשמעות היא שאם מפעילים מדיניות רשת באשכול קיים, יכול להיות שיהיה צורך להגדיל את גודל האשכול כדי להמשיך להפעיל את עומסי העבודה המתוזמנים.
• כדי להפעיל את האכיפה של מדיניות רשת ב-Kubernetes, צריך ליצור מחדש את הצמתים. אם באשכול שלכם יש חלון זמן לתחזוקה פעיל, הצמתים לא נוצרים מחדש באופן אוטומטי עד לחלון זמן לתחזוקה הבא. אם אתם מעדיפים, אתם יכולים לשדרג את האשכול באופן ידני מתי שתרצו.
• גודל האשכול המינימלי הנדרש להפעלת אכיפת מדיניות הרשת הוא שלוש מכונות וירטואליות e2-medium או מכונה וירטואלית אחת עם יותר מ-1 vCPU שניתן להקצאה. לפרטים נוספים, אפשר לעיין בבעיות ידועות ב-GKE.
• מדיניות רשת לא נתמכת באשכולות שהצמתים שלהם הם מופעי f1-micro או g1-small, כי דרישות המשאבים גבוהות מדי.

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

המגבלות הבאות רלוונטיות ל-Pods שמשתמשים בהגדרה hostNetwork: true:

• שדה podSelector ריק ב-NetworkPolicy בוחר את כל ה-Pods במרחב השמות הזה, מלבד ה-Pods עם ההגדרה hostNetwork: true.

• באשכולות שמשתמשים ב-GKE Dataplane V2, אי אפשר להשתמש באף אחד מהשדות הבאים כדי לזהות תנועה אל או מ-Pods שמשתמשים בהגדרה hostNetwork: true:

  • ingress[].from[].podSelector
  • ingress[].from[].namespaceSelector
  • egress[].to[].namespaceSelector
  • egress[].to[].podSelector
  • ingress[].from[].ipBlock
  • egress[].to[].ipBlock

• באשכולות שמשתמשים במישור הנתונים מדור קודם, אפשר להשתמש רק בשדות ingress[].from[].ipBlock ו-egress[].to[].ipBlock כדי לזהות תנועה אל או מ-Pods שמשתמשים בהגדרה hostNetwork: true. אי אפשר להשתמש באף אחד מהשדות הבאים כדי לזהות את התנועה הזו:

  • ingress[].from[].podSelector
  • ingress[].from[].namespaceSelector
  • egress[].to[].namespaceSelector
  • egress[].to[].podSelector

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

אם אתם משתמשים ב-GKE Dataplane V2 באשכול, דלגו אל יצירת מדיניות רשת.

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

לפני שממשיכים: מדיניות הרשת תיאכף כשיוצרים מחדש את הצמתים.

השבתת האכיפה של מדיניות רשת ב-Kubernetes באשכול Standard

אפשר להשבית את האכיפה של מדיניות רשת ב-Kubernetes באמצעות ה-CLI של gcloud,‏ Google Cloud המסוף או GKE API. אי אפשר להשבית את האכיפה של מדיניות הרשת באשכולות Autopilot או באשכולות שמשתמשים ב-GKE Dataplane V2.

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

יצירת מדיניות רשת ב-Kubernetes

אפשר ליצור מדיניות רשת באמצעות Kubernetes Network Policy API.

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

• סקירה כללית של מדיניות הרשת
• הצהרה על מדיניות הרשת

מדיניות רשת ב-Kubernetes ואיחוד זהויות של עומסי עבודה ל-GKE

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

• באשכולות שמריצים GKE בגרסה 1.21.0-gke.1000 ואילך, צריך לאפשר יציאה אל 169.254.169.252/32 ביציאות 988 ו-987.
• באשכולות שמריצים גרסאות GKE מוקדמות מ-1.21.0-gke.1000, צריך לאפשר יציאה אל 127.0.0.1/32 ביציאות 988 ו-987.
• באשכולות שמופעל בהם GKE Dataplane V2, צריך לאפשר תעבורת נתונים יוצאת אל 169.254.169.254/32 ביציאות 80 ו-8080.

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

מעבר מ-Calico ל-GKE Dataplane V2

אם אתם מעבירים את מדיניות הרשת מ-Calico ל-GKE Dataplane V2, כדאי לשים לב למגבלות הבאות:

• אי אפשר להשתמש בכתובת IP של Pod או Service בשדה ipBlock.cidr של מניפסט NetworkPolicy. חובה להפנות לעומסי עבודה באמצעות תוויות. לדוגמה, ההגדרה הבאה לא תקינה:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• אי אפשר לציין שדה ports.port ריק במניפסט NetworkPolicy. אם מציינים פרוטוקול, צריך לציין גם יציאה. לדוגמה, ההגדרה הבאה לא חוקית:

  ingress:
  - ports:
    - protocol: TCP
  

עבודה עם מאזני עומסים של אפליקציות

כשמחילים Ingress על Service כדי ליצור מאזן עומסים של HTTP(S), צריך לוודא שמדיניות רשת ב-Kubernetes מאפשרת תעבורת נתונים מ טווח כתובות ה-IP של בדיקות תקינות של מאזן עומסים של אפליקציות מסוג HTTP(S).

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

איזון עומסים מובנה בקונטיינר, שמופעל כברירת מחדל בכל אשכולות GKE, מנתב את תעבורת הנתונים ישירות לנקודות הקצה של ה-Pod. כדי לעשות את זה, שירותי GKE מקבלים באופן אוטומטי את ההערה cloud.google.com/neg: '{"ingress": true}'. עם זאת, הפעלת מדיניות רשת ב-Kubernetes של GKE היא אחד מהתנאים הספציפיים שמונעים את ההפעלה של איזון עומסים מבוסס-קונטיינרים כברירת מחדל. כדי לשמור על היתרונות של איזון עומסים מובנה ב-Container כשמשתמשים במדיניות רשת, צריך להחיל באופן ידני את ההערה הבאה על מניפסטים של שירותים:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

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

הכללה של טווחי כתובות IP של Pod בכללי ipBlock

כדי לשלוט בתנועה של Pods ספציפיים, תמיד צריך לבחור את ה-Pods לפי מרחב השמות שלהם או לפי התוויות של ה-Pods באמצעות השדות namespaceSelector ו-podSelector בכללי הכניסה או היציאה של NetworkPolicy. לא מומלץ להשתמש בשדה ipBlock.cidr כדי לבחור בכוונה טווחי כתובות IP של Pod, שהן ארעיות. בפרויקט Kubernetes לא מוגדר במפורש אופן הפעולה של השדה ipBlock.cidr כשהוא כולל טווחי כתובות IP של Pod. ציון טווחי CIDR רחבים בשדה הזה, כמו 0.0.0.0/0 (שכוללים את טווחי כתובות ה-IP של ה-Pod), עלול להוביל לתוצאות לא צפויות בהטמעות שונות של NetworkPolicy.

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

התנהגות של ipBlock ב-GKE Dataplane V2

ביישום GKE Dataplane V2 של NetworkPolicy, תעבורת הנתונים של ה-Pod אף פעם לא מכוסה על ידי כלל ipBlock. לכן, גם אם תגדירו כלל רחב כמו cidr: '0.0.0.0/0', הוא לא יכלול תנועה של Pod. האפשרות הזו שימושית כי היא מאפשרת, למשל, לקבוצות Pod במרחב שמות לקבל תעבורת נתונים מהאינטרנט, בלי לאפשר גם תעבורת נתונים מקבוצות Pod. כדי לכלול גם תנועה של Pod, צריך לבחור Pod באופן מפורש באמצעות עוד Pod או בורר של מרחב שמות בהגדרות של כללי הכניסה או היציאה של NetworkPolicy.

ההתנהגות של ipBlock ב-Calico

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

בדוגמה הזו, POD_IP_RANGE הוא טווח כתובות ה-IPv4 של ה-Pod באשכול, לדוגמה 10.95.0.0/17. אם יש לכם כמה טווחי כתובות IP, אתם יכולים לכלול אותם בנפרד במערך, למשל ['10.95.0.0/17', '10.108.128.0/17'].

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

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

‫externalTrafficPolicy יכול לקבל שני ערכים:

• ‫Cluster: כשמגדירים את externalTrafficPolicy לערך Cluster, יעד ה-Pod רואה את כתובת ה-IP של המקור ככתובת ה-IP של הצומת שבו התקבלה התנועה בהתחלה. אם יש לכם NetworkPolicy שחוסם תנועה על סמך כתובות IP של לקוחות, אבל לא כולל את כתובות ה-IP של הצמתים המרוחקים, יכול להיות שהוא יחסום בטעות תנועה חיצונית מהלקוחות החיצוניים שצוינו בכללי המדיניות. כדי למנוע את זה, צריך ליצור מדיניות שמאפשרת תנועה מכל הצמתים באשכול. עם זאת, המדיניות הזו תאפשר תנועה מכל לקוח חיצוני.

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

פתרון בעיות

אין אפשרות ליצור תקשורת בין ה-Pods לבין מישור הבקרה באשכולות שמשתמשים ב-Private Service Connect

יכול להיות שיהיה פודים באשכולות GKE שמשתמשים ב-Private Service Connect שיתקלו בבעיה בתקשורת עם מישור הבקרה אם היציאה של הפוד לכתובת ה-IP הפנימית של מישור הבקרה מוגבלת במדיניות היציאה מהרשת.

כדי לפתור את הבעיה:

1. מוודאים שהאשכול משתמש ב-Private Service Connect. באשכולות שמשתמשים ב-Private Service Connect, אם משתמשים בדגל master-ipv4-cidr כשיוצרים את רשת המשנה, GKE מקצה לכל מישור בקרה כתובת IP פנימית מהערכים שהגדרתם ב-master-ipv4-cidr. אחרת, GKE משתמש ברשת המשנה של צומת האשכול כדי להקצות לכל מישור בקרה כתובת IP פנימית.

2. מגדירים את מדיניות היציאה של האשכול כך שתאפשר תעבורת נתונים לכתובת ה-IP הפנימית של מישור הבקרה.

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

   gcloud

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

   gcloud container clusters describe CLUSTER_NAME
   

   מחליפים את CLUSTER_NAME בשם האשכול.

   הפקודה הזו מאחזרת את privateEndpoint של האשכול שצוין.

   המסוף

   1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

      מעבר אל Google Kubernetes Engine

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

   3. בקטע Cluster basics (יסודות של אשכול), עוברים אל Internal endpoint, שבו מופיעה כתובת ה-IP הפנימית.

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

העדכון של האשכול מתבצע לאט

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

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

יחידות Pod שנפרסו באופן ידני לא מתוזמנות

כשמפעילים את האכיפה של מדיניות רשת ב-Kubernetes במישור הבקרה של אשכול קיים, GKE מבטל את התזמון של כל ה-Pods של ip-masquerade-agent או של צומת Calico שפרסתם באופן ידני.

מערכת GKE לא מתזמנת מחדש את ה-Pods האלה עד שהאכיפה של מדיניות רשת ב-Kubernetes מופעלת בצמתי האשכול ועד שהצמתים נוצרים מחדש.

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

כדי למזער את משך השיבוש הזה, אפשר להקצות ידנית את התוויות הבאות לצמתי האשכול:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

מדיניות הרשת לא נכנסת לתוקף

אם מדיניות NetworkPolicy לא נכנסת לתוקף, אפשר לפתור את הבעיה באמצעות השלבים הבאים:

1. מוודאים שאכיפת מדיניות הרשת מופעלת. הפקודה שבה משתמשים תלויה בשאלה אם GKE Dataplane V2 מופעל באשכול.

   אם הפעלתם את GKE Dataplane V2 באשכול, מריצים את הפקודה הבאה:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

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

   אם לא הפעלתם את GKE Dataplane V2 באשכול, מריצים את הפקודה הבאה:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

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

2. בודקים את התוויות של ה-Pod:

   kubectl describe pod POD_NAME
   

   מחליפים את POD_NAME בשם של ה-Pod.

   הפלט אמור להיראות כך:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. מוודאים שהתוויות במדיניות זהות לתוויות ב-Pod:

   kubectl describe networkpolicy
   

   הפלט אמור להיראות כך:

   PodSelector: app=store
   

   בפלט הזה, התוויות app=store זהות לתוויות app=store מהשלב הקודם.

4. בודקים אם יש מדיניות רשת שבוחרת את עומסי העבודה:

   kubectl get networkpolicy
   

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

   kubectl describe networkpolicy
   

   הפלט אמור להיראות כך:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

בעיות מוכרות

רצף המודעות תקוע במצב containerCreating

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

בכרטיסייה אירועים של הפוד, תופיע הודעה דומה לזו שבהמשך:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

כדי לפתור את הבעיה, צריך להשתמש ב-IPAM מקומי למארח עבור Calico במקום ב-calico-ipam באשכולות GKE.

503 Calico readiness probe failures in large clusters

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

כדי לשנות את הערכים, עורכים את calico-node-vertical-autoscaler ConfigMap כדי להשתמש באותם ערכי פרמטרים בשדות base ו-max. הגישה הזו משביתה בקשות דינמיות למשאבי CPU, ומפסיקה בקשות משתנות של CPU עם תחלופת צמתים:

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-node-vertical-autoscaler
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: EnsureExists
data:
  node-autoscaler: |-
    {
      "calico-node": {
        "requests": {
          "cpu": {
            "base": "200m",
            "step": "100m",
            "nodesPerStep": 50,
            "max": "200m"
          }
        }
      }
    }

הגדרת הערך של השדה base (200m) כגבוה יותר מהערך של השדה step (100m) עוזרת להבטיח של-calico-node Pods יהיו מספיק משאבי מעבד (CPU) לאשכולות של עד 60 צמתים, בהתאם לנוסחה של Autoscaler, כי המעבד המבוקש לא יותאם יותר למספר הצמתים.

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

• לפעול לפי המדריך בנושא מדיניות הרשת.

• מידע נוסף על מדיניות רשת ב-Kubernetes

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

• שימוש ברישום ביומן של מדיניות רשת ב-Kubernetes.

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