היסודות של רשתות GKE

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

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

למה הרשת ב-Kubernetes שונה

כשמשתמשים ב-Kubernetes כדי לתזמן את האפליקציות, צריך לחשוב אחרת על עיצוב הרשת. עם Kubernetes, אתם מתמקדים באופן התקשורת בין Pods,‏ Services ולקוחות חיצוניים, במקום לנהל רשתות של מארחים בודדים או מכונות וירטואליות (VM). ההפשטה הזו מפשטת את פריסת האפליקציות ואת ההתאמה שלהן, כי היא מבטלת מורכבויות כמו מיפוי יציאות ידני.

דרישות מוקדמות

לפני שמתחילים ללמוד על רשתות ב-GKE, חשוב להבין את המושגים הבאים:

רישות ליבה ו Google Cloud מושגים בסיסיים

‫GKE מבוסס על עקרונות רישות סטנדרטיים. כדי להבין איך GKE מנהל ומנתב תנועה בתוך אשכולות ובאשכולות שונים, כדאי להכיר את מושגי הליבה הבאים בנושא רשתות.

שכבות ופרוטוקולים של רשתות

כדי להבין איך הנתונים עוברים ברשת, צריך להתחיל עם שכבות הרשת. ב-GKE נעשה שימוש נרחב במושגים משכבות התעבורה, האינטרנט והאפליקציה של מחסנית הרשת. חשוב להכיר את הפונקציות הבסיסיות שלהם ואת הפרוטוקולים הנפוצים כמו HTTP,‏ DNS ו-TCP/IP. מידע נוסף זמין במאמר בנושא מודל OSI.

  • שכבת התעבורה – פרוטוקול העברת נתונים מבוקרת (TCP) או פרוטוקול User Datagram‏ (UDP): מטפלת בתקשורת מקצה לקצה בין אפליקציות. פרוטוקול העברת הנתונים המבוקרת (TCP) מספק העברה אמינה, מסודרת ומבוקרת, שחיונית לרוב תעבורת הנתונים של האפליקציות. פרוטוקול User Datagram‏ (UDP) מציע תקשורת מהירה ללא חיבור, והוא משמש לעיתים קרובות לסטרימינג או למשחקים. ב-GKE נעשה שימוש בשני הפרוטוקולים לתקשורת בין Pod לבין Service.

  • שכבת האינטרנט – פרוטוקול האינטרנט (IP): כתובות וחבילות נתונים של מסלולים ברשתות שונות. לכל Pod ולכל צומת ב-GKE מוקצית כתובת IP, וניתוב כתובות ה-IP קובע איך התנועה עוברת דרך האשכול ורשת ה-VPC.

  • שכבת האפליקציה – פרוטוקול Hypertext Transfer Protocol ‏ (HTTP) ומערכת שמות הדומיין (DNS): בשכבה הזו האפליקציות מקיימות אינטראקציה עם הרשת. פרוטוקולי HTTP ו-HTTPS הם בסיסיים לתקשורת באינטרנט, ובדרך כלל משתמשים בהם בבקרי Ingress ובמאזני עומסים כדי לחשוף אפליקציות. מערכת DNS חיונית לזיהוי שירותים ב-Kubernetes, כי היא מתרגמת שמות של שירותים שקריאים לאנשים לכתובות IP.

כתובות IP וסימון CIDR

חשוב להבין את הקצאת כתובות IP ואת הסימון CIDR (Classless Inter-Domain Routing), כי מודל הרשת של Kubernetes משתמש בכתובות IP באופן נרחב לתקשורת בין כל הרכיבים שלו. ה-CIDR חיוני לתכנון הקצאת כתובות ה-IP של האשכול ברשת ה- Google Cloud VPC. הוא מאפשר להגדיר בלוקים של כתובות IP לקבוצות Pod, לשירותים ולצמתים. לדוגמה, הקצאת 10.10.0.0/16 ל-Pods שלכם שומרת 65,536 כתובות IP. תכנון נכון של CIDR עוזר למנוע מצבים שבהם נגמרות כתובות ה-IP כשהאשכול גדל.

כלי עזר לרשתות ב-Linux

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

הסבר על מודל הרשת של Kubernetes

מודל הרשת של Kubernetes מגדיר את האופן שבו אפליקציות בקונטיינרים מתקשרות בתוך אשכול. בניגוד למודלים רגילים שמתמקדים במכונות וירטואליות, ב-Kubernetes יש דגש על תקשורת בין פודים ועל תקשורת מבוססת-שירות. המודל הזה מאפשר לחזות את התנהלות הרשת של האפליקציה בצורה טובה יותר, כי הוא מסתיר את חוסר המהימנות של כתובות ה-IP הדינמיות של ה-Pod. ה-Pods הם זמניים ואפשר ליצור אותם מחדש בכל שלב עם כתובת IP חדשה, ולכן תקשורת ישירה עם כתובות IP של Pods היא לא יציבה. ‫Kubernetes פותרת את הבעיה הזו על ידי קיבוץ של Pods לשירות. שירות מספק כתובת IP וירטואלית יציבה (ClusterIP) ושם DNS עקבי, שאפליקציות יכולות להתחבר אליהם בצורה מהימנה. נקודת הקצה היציבה הזו, בשילוב עם רשת שטוחה שמאפשרת לכל ה-Pods לתקשר ישירות בלי צורך ב-NAT, יוצרת בסיס חזק לאפליקציות מודרניות שמבוססות על קונטיינרים.

עקרונות מרכזיים של מודל הרשתות של Kubernetes

  • לכל Pod יש כתובת IP ייחודית: כל Pod באשכול Kubernetes מקבל כתובת IP משלו, שמשותפת לכל הקונטיינרים ב-Pod הזה. כתובת ה-IP הייחודית הזו מאפשרת ל-Pods לפעול כמו מארחים נפרדים ברשת, בדומה למכונות וירטואליות.

  • תקשורת שטוחה בין פודים ללא NAT: כל הפודים יכולים לתקשר ישירות זה עם זה באמצעות כתובות ה-IP שלהם, ללא קשר לצומת שבו הם פועלים. ב-GKE, התקשורת הישירה הזו מתבצעת באמצעות אשכולות מקוריים של VPC, שבהם כתובות ה-IP של ה-Pod הן כתובות IP של כינוי ברשת ה-VPC. כתובות ה-IP של הכינויים האלה מאפשרות ניתוב ישיר של ה-Pods בתוך ה-VPC, כך שלא צריך לבצע תרגום כתובות רשת (NAT) והתקשורת בין הצמתים פשוטה יותר.

  • שירותים מספקים נקודות קצה יציבות: מכיוון ש-Pods הם זמניים ואפשר ליצור אותם מחדש בכל שלב עם כתובות IP חדשות, תקשורת ישירה עם כתובות IP של Pods היא לא אמינה. שירותי Kubernetes פותרים את הבעיה הזו על ידי קיבוץ של קבוצת Pods וחשיפה של כתובת IP יציבה (ClusterIP) ושם DNS. ההפשטה הזו של הבעיה מאפשרת גישה עקבית לקבוצה דינמית של Pods.

  • זיהוי שירותים מובנה באמצעות DNS: Kubernetes כולל שירות DNS מובנה שמקצה באופן אוטומטי שמות DNS לשירותים. אפליקציות יכולות להשתמש בשמות האלה (לדוגמה, my-service.my-namespace.svc.cluster.local) כדי לאתר שירותים אחרים ולתקשר איתם בצורה מהימנה.

  • איזון עומסים משולב. כשלקוחות שולחים תעבורה לכתובת ClusterIP של שירות, כללי הרשת בצומת (שתוכנתו על ידי kube-proxy או GKE Dataplane V2) מיירטים את התעבורה ומאזנים את העומס שלה בכל ה-Pods התקינים בשירות הזה. ההפצה הזו מתבצעת במקור, ולכן היא יעילה מאוד ועוזרת להבטיח זמינות גבוהה.

לסיכום, מודל הרשת של Kubernetes מפשט הרבה מורכבויות של רשתות קונבנציונליות, ומציג קבוצה פשוטה ויעילה יותר של פרימיטיבים לאפליקציות מבוססות-קונטיינרים. הוא מספק בסיס חזק וניתן להרחבה לאפליקציות מודרניות שמבוססות על קונטיינרים, באמצעות הפעלה של תקשורת ישירה בין פודים, נקודות קצה (endpoints) יציבות של שירותים, ו-DNS משולב ואיזון עומסים.

הקשר בין GKE לבין Google Cloud

הרישות ב-GKE משמש כגשר בין המודל המושגי של הרישות ב-Kubernetes לבין התשתית הפיזית של Google Cloud:

  • מודל הרשת של Kubernetes: ‏ Kubernetes מגדיר כללים שלפיהם כל Pod מקבל כתובת IP משלו, וכך מאפשר תקשורת ישירה בין Pod ל-Pod בלי שיהיה צורך ב-NAT.

  • ‫Google Cloud Networking: זו התשתית הבסיסית, כולל VPC, רשתות משנה, חומות אש ומאזני עומסים.

  • רשת GKE: שכבת החיבור הזו מטמיעה את מודל Kubernetes באמצעות התשתית של Google Cloud.

  • ‫Container Network Interface (CNI): ‏ GKE משתמש בתוסף CNI בכל צומת כדי לטפל בהקצאת כתובות IP של Pod ולחבר את ה-Pods לרשת של הצומת.

  • מישור הבקרה של GKE: הרכיבים האלה פועלים באינטראקציה עםGoogle Cloud כדי להגדיר באופן אוטומטי נתיבי VPC לטווחי כתובות IP של Pod, לנהל כללי חומת אש ולספק מאזני עומסים על סמך פריסות Kubernetes.

בתרשים הבא מוצג זרימת התנועה הנכנסת והיוצאת אל אשכולות GKE שנמצאים ב-VPC ומאחורי חומת אש בענן, ומהם. תעבורת נתונים נכנסת (ingress) כוללת תעבורת נתונים מאוזנת עומסים מרכיבים כמו שרת proxy של SSL, שרת proxy של TCP או איזון עומסים של HTTP(S). תעבורת נתונים יוצאת כוללת יעדים כמו רשתות חיצוניות, משתמשים ואיזון עומסים של שרתי proxy מסוג TCP.
איור 1. רשתות GKE משולבות עם Google Cloud רכיבים כמו VPC,‏ Cloud Load Balancing ו-Cloud Firewall כדי לספק סביבה מאובטחת וניתנת להרחבה.

למה Google Cloud ידע ברישות חיוני ל-GKE

‫GKE מבוסס על Google Cloud תשתית רשת. ‫GKE לא יוצר שכבת רשת נפרדת – במקום זאת, הוא משתמש ברכיבי רשת קיימים Google Cloud . לכן, חשוב להבין Google Cloud את הרשתות כדי לתכנן את אשכולות ה-GKE ולהגן עליהם.

למה חשוב להכיר את Google Cloud היסודות של רשתות:

  • האשכול פועל ב-VPC: כל אשכול GKE פועל ב-VPC. כל כתובות ה-IP – של הצמתים, ה-Pods והשירותים – נלקחות מטווח כתובות ה-IP שמוגדר בתת-הרשתות של ה-VPC. כדי להקצות כתובות IP בצורה נכונה ולהימנע ממצב שבו לא נשארות כתובות IP, צריך להכיר את VPC ואת תכנון רשתות המשנה. מידע נוסף זמין במאמר בנושא VPC.

  • חשיפת אפליקציות באמצעות Google Cloud מאזני עומסים: כשחושפים אפליקציות מחוץ לאשכול באמצעות שירות LoadBalancer או Ingress, ‏ GKE מקצה מאזן עומסים מובנה Google Cloud . בדרך כלל משתמשים בשירות LoadBalancer לתנועה בשכבה 4, וב-Ingress לתנועה בשכבה 7 של HTTP(S). הבנה של אופן הפעולה של מאזני העומסים האלה עוזרת לכם לנהל תנועה חיצונית, להגדיר בדיקות תקינות ולפתור בעיות קישוריות בצורה יעילה. מידע נוסף זמין במאמרים בנושא Cloud Load Balancing.

  • האבטחה נאכפת באמצעות Google Cloud כללי חומת אש: ‫GKE יוצר באופן אוטומטי כללי חומת אש מסוימים כדי לאפשר תעבורה חיונית באשכול. עם זאת, כדי לאבטח את עומסי העבודה, צריך להגדיר כללים מותאמים אישית של חומת האש ב-VPC. הגדרות שגויות עלולות לחסום תנועה קריטית, ולכן חשוב להבין איך הכללים האלה פועלים. מידע נוסף זמין במאמרי העזרה בנושא Cloud Next Generation Firewall.

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