GKE Dataplane V2

בדף הזה מוסבר מהו GKE Dataplane V2 ואיך הוא פועל.

בדף הזה מניחים שיש לכם ידע בנושא רישות בתוך אשכולות GKE.

סקירה כללית של GKE Dataplane V2

‫GKE Dataplane V2 הוא מישור נתונים שעבר אופטימיזציה לרשתות Kubernetes. ‫GKE Dataplane V2 מספק את היתרונות הבאים:

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

‫GKE Dataplane V2 מופעל כברירת מחדל בכל אשכולות Autopilot החדשים.

איך פועל GKE Dataplane V2

‫GKE Dataplane V2 מיושם באמצעות eBPF. כשחבילות מגיעות לצומת GKE, תוכניות eBPF שמותקנות בקרנל מחליטות איך לנתב ולעבד את החבילות. בניגוד לעיבוד מנות עם iptables, תוכניות eBPF יכולות להשתמש במטא-נתונים ספציפיים ל-Kubernetes במנה. כך, GKE Dataplane V2 יכול לעבד חבילות רשת בקרנל בצורה יעילה יותר ולדווח על פעולות עם הערות בחזרה למרחב המשתמש לצורך רישום ביומן.

בתרשים הבא מוצג הנתיב של מנה דרך צומת באמצעות GKE Dataplane V2:

הנתיב של מנה דרך צומת באמצעות GKE Dataplane V2.

‫GKE פורס את בקר GKE Dataplane V2 כ-DaemonSet בשם anetd לכל צומת באשכול. ‫anetd מפרש אובייקטים של Kubernetes ומתכנת טופולוגיות של רשת ב-eBPF. ה-Pods של anetd פועלים במרחב השמות kube-system.

‫GKE Dataplane V2 ו-NetworkPolicy

‫GKE Dataplane V2 מיושם באמצעות Cilium. מישור הנתונים מדור קודם של GKE מיושם באמצעות Calico.

שתי הטכנולוגיות האלה מנהלות את NetworkPolicy של Kubernetes. ‫Cilium משתמש ב-eBPF וממשק רשת הקונטיינרים (CNI) של Calico משתמש ב-iptables בקרנל של Linux.

תוכניות eBPF בהתאמה אישית

‫GKE Dataplane V2 משתמש בתוכניות eBPF כדי לנהל את תעבורת הרשת, כולל ניתוב, איזון עומסים ואכיפת מדיניות רשת ב-Kubernetes. התוכניות האלה חיוניות לקישוריות לרשת, ולכן GKE לא תומך בהתקנה של תוכניות eBPF מותאמות אישית בצמתים שמשתמשים ב-GKE Dataplane V2. תוכניות eBPF בהתאמה אישית עלולות להפריע לתוכניות GKE Dataplane V2 ולשבש את הרשת של האשכול.

היתרונות של GKE Dataplane V2

‫GKE Dataplane V2 מציע את היתרונות הבאים:

מדרגיות

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

בגרסאות GKE שבהן לא נעשה שימוש ב-kube-proxy ב-GKE Dataplane V2 ולא מסתמכים על iptables לניתוב שירותים, GKE מסיר חלק מהצווארי בקבוק שקשורים ל-iptables, כמו מספר השירותים.

‫GKE Dataplane V2 מסתמך על מיפוי eBPF שמוגבל ל-260,000 נקודות קצה בכל השירותים.

אבטחה

התכונה Kubernetes NetworkPolicy מופעלת תמיד באשכולות עם GKE Dataplane V2. אתם לא צריכים להתקין ולנהל תוספי תוכנה של צד שלישי כמו Calico כדי לאכוף מדיניות רשת ב-Kubernetes.

תפעול

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

עקביות

‫GKE Dataplane V2 מספק חוויית רשת עקבית.

מידע נוסף מופיע בקטע זמינות של GKE Dataplane V2.

מפרטים טכניים של GKE Dataplane V2

‫GKE Dataplane V2 תומך באשכולות עם המפרטים הבאים:

מפרט GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
מספר הצמתים בכל אשכול 15,000 500 500
מספר ה-Pods בכל אשכול 400,000 15,000 27,500
מספר ה-Pods מאחורי שירות אחד 10,000 1,000 1,000
מספר שירותי ה-IP של האשכול 10,000 1,000 1,000
מספר שירותי איזון עומסים לכל אשכול 750 500 1,000

‫GKE Dataplane V2 שומר על מפת שירות כדי לעקוב אחרי השירותים שמפנים אל הפודים כאל קצה העורפי שלהם. סכום מספר ה-Pod backends לכל שירות בכל השירותים צריך להיכנס למפת השירות, שיכולה להכיל עד 260,000 רשומות. אם חורגים מהמגבלה הזו, יכול להיות שהאשכול לא יפעל כצפוי.

מגבלות צמתים

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

  • אשכולות אזוריים: עד 5,000,‏ 15,000 או 65,000 צמתים לכל אשכול. לא כל הגדלות הצמתים הן אוטומטיות. בהתאם למספר צמתי היעד, יש דרישות תשתית ספציפיות, ויכול להיות שתצטרכו לפנות ל-Cloud Customer Care. כדי להרחיב את הפתרון ל-65,000 צמתים, צריך להשתמש במצב של Dataplane V2 שעבר אופטימיזציה להרחבה, שבו האכיפה של מדיניות רשת ב-Kubernetes מושבתת. מידע מפורט זמין במאמר בנושא מגבלות ודרישות לגבי גודל האשכול.
  • אשכולות אזוריים: עד 1,000 צמתים.

כדי להגדיל את מספר הצמתים מעבר ל-5,000 באשכולות אזוריים, הסביבה שלכם צריכה לעמוד בתנאים הבאים:

  • צריך להפעיל את Private Service Connect באשכול. כדי לבדוק אם האשכול שלכם משתמש ב-Private Service Connect, אפשר לעיין במאמר בנושא אשכולות עם Private Service Connect.
  • בקטעי קוד שמשתמשים ב-CiliumNetworkPolicy CRD, יש הגבלה של עד 1,000 צמתים באזורים. במקום זאת, צריך להשתמש ב-CRD‏ CiliumClusterwideNetworkPolicy כדי לתמוך בהרחבה של עד 5,000 צמתים.

שירותי LoadBalancer ב-Google Distributed Cloud

מספר שירותי LoadBalancer שנתמכים ב-Google Distributed Cloud תלוי במצב מאזן העומסים שבו משתמשים. ‫Google Distributed Cloud תומך ב-500 שירותי LoadBalancer כשמשתמשים במצב של איזון עומסים בחבילה (Seesaw) וב-250 כשמשתמשים במצב של איזון עומסים משולב עם F5. מידע נוסף זמין במאמר בנושא מדרגיות.

תמיכה ב-Maglev

באשכולות GKE שמופעלת בהם גרסה 1.36.0-gke.2882000 ואילך, אפשר להגדיר שירותים לשימוש באלגוריתם הגיבוב העקבי של Maglev לבחירת קצה עורפי.

כברירת מחדל, שירותי Kubernetes משתמשים באלגוריתם random כדי לבחור בקצה העורפי. האלגוריתם random עלול לגרום לניתוב מחדש ולאיפוס של חיבורים תקינים כשקבוצת ה-Pods של ה-Backend משתנה (לדוגמה, במהלך אירועי שינוי גודל). ‫Maglev מפחית את הסיכון הזה על ידי המשך ניתוב התנועה אל העורף האחורי שהוקצה לחיבור כל עוד הוא תקין, גם כשמוסיפים או מסירים תרמילים אחרים.

יתרונות השימוש באלגוריתם Maglev

היתרונות של שימוש באלגוריתם Maglev:

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

מגבלות השימוש באלגוריתם Maglev

השימוש באלגוריתם Maglev עלול להיות עתיר משאבים:

  • הוא עלול לגרום לשימוש מוגבר בזיכרון ב-anetd בכל אשכול. מידע נוסף מופיע בקטע הבא, 'שיקולים לגבי השימוש בזיכרון ב-Maglev'.
  • יכול להיות שהיא קשורה לשימוש גבוה יותר ב-anetd CPU‏ (עד פי שלושה) במהלך שינויים בשרת העורפי.

שיקולים לגבי השימוש בזיכרון ב-Maglev

כדי לעקוב אחרי חיבורים ועורפיים, אלגוריתם Maglev משתמש בטבלת גיבוב: הוא מבצע גיבוב של 5-tuple של חבילת הנתונים (כתובת ה-IP של המקור, כתובת ה-IP של היעד, יציאת המקור, יציאת היעד והפרוטוקול).

גודל טבלת החיפוש מוגדר ל-16,381 רשומות. כל רשומה היא בגודל 4 בייט, ולכן שירות שהוגדר לשימוש באלגוריתם Maglev צריך 65.5KB‏ (16,381 × 4 בייט) של זיכרון שניתן להקצאה בכל צומת.

מספר השירותים שבהם מופעל Maglev שימוש נוסף בזיכרון
100 ‫6.5 MB
1,000 ‫65 MB
10,000 ‫650 MB

החלת האלגוריתם של Maglev

כדי להחיל את אלגוריתם Maglev על Service מסוג NodePort או LoadBalancer, צריך להוסיף את ההערה gke.networking.io/lb-algorithm: "maglev" למטא-נתונים של ה-Service במהלך יצירת ה-Service.

דוגמה:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

ההערה gke.networking.io/lb-algorithm נכנסת לתוקף במהלך יצירת השירות. כדי לשנות את האלגוריתם של שירות קיים, צריך למחוק את השירות וליצור אותו מחדש. שינוי ערך ההערה בלי ליצור אותה מחדש גורם להתנהגות לא עקבית. ‫anetd בניסיון להשתמש באלגוריתם שהוגדר לאחרונה בצמתים חדשים, בזמן ש-Pods קיימים ממשיכים להשתמש באלגוריתם הקודם.

פריסת עומסי עבודה באמצעות SCTP

אתם יכולים לפרוס עומסי עבודה שמשתמשים בפרוטוקול Stream Control Transmission Protocol‏ (SCTP) באשכולות שמופעל בהם GKE Dataplane V2. ‫SCTP הוא פרוטוקול של שכבת התעבורה שמספק שידור אמין ומכוון-הודעות. מידע נוסף זמין במאמר פריסת עומסי עבודה באמצעות SCTP.

מגבלות

ל-GKE Dataplane V2 יש את המגבלות הבאות:

  • אפשר להפעיל את GKE Dataplane V2 רק כשיוצרים אשכול חדש. אי אפשר לשדרג אשכולות קיימים כדי להשתמש ב-GKE Dataplane V2.
  • אין תמיכה במאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי שנוצרו באופן ידני ומשויכים לשירות מסוג NodePort.
  • ‫GKE Dataplane V2 משתמש ב-cilium במקום ב-kube-proxy כדי להטמיע את שירותי Kubernetes. ‫kube-proxy מתוחזק ומפותח על ידי קהילת Kubernetes, ולכן סביר יותר שתכונות חדשות של Services יוטמעו ב-kube-proxy לפני שהן יוטמעו ב-cilium עבור GKE Dataplane V2.
  • במקרים מסוימים, פודים של סוכני GKE Dataplane V2 ‏ (anetd) יכולים לצרוך כמות משמעותית של משאבי CPU, עד שניים או שלושה מעבדי CPU וירטואליים לכל מכונה. הבעיה הזו מתרחשת כשנפתחים ונסגרים במהירות נפחים גדולים של חיבורי TCP בצומת. כדי לצמצם את הבעיה הזו, מומלץ להטמיע keep-alives לקריאות HTTP ואיגום חיבורים לעומסי העבודה הרלוונטיים.

  • השימוש בזיכרון של פודים של סוכני GKE Dataplane V2 (anetd) תלוי בזיכרון הכולל שזמין בצומת. בצמתים עם זיכרון כולל גדול יותר, השימוש בזיכרון של ה-Pods‏ [anetd] גבוה יותר. ה-Pods‏ anetd לא משתמשים בפועל ביותר זיכרון. השימוש המדווח גדל כי המדד הזה כולל את הקצאת הזיכרון של מיפוי eBPF.

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

  • ‫GKE Dataplane V2 משתמש ב-eBPF כדי לנהל את תעבורת הרשת של האשכול. אם תתקינו אפליקציה של צד שלישי שגם היא משתמשת ב-eBPF, יכול להיות שהיא תפריע ל-GKE Dataplane V2. לדוגמה, שימוש ב-Retina עם GKE Dataplane V2 יכול למנוע מה-Pods שלכם להתחבר לשירותים. הבעיה הזו מתרחשת כי תוכניות eBPF של Retina יכולות לשבש את האופן שבו GKE Dataplane V2 מנתב תנועה. אם מופיעות הודעות שגיאה שמציינות שחלק מהתנועה נחסמת כי היא מנסה להגיע ישירות לכתובת ה-IP של השירות, יכול להיות שזו הבעיה שאתם נתקלים בה. הסיבה לכך היא שאין אפשרות ל-Pods לגשת ישירות לכתובת ה-IP של השירות, והתנועה חייבת לעבור דרך מנגנוני הניתוב של Dataplane V2. מידע נוסף מופיע במאמר בעיות של חוסר תאימות ל-Retina.

  • אין תמיכה במנות ICMP מקוטעות, והן מושמטות על ידי GKE Dataplane V2.

אכיפת מדיניות רשת ב-Kubernetes ללא GKE Dataplane V2

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

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