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. התוכנות האלה חיוניות לקישוריות לרשת, ולכן אי אפשר להתקין תוכנות eBPF בהתאמה אישית בצמתים שמשתמשים ב-GKE Dataplane V2. תוכנות eBPF בהתאמה אישית יכולות להפריע לתוכנות GKE Dataplane V2 ולשבש את הרשת של האשכול.

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

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

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

מדרגיות

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

ב-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
מספר שירותי LoadBalancer לכל אשכול 750 500 1,000

ב-GKE Dataplane V2 יש מפת שירותים שמאפשרת לעקוב אחרי השירותים שמפנים לפודים מסוימים בתור הקצה העורפי שלהם. מספר הקצוות העורפיים של Pod לכל שירות, שמסוכמים בכל השירותים, חייב להתאים למפת השירות, שיכולה להכיל עד 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 כדי לבחור את ה-backends. האלגוריתם random יכול לגרום לניתוב מחדש ולאיפוס של חיבורים תקינים כשקבוצת ה-Pods בקצה העורפי משתנה (לדוגמה, במהלך אירועי התאמה לעומס). ‫Maglev מפחית את ההשפעה של הבעיה הזו על ידי המשך ניתוב התנועה לקצה העורפי שהוקצה לחיבור כל עוד הוא תקין, גם כשמוסיפים או מסירים Pods אחרים.

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

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

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

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

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

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

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

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

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

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

הפעלת האלגוריתם Maglev

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

דוגמה:

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, הטמעת שירותי Kubernetes מתבצעת באמצעות cilium במקום kube-proxy. ‫kube-proxy מתוחזק ומפותח על ידי קהילת Kubernetes, ולכן סביר יותר שתכונות חדשות של שירותים יוטמעו ב-kube-proxy לפני שהן יוטמעו ב-cilium ל-GKE Dataplane V2.
  • במקרים מסוימים, פודים של סוכני GKE Dataplane V2 (anetd) יכולים לצרוך כמות משמעותית של משאבי מעבד (CPU), עד שניים או שלושה מעבדי vCPU לכל מכונה. זה קורה כשיש נפח גבוה של חיבורי TCP שנפתחים ונסגרים במהירות בצומת. כדי לצמצם את הבעיה, מומלץ להטמיע keep-alive לקריאות HTTP ומאגר חיבורים לעומסי העבודה הרלוונטיים.

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

  • חבילות ICMP מקוטעות לא נתמכות ומוסרות על ידי GKE Dataplane V2.

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

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

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