הגדרת תמיכה בכמה רשתות לקבוצות Pod

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

אתם יכולים להגדיר אשכולות של Google Kubernetes Engine ‏ (GKE) עם תמיכה בריבוי רשתות ל-Pods, כדי לחבר Pods וצמתים לכמה רשתות נפרדות בו-זמנית. היכולת הזו עוזרת לכם לעמוד בדרישות מיוחדות של הרשת, כמו בידוד תנועה או שיפור התפוקה של עומסי עבודה של מחשוב בעל ביצועים גבוהים (HPC) או וירטואליזציה של פונקציות רשת (NFV).

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

מידע נוסף זמין במאמר מידע על תמיכה בריבוי רשתות עבור Pods.

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

התמיכה בריבוי רשתות ב-Pods כפופה לדרישות ולמגבלות הבאות:

דרישות

• ‫GKE Standard בגרסה 1.28 ואילך.
• ‫GKE Autopilot גרסה ‎1.29.5-gke.1091000 ואילך או גרסה ‎1.30.1-gke.1280000 ואילך.
• התמיכה בריבוי רשתות עבור Pods משתמשת באותן הגדרות ברמת המכונה הווירטואלית כמו ריבוי כרטיסי NIC ב-Compute Engine.
• כדי להשתמש בתמיכה בריבוי רשתות ב-Pods, צריך להשתמש ב-GKE Dataplane V2.
• התמיכה בריבוי רשתות ל-Pods זמינה במערכת ההפעלה שמותאמת לקונטיינרים. התמיכה ב-Ubuntu זמינה בצמתים שמריצים את גרסת GKE‏ ‎1.32.3-gke.1785000 ואילך.

מגבלות כלליות

• התמיכה בריבוי רשתות ב-Pods לא פועלת באשכולות שמופעלת בהם רשת עם פרוטוקול כפול.
• ‫VPC משותף נתמך רק ב-GKE בגרסה 1.28 ואילך.
• ‫Multi-Pod CIDR נתמך רק ב-GKE בגרסה 1.29 ואילך, ורק ברשת ברירת המחדל של ה-Pod.
• לא יכולים להיות טווחי CIDR חופפים ברשתות Pod באותו אשכול GKE.
• כשמפעילים תמיכה בריבוי רשתות עבור קבוצות Pod, אי אפשר להוסיף או להסיר ממשקי רשת של צמתים או רשתות של קבוצות Pod אחרי שיוצרים מאגר צמתים. כדי לשנות את ההגדרות האלה, צריך ליצור מחדש את מאגר הצמתים.
• כברירת מחדל, אין גישה לאינטרנט בממשקים נוספים של רשתות Pod בתוך ה-Pod. אבל אפשר להפעיל אותו ידנית באמצעות Cloud NAT.
• אי אפשר לשנות את שער ברירת המחדל בתוך Pod עם כמה ממשקים באמצעות ה-API. שער ברירת המחדל חייב להיות מחובר לרשת ברירת המחדל של ה-Pod.
• תמיד צריך לכלול את רשת ה-Pod שמוגדרת כברירת מחדל ב-Pods, גם אם יוצרים רשתות Pod נוספות או ממשקי Pod נוספים.
• אי אפשר להגדיר את התכונה 'ריבוי רשתות' אם הוגדר Managed Hubble.
• כדי להשתמש ב-VPC משותף, צריך לוודא שאשכול GKE פועל בגרסה 1.28.4 ואילך.
• בפריסות של VPC משותף, כל ממשקי הרשת (NIC) שמצורפים לצמתים צריכים להשתייך לאותו פרויקט כמו הפרויקט המארח.
• שם של אובייקטים ברשת שמוקלדים במכשיר לא יכול להיות ארוך מ-41 תווים. הנתיב המלא של כל שקע דומיין של UNIX מורכב, כולל שם הרשת המתאים. ב-Linux יש מגבלה על אורך נתיבי שקע (מתחת ל-107 בייטים). אחרי שכוללים את הספרייה, הקידומת של שם הקובץ והסיומת .sock, שם הרשת מוגבל למקסימום 41 תווים.
• אי אפשר לשנות אובייקטים מסוג Network ו-GKENetworkParamSet. כדי לעדכן את האובייקטים האלה, צריך למחוק אותם וליצור אותם מחדש.

מגבלות של ערכת פיתוח של מישור נתונים (DPDK) ומכשירים

• כרטיס רשת של מכונה וירטואלית שמועבר ל-Pod ככרטיס רשת מסוג Device לא זמין ל-Pods אחרים באותו צומת.
• צריך להפעיל תרמילים שמשתמשים במצב DPDK במצב הרשאות כדי לגשת למכשירי VFIO.
• מצב אוטומטי לא תומך ב-DPDK.
• במצב DPDK, המכשיר נחשב למשאב של צומת ומצורף רק לקונטיינר הראשון (לא init) ב-Pod. אם רוצים לפצל כמה מכשירי DPDK בין קונטיינרים באותו Pod, צריך להריץ את הקונטיינרים האלה ב-Pods נפרדים.
• בצמתים של Ubuntu, רשתות DPDK-VFIO נתמכות רק ב-GKE מגרסה 1.33.1-gke.1959000 ואילך.

מגבלות על שינוי הגודל

‫GKE מספק ארכיטקטורת רשת גמישה שמאפשרת לכם לשנות את גודל האשכול. אפשר להוסיף עוד רשתות צמתים ורשתות של Pod לאשכול. כדי לשנות את גודל האשכול:

• אפשר להוסיף עד 8 רשתות צמתים נוספות לכל מאגר צמתים של GKE. זוהי אותה מגבלת גודל כמו במכונות וירטואליות ב-Compute Engine.
• לכל פוד יכולות להיות עד 8 רשתות נוספות שמצורפות אליו.
• אפשר להגדיר עד 35 רשתות של Pod בכל אחת מ-8 רשתות הצמתים במאגר צמתים יחיד. אפשר לפרק את זה לשילובים שונים, כמו:
  • ‫7 רשתות צמתים עם 5 רשתות של Pod כל אחת
  • ‫5 רשתות צמתים עם 7 רשתות Pod בכל אחת
  • רשת אחת של צמתים עם 30 רשתות של Pod. המגבלה של טווחי כתובות משניים לכל רשת משנה היא 30.
• אפשר להגדיר עד 50 רשתות של פודים לכל אשכול.
• אפשר להגדיר עד 32 תרמילי רשת מרובים לכל צומת.
• אפשר להשתמש בעד 5,000 צמתים עם כמה ממשקים.
• אפשר להוסיף עד 100,000 ממשקים בכל ה-Pods.

Deploy multi-network Pods

כדי לפרוס Pods עם כמה רשתות:

1. מכינים עוד VPC, רשת משנה (node-network) וטווחים משניים (Pod-network).
2. יוצרים אשכול GKE עם תמיכה בכמה רשתות באמצעות פקודת Google Cloud CLI.
3. יוצרים מאגר צמתים חדש של GKE שמחובר לרשת הצמתים ולרשת ה-Pod הנוספות באמצעות פקודת Google Cloud CLI.
4. יצירת רשת Pod והפניה ל-VPC, לתת-רשת ולטווחים המשניים הנכונים באובייקטים של רשתות מרובות באמצעות Kubernetes API.
5. בהגדרת עומס העבודה, מפנים אל אובייקט הרשת שהוכן ב-Kubernetes באמצעות Kubernetes API.

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

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

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

• קוראים את הדרישות והמגבלות.

הכנת VPC נוסף

Google Cloud יוצר רשת ברירת מחדל של Pod במהלך יצירת האשכול, שמשויכת למאגר הצמתים של GKE שבו נעשה שימוש במהלך היצירה הראשונית של אשכול GKE. רשת ה-Pod שמוגדרת כברירת מחדל זמינה בכל הצמתים וה-Pods של האשכול. כדי לאפשר יכולות של ריבוי רשתות במאגר הצמתים, צריך להכין רשתות VPC קיימות או חדשות שתומכות ברשתות מסוג Layer 3 ו-Device.

כדי להכין עוד VPC, צריך לעמוד בדרישות הבאות:

• רשת מסוג Layer 3 ו-Netdevice:

  • יוצרים טווח משני אם משתמשים ברשתות מסוג Layer 3.
  • חשוב לוודא שגודל ה-CIDR של הטווח המשני גדול מספיק כדי להכיל את מספר הצמתים במאגר הצמתים ואת מספר ה-Pods לכל צומת שרוצים להגדיר.
  • בדומה לרשת ברירת המחדל של ה-Pod, גם רשתות ה-Pod האחרות משתמשות בהקצאת יתר של כתובות IP. בטווח הכתובות המשני של כתובות ה-IP צריך להיות מספר כפול של כתובות IP לכל צומת ממספר ה-Pods לכל צומת.

• ‫Device type network requirements: Create a regular subnet on a VPC. לא צריך להגדיר טווח משני.

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

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

יוצרים רשת VPC שתומכת במכשיר מסוג Layer 3

כדי ליצור רשת VPC שתומכת במכשיר מסוג Layer 3:

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

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

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

מחליפים את מה שכתוב בשדות הבאים:

• ‫SUBNET_NAME: השם של רשת המשנה.
• ‫PROJECT_ID: מזהה הפרויקט שמכיל את רשת ה-VPC שבה נוצרת רשת המשנה.
• ‫SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה, בסימון CIDR.
• ‫NETWORK_NAME: השם של רשת ה-VPC שמכילה את תת-הרשת החדשה.
• ‫REGION: האזור Google Cloud שבו נוצרת תת-הרשת החדשה.
• ‫SECONDARY_RANGE_NAME: השם של הטווח המשני.
• SECONDARY_IP_RANGE טווח כתובות ה-IPv4 המשני בסימון CIDR.

המסוף

1. נכנסים לדף VPC networks במסוף Google Cloud .

2. לוחצים על יצירת רשת VPC.

3. בשדה Name (שם), מזינים את שם הרשת. לדוגמה, l3-vpc.

4. כדי להגדיר את יחידת השידור המקסימלית (MTU) של הרשת, מבצעים את הפעולות הבאות:

   • כדי להשתמש בערך ברירת המחדל 1460, משאירים את תיבת הסימון הגדרת MTU באופן אוטומטי מסומנת.
   • כדי להגדיר ערך מותאם אישית:
     1. קוראים את המידע במאמר בנושא יחידת שידור מקסימלית.
     2. מבטלים את הסימון בתיבה הגדרת MTU באופן אוטומטי.
     3. בשדה יחידת שידור מקסימלית (MTU), בוחרים ערך MTU.

5. בקטע Subnet creation mode (מצב יצירת רשת משנה), בוחרים באפשרות Custom (בהתאמה אישית).

6. לוחצים על הוספת רשת משנה.

7. בקטע New subnet (רשת משנה חדשה), מציינים את פרמטרים ההגדרה הבאים של רשת משנה:

   1. מזינים שם. לדוגמה, l3-subnet.

   2. בוחרים Region.

   3. מזינים טווח כתובות IP. זהו טווח ה-IPv4 הראשי של רשת המשנה.

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

   4. כדי להגדיר טווח משני לרשת המשנה, לוחצים על יצירת טווח כתובות IP משני.

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

   5. גישה פרטית ל-Google: אתם יכולים להפעיל גישה פרטית ל-Google לרשת המשנה כשאתם יוצרים אותה או מאוחר יותר על ידי עריכה שלה.

   6. יומני תעבורה: אתם יכולים להפעיל יומני תעבורה של VPC עבור תת-הרשת כשאתם יוצרים אותה או מאוחר יותר על ידי עריכה שלה.

   7. לוחצים על סיום.

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

8. בקטע Firewall rules, מתחת לIPv4 firewall rules, בוחרים אפס או יותר כללים מוגדרים מראש של חומת אש.

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

9. בקטע IPv4 firewall rules (כללי חומת אש של IPv4), כדי לערוך את כלל חומת האש המוגדר מראש לתעבורת נתונים נכנסת (ingress) שנקרא allow-custom, לוחצים על EDIT (עריכה).

   אפשר לערוך רשתות משנה, להוסיף טווחי IPv4 נוספים ולציין פרוטוקולים ויציאות.

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

10. בקטע מצב ניתוב דינמי, עבור רשת ה-VPC. מידע נוסף זמין במאמר בנושא מצב ניתוב דינמי. תמיד אפשר לשנות את מצב הניתוב הדינמי.

11. לוחצים על יצירה.

יצירת רשת VPC שתומכת במכשירים מסוג Netdevice או DPDK

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION

מחליפים את מה שכתוב בשדות הבאים:

• ‫SUBNET_NAME: השם של רשת המשנה.
• ‫PROJECT_ID: מזהה הפרויקט שמכיל את רשת ה-VPC שבה נוצרת רשת המשנה.
• ‫SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה, בסימון CIDR.
• ‫NETWORK_NAME: השם של רשת ה-VPC שמכילה את תת-הרשת החדשה.
• ‫REGION: האזור Google Cloud שבו נוצרת תת-הרשת החדשה.

המסוף

1. נכנסים לדף VPC networks במסוף Google Cloud .

2. לוחצים על יצירת רשת VPC.

3. בשדה Name (שם), מזינים את שם הרשת. לדוגמה, netdevice-vpc או dpdk-vpc.

4. בתפריט הנפתח Maximum transmission unit (MTU) (יחידת שידור מקסימלית), בוחרים את ערך ה-MTU המתאים.

   הערה: לפני שמגדירים את ה-MTU לערך גבוה מ-1460, כדאי לעיין ביחידת השידור המקסימלית.

5. בקטע Subnet creation mode (מצב יצירת רשת משנה), בוחרים באפשרות Custom (בהתאמה אישית).

6. בקטע New subnet (רשת משנה חדשה), מציינים את פרמטרים ההגדרה הבאים של רשת משנה:

   1. מזינים שם. לדוגמה, netdevice-subnet או dpdk-vpc.

   2. בוחרים Region.

   3. מזינים טווח כתובות IP. זהו טווח ה-IPv4 הראשי של רשת המשנה.

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

   4. גישה פרטית ל-Google: בוחרים אם להפעיל גישה פרטית ל-Google עבור רשת המשנה כשיוצרים אותה או מאוחר יותר על ידי עריכה שלה.

   5. יומני תעבורה: אתם יכולים להפעיל יומני תעבורה של VPC עבור תת-הרשת כשאתם יוצרים אותה או מאוחר יותר על ידי עריכה שלה.

   6. לוחצים על סיום.

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

7. בקטע Firewall rules, מתחת לIPv4 firewall rules, בוחרים אפס או יותר כללים מוגדרים מראש של חומת אש.

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

8. בקטע IPv4 firewall rules (כללי חומת אש של IPv4), כדי לערוך את כלל חומת האש המוגדר מראש לתעבורת נתונים נכנסת (ingress) שנקרא allow-custom, לוחצים על EDIT (עריכה).

   אפשר לערוך רשתות משנה, להוסיף טווחי IPv4 נוספים ולציין פרוטוקולים ויציאות.

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

9. בקטע מצב ניתוב דינמי, עבור רשת ה-VPC. מידע נוסף זמין במאמר בנושא מצב ניתוב דינמי. תמיד אפשר לשנות את מצב הניתוב הדינמי.

10. לוחצים על יצירה.

יצירת אשכול GKE עם יכולות של כמה רשתות

הפעלת ריבוי רשתות באשכול מוסיפה את ההגדרות הנדרשות של CustomResourceDefinitions ‏ (CRD) לשרת ה-API של האשכול. הוא גם פורס את network-controller-manager, שאחראי על התאמה וניהול של אובייקטים מרובי רשתות. אי אפשר לשנות את הגדרות האשכול אחרי שהוא נוצר.

יצירת אשכול GKE Autopilot עם יכולות של ריבוי רשתות

יוצרים אשכול GKE Autopilot עם יכולות של ריבוי רשתות:

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-multi-networking

מחליפים את מה שכתוב בשדות הבאים:

• ‫CLUSTER_NAME: שם האשכול.
• ‫CLUSTER_VERSION: הגרסה של האשכול.

הדגל --enable-multi-networking מפעיל הגדרות של משאבים מותאמים אישית (CRD) של ריבוי רשתות בשרת ה-API של האשכול הזה, ומפריס network-controller-manager שמכיל את התיאום ואת ניהול מחזור החיים של אובייקטים של ריבוי רשתות.

יצירת אשכול GKE Standard עם יכולות של רשתות מרובות

gcloud

יוצרים אשכול GKE Standard עם יכולות של רשתות מרובות:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

מחליפים את מה שכתוב בשדות הבאים:

• ‫CLUSTER_NAME: שם האשכול.
• ‫CLUSTER_VERSION: הגרסה של האשכול.

הפקודה הזו כוללת את הדגלים הבאים:

• ‫--enable-multi-networking: מפעיל הגדרות של משאבים בהתאמה אישית (CRD) של ריבוי רשתות בשרת ה-API של האשכול הזה, ומפריס network-controller-manager שמכיל את התיאום ואת ניהול מחזור החיים של אובייקטים של ריבוי רשתות.
• ‫--enable-dataplane-v2: מאפשרת את GKE Dataplane V2. הדגל הזה נדרש כדי להפעיל רשתות מרובות.

המסוף

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

   מעבר אל יצירת אשכול Kubernetes

2. מגדירים את אשכול Standard. מידע נוסף זמין במאמרים בנושא יצירת אשכול אזורי או יצירת אשכול אזורי. במהלך יצירת האשכול, בוחרים את הרשת המתאימה ואת תת-הרשת של הצומת.
3. בחלונית הניווט, בקטע Cluster, לוחצים על Networking.
4. מסמנים את התיבה Enable Dataplane V2.
5. בוחרים באפשרות הפעלת ריבוי רשתות.
6. לוחצים על יצירה.

יצירת מאגר צמתים ב-GKE Standard שמחובר לרשתות VPC נוספות

יוצרים מאגר צמתים שכולל צמתים שמחוברים לרשת הצמתים (VPC ורשת משנה) ולרשת הפודים (טווח משני) שנוצרו במאמר יצירת רשת פודים.

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

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS

מחליפים את מה שכתוב בשדות הבאים:

• ‫POOL_NAME בשם של מאגר הצמתים החדש.
• ‫CLUSTER_NAME בשם האשכול הקיים שאליו רוצים להוסיף את מאגר הצמתים.
• ‫NETWORK_NAME עם שם הרשת שאליה רוצים לצרף את הצמתים של מאגר הצמתים.
• ‫SUBNET_NAME עם השם של רשת המשנה בתוך הרשת שבה רוצים להשתמש עבור הצמתים.
• POD_IP_RANGE טווח כתובות ה-IP של ה-Pod בתוך תת-הרשת.
• NUMBER_OF_PODS מספר הפודים המקסימלי לכל צומת.

הפקודה הזו כוללת את הדגלים הבאים:

• ‫--additional-node-network: מגדיר פרטים של ממשק הרשת הנוסף, הרשת ורשת המשנה. הפרמטר הזה משמש לציון רשתות הצמתים לחיבור לצמתים של מאגר הצמתים. מציינים את הפרמטר הזה כשרוצים להתחבר ל-VPC אחר. אם לא מציינים את הפרמטר הזה, נעשה שימוש ב-VPC שמוגדר כברירת מחדל שמשויך לאשכול. ברשתות מסוג Layer 3, מציינים את הדגל additional-pod-network שמגדיר את רשת ה-Pod, שנחשפת בתוך אשכול GKE כאובייקט Network. כשמשתמשים בדגל --additional-node-network, צריך לספק רשת ותת-רשת כפרמטרים חובה. חשוב להפריד בין ערכי הרשת והרשת המשנית באמצעות פסיק, ולא להשתמש ברווחים.

  אופציונלי, אפשר גם לציין את הפרמטר stack-type (תצוגה מקדימה) כדי להגדיר את סוג מחסנית כתובות ה-IP לממשק הרשת (הערכים התקינים הם ipv4,‏ ipv4-ipv6 או ipv6). הגדרת ממשק הרשת הסופית תלויה גם בערך שציינתם בשדה stack-type וגם בהגדרות של רשת המשנה הבסיסית:

  • ברשתות משנה מסוג IPv4_ONLY, הערך התקין בשדה stack-type הוא ipv4.
  • ברשתות משנה מסוג IPv4_IPv6, הערכים התקפים בשדה stack-type הם ipv4,‏ ipv4-ipv6 ו-ipv6.
  • ברשתות משנה מסוג IPv6_ONLY, הערך התקין בשדה stack-type הוא ipv6.

  אם לא מציינים ערך לשדה stack-type, סוג ה-stack מוגדר כברירת מחדל לכתובת IPv4 ב-NIC עבור רשתות משנה מסוג IPv4 בלבד או dual-stack, ולכתובת IPv6 עבור רשתות משנה מסוג IPv6 בלבד. אלא אם משנים במפורש את הערך של השדה stack-type עבור רשתות משנה עם כתובות IPv4 ו-IPv6, ערך ברירת המחדל הוא ipv4 כדי לשמור על תאימות לדורות קודמים. מידע נוסף זמין במאמר בנושא סוגי מחסניות.

• ‫--additional-pod-network: מציין את הפרטים של הטווח המשני שישמש את רשת הפודים. הפרמטר הזה לא נדרש אם משתמשים ברשת מסוג Device. הארגומנט הזה מציין את ערכי המפתח הבאים: subnetwork, pod-ipv4-range ו-max-pods-per-node. כשמשתמשים ב---additional-pod-network, צריך לציין את הערכים pod-ipv4-range ו-max-pods-per-node, מופרדים בפסיקים וללא רווחים.

  • ‫subnetwork: מקשר בין רשת הצמתים לבין רשת ה-Pod. הגדרת רשת משנה היא אופציונלית. אם לא מציינים את הרשת הנוספת, היא משויכת לרשת המשנה שמוגדרת כברירת מחדל ומסופקת במהלך יצירת האשכול.
  • ‫--max-pods-per-node: צריך לציין את max-pods-per-node, והוא חייב להיות חזקה של 2. הערך המינימלי הוא 4. הערך של max-pods-per-node לא יכול להיות גדול מהערך של max-pods-per-node במאגר הצמתים.

המסוף

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

   מעבר אל Google Kubernetes Engine

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

3. בקטע Kubernetes clusters (אשכולות Kubernetes), לוחצים על האשכול שיצרתם.

4. לוחצים על הכרטיסייה Nodes (צמתים).

5. לוחצים על Create user-managed node pool (יצירת מאגר צמתים בניהול המשתמש).

6. בקטע פרטי מאגר הצמתים, מבצעים את הפעולות הבאות:

   1. מזינים שם למאגר הצמתים.
   2. מזינים את מספר הצמתים שרוצים ליצור במאגר הצמתים.

7. בחלונית הניווט, בקטע Node Pools (מאגרי צמתים), לוחצים על Nodes (צמתים).

   1. בתפריט הנפתח Image type בוחרים את תמונת הצומת מערכת הפעלה שמותאמת לקונטיינרים עם containerd (cos_containerd).

8. כשיוצרים מכונה וירטואלית, בוחרים סוג מכונה מתוך משפחת מכונות שקובעת את המשאבים שזמינים למכונה הוירטואלית. לדוגמה, סוג מכונה כמו e2-standard-4 מכיל 4 יחידות vCPU, ולכן יכול לתמוך בסך הכול בעד 4 רשתות VPC. יש כמה משפחות של מכונות שאפשר לבחור מביניהן, וכל משפחת מכונות מחולקת לסדרות מכונות ולסוגי מכונות שהוגדרו מראש או שהוגדרו בהתאמה אישית בכל סדרה. החיוב על כל סוג מכונה מתבצע באופן שונה. מידע נוסף זמין בגיליון המחירים של סוגי המכונות.

9. בחלונית הניווט, בוחרים באפשרות Networking.

10. בקטע Node Networking (רשת הצמתים), מציינים את המספר המקסימלי של פודים לכל צומת. בקטע Node Networks (רשתות צמתים) מוצגת רשת ה-VPC שנעשה בה שימוש ליצירת האשכול. צריך להגדיר רשתות צמתים נוספות שמתאימות לרשתות VPC ולסוגי מכשירים שהוגדרו בעבר.

11. יצירת שיוך של מאגר צמתים:

    1. במכשיר מסוג Layer 3:
       1. בקטע Node Networks (רשתות צמתים), לוחצים על ADD A NODE NETWORK (הוספת רשת צמתים).
       2. בתפריט הנפתח של הרשת, בוחרים באפשרות VPC that supports Layer 3 type device (רשת VPC שתומכת במכשיר מסוג Layer 3).
       3. בוחרים את תת-הרשת שנוצרה עבור Layer 3 VPC.
       4. בקטע Alias Pod IP address ranges, לוחצים על Add Pod IP address range.
       5. בוחרים את רשת המשנה המשנית ומציינים את המספר המקסימלי של יחידות Pod לכל צומת.
       6. לוחצים על סיום.
    2. למכשירים מסוג Netdevice ו-DPDK:
       1. בקטע Node Networks (רשתות צמתים), לוחצים על ADD A NODE NETWORK (הוספת רשת צמתים).
       2. מהרשימה הנפתחת של הרשת, בוחרים את ה-VPC שתומך במכשירים מסוג Netdevice או DPDK.
       3. בוחרים את רשת המשנה שנוצרה עבור Netdevice או DPDK VPC.
       4. לוחצים על סיום.

12. לוחצים על יצירה.

הערות:

• כשמפעילים כתובת IPv6 בכרטיסי NIC נוספים על ידי הגדרת stack-type, צריך לוודא שמדיניות חומת האש של ה-VPC מוגדרת בצורה נכונה לכתובות IPv6. בניגוד לכתובות IPv4, אם משתמשים בכתובות Global Unicast (GUA), הצמתים עלולים להיחשף לאינטרנט הציבורי אם לא מגבילים אותם בצורה נכונה.
• אם מציינים כמה רשתות פודים נוספות באותה רשת צמתים, הן צריכות להיות באותה רשת משנה.
• אי אפשר להפנות לאותו טווח משני של רשת משנה כמה פעמים.

דוגמה בדוגמה הבאה נוצר מאגר צמתים בשם pool-multi-net שמצורפות אליו שתי רשתות נוספות לצמתים, dataplane (רשת מסוג Layer 3) ו-highperformance (רשת מסוג netdevice). בדוגמה הזו מניחים שכבר יצרתם אשכול GKE בשם cluster-1:

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --location us-central1-c \
  --additional-node-network network=dataplane,subnetwork=subnet-dp \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

כדי לציין עוד ממשקי node-network ו-Pod-network, מגדירים את הפרמטרים --additional-node-network ו---additional-pod-network כמה פעמים, כמו בדוגמה הבאה:

--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4

כדי לציין רשתות Pod נוספות ישירות בממשק ה-VPC הראשי של מאגר הצמתים, כמו בדוגמה הבאה:

--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8

כדי להוסיף ממשק רשת משני עם IPv6 בלבד, מוסיפים את הפרמטר stack-type כמו בדוגמה הבאה:

--additional-node-network network=highperformance,subnetwork=ipv6-only-subnet,stack-type=ipv6

כדי להוסיף ממשק רשת משני עם תמיכה כפולה בכתובות IPv4 ו-IPv6, מוסיפים את הפרמטר stack-type כמו בדוגמה הבאה:

--additional-node-network network=service-net,subnetwork=dual-stack-subnet,stack-type=ipv4-ipv6

יצירת רשת Pod

הגדרת רשתות ה-Pod שה-Pods יקבלו אליהן גישה על ידי הגדרת אובייקטים של Kubernetes וקישור שלהם למשאבי Compute Engine המתאימים, כמו רשתות VPC, רשתות משנה וטווחים משניים.

כדי ליצור רשת של Pod, צריך להגדיר את אובייקטי ה-CRD של הרשת באשכול.

הגדרת רשת Layer 3 VPC

YAML

ברשת ה-VPC‏ Layer 3, יוצרים את האובייקטים Network ו-GKENetworkParamSet:

1. שומרים את קובץ המניפסט לדוגמה הבא בשם blue-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: blue-network
   spec:
     type: "L3"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "l3-vpc"
   

   המניפסט מגדיר משאב Network בשם blue-network מהסוג Layer 3. האובייקט Network מפנה לאובייקט GKENetworkParamSet שנקרא l3-vpc, שמשייך רשת למשאבי Compute Engine.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f blue-network.yaml
   

3. שומרים את קובץ המניפסט הבא בשם l3-vpc.yaml :

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: "l3-vpc"
   spec:
     vpc: "l3-vpc"
     vpcSubnet: "subnet-dp"
     podIPv4Ranges:
       rangeNames:
       - "sec-range-blue"
   

   במניפסט הזה מוגדר אובייקט GKENetworkParamSet בשם l3-vpc, על ידי הגדרת שם ה-VPC כ-l3-vpc, שם תת-הרשת כ-subnet-dp וטווח כתובות ה-IPv4 המשני של הפודים כ-sec-range-blue.

4. מחילים את המניפסט על האשכול:

   kubectl apply -f l3-vpc.yaml
   

המסוף

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

   מעבר אל Google Kubernetes Engine

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

3. בחלק העליון של הדף, לוחצים על יצירה כדי ליצור את רשת הפודים.

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

5. לוחצים על הבא: מיקום רשת POD.

6. בקטע Pod network location, בתפריט הנפתח Cluster, בוחרים את אשכול GKE שבו מופעלת רשת מרובה ו-GKE Dataplane V2.

7. לוחצים על הבא: הפניה לרשת VPC.

8. בקטע VPC network reference, בתפריט הנפתח VPC network reference, בוחרים את רשת ה-VPC שמשמשת ל-Pods עם כמה כרטיסי NIC‏ Layer 3.

9. לוחצים על הבא: סוג רשת ה-POD.

10. בקטע Pod network type (סוג רשת ה-Pod), בוחרים באפשרות L3 ומזינים את Pod network name (שם רשת ה-Pod).

11. לוחצים על הבא: טווח משני של רשת POD.

12. בקטע Pod network secondary range, מזינים את Secondary range.

13. לוחצים על הבא: נתיבי רשת של POD.

14. בקטע Pod network routes (נתיבי רשת של ה-Pod), כדי להגדיר Custom routes (נתיבים בהתאמה אישית), לוחצים על ADD ROUTE (הוספת נתיב).

15. לוחצים על יצירת רשת של פודים.

הגדרת רשת DPDK

YAML

עבור DPDK VPC, יוצרים אובייקטים של Network ו-GKENetworkParamSet.

1. שומרים את קובץ המניפסט לדוגמה הבא בשם dpdk-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: dpdk-network
   spec:
     type: "Device"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "dpdk"
   

   המניפסט הזה מגדיר משאב Network בשם dpdk-network עם סוג של Device. המשאב Network מפנה לאובייקט GKENetworkParamSet שנקרא dpdk לצורך ההגדרה שלו.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f dpdk-network.yaml
   

3. עבור האובייקט GKENetworkParamSet, שומרים את המניפסט הבא בתור dpdk.yaml:

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: "dpdk"
   spec:
     vpc: "dpdk"
     vpcSubnet: "subnet-dpdk"
     deviceMode: "DPDK-VFIO"
   

   במניפסט הזה מוגדר אובייקט GKENetworkParamSet בשם dpdk, השם של ה-VPC מוגדר כ-dpdk, השם של תת-הרשת מוגדר כ-subnet-dpdk והשם של deviceMode מוגדר כ-DPDK-VFIO.

4. מחילים את המניפסט על האשכול:

   kubectl apply -f dpdk.yaml
   

המסוף

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

   מעבר אל Google Kubernetes Engine

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

3. בחלק העליון של הדף, לוחצים על יצירה כדי ליצור את רשת הפודים.

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

5. לוחצים על הבא: מיקום רשת POD.

6. בקטע Pod network location, בתפריט הנפתח Cluster, בוחרים את אשכול GKE שבו מופעלת רשת מרובה ו-GKE Dataplane V2.

7. לוחצים על הבא: הפניה לרשת VPC.

8. בקטע VPC network reference, בתפריט הנפתח VPC network reference, בוחרים את רשת ה-VPC שמשמשת ל-Pods של dpdk multinic.

9. לוחצים על הבא: סוג רשת ה-POD.

10. בקטע Pod network type (סוג רשת ה-Pod), בוחרים באפשרות DPDK-VFIO (Device) (מכשיר) ומזינים את Pod network name (שם רשת ה-Pod).

11. לוחצים על הבא: טווח משני של רשת POD. הקטע 'טווח משני' ברשת של רצפי מודעות לא יהיה זמין

12. לוחצים על הבא: נתיבי רשת של POD. בקטע Pod network routes (נתיבי רשת של פוד), בוחרים באפשרות ADD ROUTE (הוספת נתיב) כדי להגדיר נתיבים מותאמים אישית.

13. לוחצים על יצירת רשת של פודים.

הערה: ברשת DPDK, כרטיס ה-NIC קשור לדרייבר VFIO שלא יוצג כמכשיר רשת רגיל של ליבת המערכת שמופיע ב-ip link.

הגדרת רשת של מכשיר רשת

ב-netdevice VPC, יוצרים אובייקטים של Network ו-GKENetworkParamSet.

YAML

1. שומרים את קובץ המניפסט לדוגמה הבא בשם netdevice-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
       name: netdevice-network
   spec:
       type: "Device"
       parametersRef:
         group: networking.gke.io
         kind: GKENetworkParamSet
         name: "netdevice"
   

   המניפסט הזה מגדיר משאב Network בשם netdevice-network עם סוג Device. הוא מפנה לאובייקט GKENetworkParamSet בשם netdevice.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f netdevice-network.yaml
   

3. שומרים את קובץ המניפסט הבא בשם netdevice.yaml :

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: netdevice
   spec:
     vpc: "netdevice"
     vpcSubnet: "subnet-netdevice"
     deviceMode: "NetDevice"
   

   קובץ המניפסט הזה מגדיר משאב GKENetworkParamSet בשם netdevice, מגדיר את שם ה-VPC כ-netdevice, את שם תת-הרשת כ-subnet-netdevice ומציין את מצב המכשיר כ-NetDevice.

4. מחילים את המניפסט על האשכול:

   kubectl apply -f netdevice.yaml
   

המסוף

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

   מעבר אל Google Kubernetes Engine

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

3. בחלק העליון של הדף, לוחצים על יצירה כדי ליצור את רשת הפודים.

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

5. לוחצים על הבא: מיקום רשת POD.

6. בקטע Pod network location, בתפריט הנפתח Cluster, בוחרים את אשכול GKE שבו מופעלת רשת מרובה ו-GKE Dataplane V2.

7. לוחצים על הבא: הפניה לרשת VPC.

8. בקטע VPC network reference, בתפריט הנפתח VPC network reference, בוחרים את רשת ה-VPC שמשמשת ל-Pods של netdevice multinic.

9. לוחצים על הבא: סוג רשת ה-POD.

10. בקטע Pod network type (סוג רשת ה-Pod), בוחרים באפשרות NetDevice (Device) (מכשיר רשת) ומזינים את Pod network name (שם רשת ה-Pod).

11. לוחצים על הבא: טווח משני של רשת POD. הקטע 'טווח משני' ברשת ה-Pod לא יהיה זמין

12. לוחצים על הבא: נתיבי רשת של POD. בקטע Pod network routes (נתיבי רשת של Pod), כדי להגדיר נתיבים מותאמים אישית, בוחרים באפשרות ADD ROUTE (הוספת נתיב).

13. לוחצים על יצירת רשת של פודים.

הגדרת נתיבי רשת

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

YAML

1. שומרים את קובץ המניפסט הבא בשם red-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: red-network
   spec:
     type: "L3"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "management"
     routes:
     -   to: "10.0.2.0/28"
   

   במניפסט הזה מוגדר משאב Network בשם red-network עם סוג של Layer 3 ומסלול מותאם אישית '10.0.2.0/28' דרך ממשק Network.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f red-network.yaml
   

המסוף

1. עוברים לדף Network Function Optimizer במסוף Google Cloud .

   מעבר לכלי לשיפור התפקוד של הרשת

2. לוחצים על יצירה.

3. בוחרים אשכול שבו מופעלת תכונת הרישות המרובה.

4. מגדירים את העדפות הרשת.

5. לוחצים על יצירת רשת Pod.

התייחסות לNetwork שהוכנו

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

חיבור של Pod לרשתות ספציפיות

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

1. שומרים את קובץ המניפסט לדוגמה הבא בשם sample-l3-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"}
         ]
   spec:
     containers:
     - name: sample-l3-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   קובץ המניפסט הזה יוצר Pod בשם sample-l3-pod עם שני ממשקי רשת, eth0 ו-eth1, שמשויכים לרשתות default ו-blue-network, בהתאמה.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f sample-l3-pod.yaml
   

חיבור של Pod למספר רשתות

1. שומרים את קובץ המניפסט לדוגמה הבא בשם sample-l3-netdevice-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-netdevice-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"},
           {"interfaceName":"eth2","network":"netdevice-network"}
         ]
   spec:
     containers:
     - name: sample-l3-netdevice-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   המניפסט הזה יוצר Pod בשם sample-l3-netdevice-pod עם שלושה ממשקי רשת, eth0, eth1 ו-eth2 שמשויכים לרשתות default, blue-network ו-netdevice, בהתאמה.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f sample-l3-netdevice-pod.yaml
   

אפשר להשתמש באותה הערה בכל ReplicaSet (Deployment או DaemonSet) בקטע ההערות של התבנית.

דוגמה להגדרה של Pod עם כמה ממשקים:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
    link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
      valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
    link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.1.2/32 scope global eth1
      valid_lft forever preferred_lft forever

אימות

• חשוב לוודא שיוצרים אשכולות עם --enable-multi-networking רק אם האפשרות --enable-dataplane-v2 מופעלת.
• מוודאים שכל מאגרי הצמתים באשכול מריצים תמונות של מערכת הפעלה שמותאמת לקונטיינרים בזמן יצירת האשכול ומאגר הצמתים.
• מוודאים שמאגרי הצמתים נוצרו עם --additional-node-network או עם --additional-pod-network רק אם מופעלת רשת מרובה באשכול.
• מוודאים שאותה רשת משנה לא מצוינת פעמיים כארגומנט --additional-node-network למאגר צמתים.
• מוודאים שאותו טווח משני לא מצוין כארגומנט --additional-pod-network למאגר צמתים.
• צריך לפעול בהתאם למגבלות הגודל שצוינו לאובייקטים ברשת, תוך התחשבות במספר המקסימלי של הצמתים, קבוצות ה-Pod וכתובות ה-IP שמותרים.
• מוודאים שיש רק אובייקט GKENetworkParamSet אחד שמפנה לתת-רשת ולטווח משני מסוימים.
• מוודאים שכל אובייקט רשת מפנה לאובייקט GKENetworkParamSet שונה.
• מוודאים שאובייקט הרשת, אם הוא נוצר עם רשת משנה ספציפית עם Device network, לא נמצא בשימוש באותו צומת עם רשת אחרת עם טווח משני. אפשר לאמת את זה רק בזמן הריצה.
• מוודאים שלטווחים המשניים השונים שהוקצו למאגרי הצמתים אין כתובות IP חופפות.

פתרון בעיות בפרמטרים של כמה רשתות ב-GKE

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

הערה: כשפותרים בעיות ברשתות מסוג Device, צריך לוודא שהתוספים high-perf-device-plugin ו-anetd מותקנים בצמתים. בנוסף, מוודאים שתווית הצומת google.cloud.com/run-high-perf-daemons: "true" מופיעה בצמתים. התווית הזו שולטת באופן ספציפי בhigh-perf-device-plugin.

החל מגרסה 1.32 של GKE ואילך, high-perf-config-daemonנדרש רק אם רשת DPDK-VFIO קיימת בצומת. כדי לבדוק את high-perf-config-daemon, מוודאים שתווית הצומת cloud.google.com/run-high-perf-config-daemons: "true" מופיעה. היעדר התוספים הנדרשים או תוויות הצמתים לסוג הרשת הספציפי עשוי להצביע על הגדרה לא מלאה או שגויה.

שגיאה מסוג stack לא תקין

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

Google Compute Engine: Invalid value for field 'resource.properties.networkInterfaces[1].stackType': 'UNSPECIFIED_STACK_TYPE'.

השגיאה הזו מתרחשת בדרך כלל כשמשתמשים ברשת משנה עם IPv6 בלבד בלי להגדיר במפורש את הערך של השדה stack-type בגרסאות או בתצורות קודמות של GKE. כדי לפתור את הבעיה, צריך לעדכן את הרכיבים של ה-CLI של gcloud, להשתמש בגרסה חדשה יותר של GKE ולכלול באופן מפורש את הפרמטר stack-type=ipv6 בפקודה.

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

kubectl describe pods samplepod

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

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   NotTriggerScaleUp  9s               cluster-autoscaler  pod didn't trigger scale-up:
  Warning  FailedScheduling   8s (x2 over 9s)  default-scheduler   0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod

אלה הסיבות הכלליות לכשל ביצירת Pod:

• התזמון של ה-Pod נכשל כי הדרישות של משאבי ריבוי רשתות לא מתקיימות
• הזיהוי של הרשתות שצוינו נכשל

פתרון בעיות ביצירת רשתות Kubernetes

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

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

kubectl describe node NODE_NAME

מחליפים את NODE_NAME בשם הצומת.

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

networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]

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

בודקים אם לצומת יש גישה לרשת

אם הרשת לא מופיעה בהערה network-status של הצומת:

1. מוודאים שהצומת הוא חלק ממאגר שהוגדר לריבוי רשתות.
2. בודקים את הממשקים של הצומת כדי לראות אם יש לו ממשק לרשת שמגדירים.
3. אם חסר צומת עם סטטוס רשת ויש לו רק ממשק רשת אחד, עדיין צריך ליצור מאגר צמתים עם ריבוי רשתות מופעל.
4. אם הצומת מכיל את הממשק של הרשת שאתם מגדירים, אבל הוא לא מופיע בהערה על סטטוס הרשת, כדאי לבדוק את המשאבים Network ו-GKENetworkParamSet (GNP).

בדיקת המשאבים Network ו-GKENetworkParamSet

הסטטוס של שני משאבי Network ו-GKENetworkParamSet (GNP) כולל שדה תנאים לדיווח על שגיאות בהגדרה. מומלץ לבדוק קודם את GNP, כי הוא לא מסתמך על משאב אחר כדי להיות תקף.

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

kubectl get gkenetworkparamsets GNP_NAME -o yaml

מחליפים את GNP_NAME בשם של משאב GKENetworkParamSet.

אם התנאי Ready שווה ל-true, ההגדרה תקינה והפלט יהיה דומה לזה:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-dp
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:38:04Z"
    message: ""
    reason: GNPReady
    status: "True"
    type: Ready
  networkName: dp-network
  podCIDRs:
    cidrBlocks:
    -   172.16.1.0/24

כשהתנאי Ready שווה ל-false, הפלט מציג את הסיבה ודומה לזה:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-nonexist
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:37:57Z"
    message: 'subnet: subnet-nonexist not found in VPC: dataplane'
    reason: SubnetNotFound
    status: "False"
    type: Ready
  networkName: ""

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

אחרי שה-GNP מוכן, בודקים את המשאב Network.

kubectl get networks NETWORK_NAME -o yaml

מחליפים את NETWORK_NAME בשם של משאב Network.

הפלט של תצורה תקינה אמור להיראות כך:

apiVersion: networking.gke.io/v1
kind: Network
...
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: dp-gnp
  type: L3
status:
  conditions:
  -   lastTransitionTime: "2023-06-07T19:31:42Z"
    message: ""
    reason: GNPParamsReady
    status: "True"
    type: ParamsReady
  -   lastTransitionTime: "2023-06-07T19:31:51Z"
    message: ""
    reason: NetworkReady
    status: "True"
    type: Ready

• ‫reason: NetworkReady מציין שהמשאב Network מוגדר בצורה נכונה. ‫reason: NetworkReady לא מרמז שהמשאב Network בהכרח זמין בצומת ספציפי או נמצא בשימוש פעיל.
• אם יש שגיאה או שההגדרה לא נכונה, השדה reason בתנאי מציין את הסיבה המדויקת לבעיה. במקרים כאלה, צריך לשנות את ההגדרה בהתאם.
• מערכת GKE מאכלסת את השדה ParamsReady אם השדה parametersRef מוגדר למשאב GKENetworkParamSet שקיים באשכול. אם ציינתם GKENetworkParamSet type parametersRef והתנאי לא מופיע, ודאו שהשם, הסוג והקבוצה תואמים למשאב GNP שקיים באשכול.

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

• איך יוצרים אשכולות מקוריים של VPC
• Codelabs
• סרטון הדגמה