בדף הזה מוסבר מהו 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 פורס את בקר 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 כדי לנהל את תעבורת הרשת, כולל ניתוב, איזון עומסים ואכיפת מדיניות הרשת. התוכניות האלה חיוניות לקישוריות לרשת, ולכן 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 כדי לאכוף מדיניות רשת.
תפעול
כשיוצרים אשכול באמצעות GKE Dataplane V2, רישום ביומן של מדיניות הרשת מובנה. כדי לראות מתי הפודים מאשרים או דוחים חיבורים, צריך להגדיר את ה-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 |
| מספר שירותי ה-Cluster 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, שמשבית את האכיפה של מדיניות הרשת. מידע מפורט זמין במאמר בנושא מגבלות ודרישות לגבי גודל האשכול.
- אשכולות אזוריים: עד 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. מידע נוסף זמין במאמר בנושא מדרגיות.
פריסת עומסי עבודה באמצעות 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) תלוי בזיכרון הכולל שזמין בצומת. צמתים עם זיכרון כולל גבוה יותר מדווחים על שימוש גבוה יותר בזיכרון עבור ה-Podsanetd. ה-Podsanetdלא משתמשים בפועל ביותר זיכרון. השימוש המדווח גדל כי המדד הזה כולל את הקצאת הזיכרון של מיפוי 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.
אכיפת מדיניות רשת ללא GKE Dataplane V2
הוראות להפעלת אכיפת מדיניות רשת באשכולות שלא משתמשים ב-GKE Dataplane V2 מופיעות במאמר בנושא שימוש באכיפת מדיניות רשת.
המאמרים הבאים
- שימוש ב-GKE Dataplane V2
- מידע על יכולות הניטור של GKE Dataplane V2
- איך משתמשים ברישום ביומן של מדיניות הרשת
- אלה סביבות האשכולות של GKE Enterprise שבהן GKE Dataplane V2 זמין.