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

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

סקירה כללית

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

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

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

הסברים על המונחים

בדף הזה מופיעים המונחים הבאים:

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

‫Subnet: ב- Google Cloud, תת-רשת היא הדרך ליצור Classless Inter-Domain Routing‏ (CIDR) עם מסכות רשת ב-VPC. לרשת משנה יש טווח יחיד של כתובות IP ראשיות שמוקצה לצמתים, ויכולים להיות לה כמה טווחים משניים שיכולים להיות שייכים ל-Pods ולשירותים.

‫node-network: הכוונה לשילוב ייעודי של רשת VPC ורשת משנה. ברשת הצמתים הזו, לצמתים ששייכים למאגר הצמתים מוקצות כתובות IP מטווח כתובות ה-IP הראשי.

טווח משני: טווח משני הוא CIDR ומסכת רשת ששייכים לתת-רשת. Google Cloud ‫GKE משתמש בזה כרשת פודים בשכבה 3. ‫A Pod יכול להתחבר למספר רשתות Pod.

‫Pod-network: אובייקט Network שמשמש כנקודת חיבור לקבוצות Pod. החיבור יכול להיות מסוג Layer 3 או מסוג Device. אפשר להגדיר רשתות מסוג Device ב-netdevice או במצב Data Plane Development Kit (DPDK).

רשתות Layer 3 תואמות לטווח משני ברשת משנה. רשת Device תואמת לרשת משנה ב-VPC. מודל הנתונים של רשת ה-Pod ב-GKE multi-network הוא כדלקמן:

  • ‫Layer 3 Network: VPC -> Subnet Name -> Secondary Range Name

  • עבור רשת Device: VPC -> Subnet Name

Default Pod-network: Google Cloud יוצר רשת Pod כברירת מחדל במהלך יצירת האשכול. רשת ה-Pod שמוגדרת כברירת מחדל משתמשת ב-VPC הראשי כרשת הצמתים. רשת ה-Pod שמוגדרת כברירת מחדל זמינה בכל צמתי האשכולות ובכל ה-Pods, כברירת מחדל.

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

בתרשים הבא מוצגת ארכיטקטורה אופיינית של אשכול GKE עם רשתות Layer 3:

ארכיטקטורת אשכול GKE עם רשתות בשכבה 3

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

רשתות של פודים וצמתים

תרחישים לדוגמה

התמיכה בריבוי רשתות עבור Pods מתייחסת לתרחישי השימוש הבאים:

  • פריסת פונקציות רשת מבוססות-קונטיינר: אם אתם מריצים את פונקציות הרשת בקונטיינרים, שיש להם נתונים נפרדים ומישורי ניהול. ריבוי רשתות (Multi-network) ל-Pods מבודד רשתות למישורי משתמשים שונים, לביצועים גבוהים או לחביון נמוך מממשקים ספציפיים, או לריבוי דיירים ברמת הרשת. ההגדרה הזו נדרשת לצורך תאימות, איכות שירות ואבטחה.
  • חיבור VPC באותו ארגון ובאותו פרויקט: אתם רוצים ליצור אשכולות GKE ב-VPC וצריכים להתחבר לשירותים ב-VPC אחר. אתם יכולים להשתמש באפשרות multi-NIC nodes (צמתים עם כמה כרטיסי רשת) לקישוריות ישירה. יכול להיות שהסיבה לכך היא מודל של רשת מרכזית עם רשתות משנה, שבו שירות מרכזי (רישום ביומן, אימות) פועל ב-VPC מרכזי, ורשתות המשנה דורשות קישוריות פרטית כדי לגשת אליו. אתם יכולים להשתמש בתמיכה בריבוי רשתות עבור Pods כדי לחבר את ה-Pods שפועלים באשכול GKE ישירות ל-VPC של הרכזת.
  • הרצת אפליקציות DPDK באמצעות VFIO: אם רוצים להריץ אפליקציות DPDK שנדרשת להן גישה ל-NIC בצומת באמצעות מנהל ההתקן VFIO. כדי להשיג את קצב המנות האופטימלי, צריך לעקוף לחלוטין את הליבה, את Kubernetes ואת GKE Dataplane V2.
  • הפעלת גישה ישירה ל-vNIC תוך עקיפת Kubernetes ו-GKE Dataplane V2: מריצים את פונקציות הרשת בקונטיינרים שדורשות גישה ישירה לכרטיס ממשק הרשת (NIC) בצומת. לדוגמה, אפליקציות של מחשוב עתיר ביצועים (HPC) שרוצות לעקוף את Kubernetes ואת GKE Dataplane V2 כדי להשיג את זמן האחזור הנמוך ביותר. חלק מהאפליקציות גם רוצות גישה למידע על טופולוגיית PCIe של כרטיס ה-NIC כדי לבצע שיתוף מיקום עם מכשירים אחרים כמו GPU.
  • חשיפת עומסי עבודה ברשתות משניות באמצעות מאזני עומסים: אתם יכולים להשתמש במאזני עומסי רשת חיצוניים ופנימיים להעברת סיגנל ללא שינוי כדי לחשוף עומסי עבודה (כמו פונקציות רשת מבוססות-קונטיינרים) ישירות ברשתות VPC משניות. כך תוכלו לספק גישה לאפליקציות שלכם בממשקי רשת ספציפיים בלי להשתמש ברשת ברירת המחדל של האשכול.

יתרונות

התמיכה בריבוי רשתות ב-Pods מספקת את היתרונות הבאים:

  • בידוד תנועה: תמיכה בריבוי רשתות ל-Pods מאפשרת לבודד תנועה באשכול GKE. אפשר ליצור Pod עם כמה ממשקי רשת כדי להפריד את התנועה לפי יכולת, כמו ניהול ומישור נתונים, בתוך Pod שמריץ פונקציות רשת מכולות ספציפיות (CNF).
  • Dual homing: dual homing מאפשר ל-Pod להשתמש בכמה ממשקים ולנתב תעבורה לכמה רשתות VPC, וכך ליצור חיבורים גם לרשת VPC ראשית וגם לרשת VPC משנית. אם יש בעיות ב-VPC אחד, האפליקציה יכולה לחזור ל-VPC המשני.
  • פילוח רשת: תרמילים יכולים להתחבר לרשתות פנימיות או חיצוניות בהתאם לצורכי עומס העבודה. בהתאם לדרישות הספציפיות של עומסי העבודה, אפשר לבחור אילו פודים או קבוצות של פודים יתחברו לכל רשת. לדוגמה, אפשר להשתמש ברשת פנימית לתקשורת מזרח-מערב וברשת חיצונית לגישה לאינטרנט. כך תוכלו להתאים את קישוריות הרשת של עומסי העבודה בהתאם לצרכים הספציפיים שלהם.
  • ביצועים אופטימליים עם DPDK: תמיכה בריבוי רשתות עבור Pods ב-GKE מאפשרת לאפליקציות DPDK לפעול ב-Pods של GKE, וכך מספקת ביצועים אופטימליים של עיבוד מנות.
  • כרטיס רשת של המארח זמין ישירות ב-Pod: התמיכה בכרטיס רשת במצב netdevice עם העברות מרובות ברשת מעבירה את כרטיס הרשת של המכונה הווירטואלית ישירות ל-Pod, תוך עקיפת Kubernetes ו-GKE Dataplane V2. כך אפשר להשיג את זמן האחזור הנמוך ביותר לשיתוף פעולה בין מכשירים.
  • ביצועים: כדי לשפר את הביצועים של האפליקציות, אפשר לקשר את האפליקציות לרשת שהכי מתאימה לצרכים שלהן.
  • איזון עומסים ברשתות מרובות: תמיכה ברשתות מרובות עבור Pods מאפשרת להקצות Google Cloud מאזני עומסים חיצוניים ופנימיים של רשתות להעברת סיגנל ללא שינוי לשירותים ברשתות משניות. כך תוכלו לחשוף את האפליקציות שלכם ללקוחות ב-VPC ספציפיים, תוך שמירה על בידוד רשת קפדני בין עומסי העבודה.

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