‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Autopilot Standard

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

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

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

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

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

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

יישומי פלאגין של NetworkPolicy ב-GKE

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

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

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

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

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

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

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

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת 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 ועל אשכולות רגילים:

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

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

אם משתמשים במדיניות רשת עם איחוד זהויות של עומסי עבודה ל-GKE, צריך לאפשר יציאה לשרת המטא-נתונים.
הפעלת האכיפה של מדיניות רשת ב-Kubernetes מגדילה את הזיכרון שבשימוש של התהליך kube-system בכ-128MB, ודורשת כ-300 מילי-ליבות של מעבד (CPU). המשמעות היא שאם מפעילים מדיניות רשת עבור אשכול קיים, יכול להיות שיהיה צורך להגדיל את גודל האשכול כדי להמשיך להפעיל את עומסי העבודה המתוזמנים.
כדי להפעיל את האכיפה של מדיניות רשת ב-Kubernetes, צריך ליצור מחדש את הצמתים. אם לאשכול יש חלון זמן פעיל לתחזוקה, הצמתים לא נוצרים מחדש באופן אוטומטי עד לחלון הזמן הבא לתחזוקה. אם אתם מעדיפים, אתם יכולים לשדרג את האשכול באופן ידני בכל שלב.
גודל האשכול המינימלי הנדרש להפעלת אכיפה של מדיניות רשת ב-Kubernetes הוא שלוש e2-medium מכונות או מכונה אחת מסוג מכונה עם יותר מ-1 vCPU שניתן להקצאה. לפרטים נוספים, קראו את הבעיות המוכרות ב-GKE.
אין תמיכה במדיניות רשת ב-Kubernetes עבור אשכולות שהצמתים שלהם הם מופעי 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 תיאכף כשהצמתים ייווצרו מחדש.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

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

שימו לב: כברירת מחדל, הפעלת האכיפה של מדיניות רשת ב-Kubernetes באשכול מפעילה גם את האכיפה בצמתים של האשכול, ויכולה לגרום לשיבוש ב-Pods שנפרסו באופן ידני. למידע נוסף, ראו תרמילים שנפרסו ידנית לא מתוזמנים.
1. מריצים את הפקודה הבאה כדי להפעיל את התוסף:
```
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
```
  מחליפים את CLUSTER_NAME בשם האשכול.
2. מריצים את הפקודה הבאה כדי להפעיל את אכיפת מדיניות הרשת באשכול, וכך ליצור מחדש את מאגרי הצמתים של האשכול כשאכיפת מדיניות הרשת מופעלת:
```
gcloud container clusters update CLUSTER_NAME --enable-network-policy
```
  הערה: כדי שמדיניות רשת ב-Kubernetes תפעל, צריך להפעיל את התוסף NetworkPolicy וגם את האכיפה של מדיניות הרשת בצמתים. אם מפעילים רק את התוסף בלי להפעיל את האכיפה בצמתים, לא תיאכף מדיניות כלשהי. בדרך כלל, צריך להריץ את שתי הפקודות ברצף.

המסוף

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

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

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע Cluster Networking, בשדה Calico Kubernetes Network Policy, לוחצים על Edit network policy.
בתיבת הדו-שיח עריכת מדיניות רשת ב-Kubernetes, מסמנים את התיבה הפעלת מדיניות רשת ב-Kubernetes של Calico למישור הבקרה ולוחצים על שמירת השינויים.
מחכים שהשינויים ייכנסו לתוקף. כדי לעקוב אחרי ההתקדמות, לוחצים על התראות בפינה השמאלית העליונה של המסוף.
בשדה Calico Kubernetes Network Policy, לוחצים שוב על Edit network policy.
בתיבת הדו-שיח עריכת מדיניות רשת ב-Kubernetes, מסמנים את התיבה הפעלת מדיניות רשת ב-Kubernetes של Calico לצמתים.
לוחצים על שמירת השינויים.

API

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

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

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

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

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

gcloud

מפעילים את Cloud Shell במסוף Google Cloud .

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי להשבית את האכיפה של מדיניות רשת ב-Kubernetes, מבצעים את המשימות הבאות:
1. משביתים את האכיפה של מדיניות רשת ב-Kubernetes באשכול:
```
gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
```
מחליפים את CLUSTER_NAME בשם האשכול.

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

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

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

המסוף

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

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

כניסה ל-Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע Networking, בשדה מדיניות רשת ב-Kubernetes, לוחצים על Edit network policy.
מבטלים את הסימון בתיבה Enable network policy for nodes ולוחצים על Save Changes.
מחכים שהשינויים יחולו, ואז לוחצים שוב על עריכת מדיניות הרשת.
מבטלים את הסימון בתיבת הסימון Enable network policy for master (הפעלת מדיניות רשת ב-Kubernetes למאסטר).
לוחצים על שמירת השינויים.

API

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

מעדכנים את האשכול כך שישתמש ב-networkPolicy.enabled: false באמצעות ה-API של setNetworkPolicy.
מוודאים שכל הצמתים נוצרו מחדש באמצעות ה-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
```
כשמשביתים את האכיפה של מדיניות רשת ב-Kubernetes, יכול להיות ש-GKE לא יעדכן את הצמתים באופן מיידי אם יש באשכול חלון זמן לתחזוקה או החרגה מוגדרים. מידע נוסף זמין במאמר בנושא עדכון אשכולות איטי.
מעדכנים את האשכול לשימוש ב-update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true באמצעות updateCluster API.

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

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

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

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

אם אתם משתמשים במדיניות רשת ב-Kubernetes עם איחוד זהויות של עומסי עבודה ל-GKE, אתם צריכים לאפשר תעבורת נתונים יוצאת לכתובות ה-IP הבאות כדי שהפודים יוכלו לתקשר עם שרת המטא-נתונים של 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, צריך לאפשר תעבורת נתונים יוצאת (egress) אל 169.254.169.254/32 ביציאות 80 ו-8080.

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

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

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

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

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

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

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

בהטמעה של NetworkPolicy ב-GKE Dataplane V2, תעבורת הנתונים של 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 של המקור שהפודים רואים לתנועה נכנסת, והיא יכולה להשפיע על האופן שבו Kubernetes מעריך את הכללים של NetworkPolicy.

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

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

פתרון בעיות

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

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

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

מוודאים שהאשכול משתמש ב-Private Service Connect. באשכולות שמשתמשים ב-Private Service Connect, אם משתמשים בדגל master-ipv4-cidr כשיוצרים את רשת המשנה, מערכת GKE מקצה לכל מישור בקרה כתובת IP פנימית מהערכים שהגדרתם ב-master-ipv4-cidr. אחרת, GKE משתמש ברשת המשנה של צומת האשכול כדי להקצות לכל מישור בקרה כתובת IP פנימית.
מגדירים את מדיניות היציאה של האשכול כך שתאפשר תעבורת נתונים לכתובת ה-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. מידע נוסף מופיע במאמר בנושא הערות לגבי חלונות תחזוקה.

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

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

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

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

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

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

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

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

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

אם באשכול שלכם מופעל GKE Dataplane V2, מריצים את הפקודה הבאה:
```
kubectl -n kube-system get pods -l k8s-app=cilium
```
אם הפלט ריק, אכיפת מדיניות רשת ב-Kubernetes לא מופעלת.

אם לא מופעל ב-cluster שלכם GKE Dataplane V2, מריצים את הפקודה הבאה:
```
kubectl get nodes -l projectcalico.org/ds-ready=true
```
אם הפלט ריק, אכיפת מדיניות רשת ב-Kubernetes לא מופעלת.

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

kubectl describe pod POD_NAME

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

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

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

מוודאים שהתוויות במדיניות זהות לתוויות ב-Pod:
```
kubectl describe networkpolicy
```
הפלט אמור להיראות כך:
```
PodSelector: app=store
```
בפלט הזה, התוויות של app=store תואמות לתוויות של app=store מהשלב הקודם.
בודקים אם יש כללי מדיניות רשת ב-Kubernetes שבוחרים את עומסי העבודה:
```
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.

בכרטיסייה Events של ה-Pod, תופיע הודעה דומה לזו שבהמשך:

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

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

‫503 כשלים בבדיקת המוכנות של Calico באשכולות גדולים

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

כדי לשנות את הערכים, עורכים את ה-ConfigMap של calico-node-vertical-autoscaler כך שישתמש באותם ערכי פרמטרים בשדות 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, כי בקשת המעבד כבר לא תשתנה בהתאם למספר הצמתים.

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

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

יישומי פלאגין של NetworkPolicy ב-GKE

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

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

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

gcloud

המסוף

API

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

gcloud

המסוף

API

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

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

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

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

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

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

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

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

פתרון בעיות

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

gcloud

המסוף

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

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

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

בעיות מוכרות

הפוד תקוע במצב containerCreating

‫503 כשלים בבדיקת המוכנות של Calico באשכולות גדולים

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

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

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

הפוד תקוע במצב `containerCreating`