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 ולשבש את הרשת של האשכול.

אם מזוהה תוכנית eBPF בהתאמה אישית באשכול, GKE מספק המלצה שמציינת את נוכחות התוכנית.

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

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

מדרגיות

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

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

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

אבטחה

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

תפעול

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

עקביות

‫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
מספר הפודים בכל אשכול 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 צמתים. במקום זאת, השתמשו ב-CiliumClusterwideNetworkPolicy CRD כדי לתמוך בהרחבה של עד 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 ואילך, אפשר להגדיר שירותים שישתמשו באלגוריתם הגיבוב העקבי (consistent hashing) של 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.5MB
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, עד שניים או שלושה מעבדים וירטואליים לכל מכונה. השגיאה הזו מתרחשת כשנפתחים ונסגרים במהירות נפחים גדולים של חיבורי 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.

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