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

טייס אוטומטי רגילה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

* מוודאים שיש לכם אשכול קיים של Autopilot או Standard. אם אתם צריכים אשכול כזה, צריך ליצור אשכול Autopilot.

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

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

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

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

• אם משתמשים במדיניות רשת עם איחוד זהויות של עומסי עבודה ל-GKE, צריך לאפשר יציאה לשרת המטא-נתונים.
• הפעלת אכיפת מדיניות הרשת מגדילה את הזיכרון שבשימוש של התהליך kube-system בכ-128MB, ודורשת כ-300 מילי-ליבות של מעבד. המשמעות היא שאם מפעילים מדיניות רשת באשכול קיים, יכול להיות שיהיה צורך להגדיל את גודל האשכול כדי להמשיך להפעיל את עומסי העבודה המתוזמנים.
• כדי להפעיל את האכיפה של מדיניות הרשת, צריך ליצור מחדש את הצמתים. אם באשכול שלכם יש חלון תחזוקה פעיל, הצמתים לא נוצרים מחדש באופן אוטומטי עד לחלון התחזוקה הבא. אם אתם מעדיפים, אתם יכולים לשדרג את האשכול באופן ידני בכל שלב.
• גודל האשכול המינימלי הנדרש להפעלת אכיפה של מדיניות רשת הוא שלוש מכונות e2-medium או מכונה אחת מסוג מכונה עם יותר מ-1 vCPU ניתן להקצאה. לפרטים נוספים, ראו בעיות ידועות ב-GKE.
• מדיניות רשת לא נתמכת באשכולות שהצמתים שלהם הם מופעי f1-micro או g1-small, כי דרישות המשאבים גבוהות מדי.
• ‫GKE Dataplane V2 ו-Calico לא אוכפים מדיניות רשת עבור Pods שמשתמשים בהגדרה spec.hostNetwork: true.

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

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

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

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

חשוב: ‏ GKE פועל בהתאם למדיניות התחזוקה כשיוצר מחדש את הצמתים לשינוי הזה באמצעות אסטרטגיית שדרוג הצמתים, והוא תלוי בזמינות המשאבים. השבתה של שדרוגים אוטומטיים של צמתים לא מונעת את השינוי הזה. כדי להחיל את השינויים על הצמתים באופן ידני, משתמשים ב-CLI של gcloud כדי לקרוא לפקודה gcloud container clusters upgrade, ומעבירים את הדגל --cluster-version עם אותה גרסת GKE שמאגר הצמתים כבר פועל בה.

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

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. כדי להפעיל את האכיפה של מדיניות הרשת באשכול, מבצעים את המשימות הבאות:

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

   1. מריצים את הפקודה הבאה כדי להפעיל את התוסף:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

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

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

      gcloud container clusters update CLUSTER_NAME --enable-network-policy
      

המסוף

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

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

1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

   מעבר אל Google Kubernetes Engine

2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

3. בקטע Cluster Networking, בשדה Calico Kubernetes Network Policy, לוחצים על Edit network policy.

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

5. מחכים שהשינויים יחולו. כדי לעקוב אחרי ההתקדמות, לוחצים על Notifications (התראות) בפינה השמאלית העליונה של המסוף.

6. בשדה Calico Kubernetes Network Policy, לוחצים שוב על Edit network policy.

7. בתיבת הדו-שיח Edit network policy, מסמנים את התיבה Enable Calico Kubernetes network policy for nodes.

8. לוחצים על שמירת השינויים.

API

כדי להפעיל את האכיפה של מדיניות הרשת:

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

1. מציינים את האובייקט networkPolicy בתוך האובייקט cluster שמעבירים אל projects.zones.clusters.create או אל projects.zones.clusters.update.

2. אובייקט networkPolicy דורש enum שמציין באיזה ספק של מדיניות רשת להשתמש, וערך בוליאני שמציין אם להפעיל מדיניות רשת. אם מפעילים את מדיניות הרשת אבל לא מגדירים את הספק, הפקודות create ו-update מחזירות שגיאה.

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

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

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

חשוב: ‏ GKE פועל בהתאם למדיניות התחזוקה כשיוצר מחדש את הצמתים לשינוי הזה באמצעות אסטרטגיית שדרוג הצמתים, והוא תלוי בזמינות המשאבים. השבתה של שדרוגים אוטומטיים של צמתים לא מונעת את השינוי הזה. כדי להחיל את השינויים על הצמתים באופן ידני, משתמשים ב-CLI של gcloud כדי לקרוא לפקודה gcloud container clusters upgrade, ומעבירים את הדגל --cluster-version עם אותה גרסת GKE שמאגר הצמתים כבר פועל בה.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. כדי להשבית את האכיפה של מדיניות הרשת, מבצעים את המשימות הבאות:

   1. משביתים את האכיפה של מדיניות הרשת באשכול:

   gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
   

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

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

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

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

   אם הפעולה מצליחה, הפלט דומה לפלט הבא:

   No resources found
   

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

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

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

4. אחרי שכל הצמתים נוצרו מחדש, משביתים את התוסף:

   gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
   

המסוף

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

1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

   מעבר אל Google Kubernetes Engine

2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

3. בקטע Networking, בשדה Network policy, לוחצים על Edit network policy.

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

5. מחכים שהשינויים יחולו, ואז לוחצים שוב על עריכת מדיניות הרשת.

6. מבטלים את הסימון בתיבת הסימון הפעלת מדיניות רשת עבור המאסטר.

7. לוחצים על שמירת השינויים.

API

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

1. מעדכנים את האשכול לשימוש ב-networkPolicy.enabled: false באמצעות setNetworkPolicy API.

2. מוודאים שכל הצמתים נוצרו מחדש באמצעות ה-CLI של gcloud:

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

   אם הפעולה מצליחה, הפלט דומה לפלט הבא:

   No resources found
   

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

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

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

3. מעדכנים את האשכול לשימוש ב-update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true באמצעות updateCluster API.

יצירת מדיניות רשת

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

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

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

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

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

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

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

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

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

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

  - ipBlock:
      cidr: 10.8.0.6/32
  

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

  ingress:
  - ports:
    - protocol: TCP
  

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

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

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

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

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

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

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

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

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

כדי לשלוט בתעבורה של Pods ספציפיים, תמיד בוחרים את ה-Pods לפי מרחב השמות שלהם או לפי התוויות של ה-Pods באמצעות השדות namespaceSelector ו-podSelector בכללי תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress) של 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'].

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

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

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

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

פריסת Pods באופן ידני ללא תזמון

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

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

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

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

• 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
   

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

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

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

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

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
   

בעיות מוכרות

ה-Pod תקוע במצב containerCreating

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

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

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

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

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

• הוראות לשימוש במדיניות הרשת

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

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

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

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