היסודות של רשתות 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 של האשכול ברשת ה-VPC. Google Cloudהוא מאפשר להגדיר בלוקים של כתובות IP לקבוצות Pod, לשירותים ולצמתים. לדוגמה, הקצאת 10.10.0.0/16 ל-Pods שלכם שומרת 65,536 כתובות IP. תכנון נכון של CIDR עוזר למנוע מצבים שבהם נגמרות כתובות ה-IP כשהאשכול גדל.

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

‫GKE משתמש בתכונות של ליבת Linux כדי ליישם ניתוב תעבורה ואיזון עומסים באשכול. צריך להכיר מושגים בסיסיים בניהול רשתות ב-Linux וכלי עזר כמו טבלאות ניתוב ו-iptables. באופן מסורתי, kube-proxy, רכיב מרכזי של Kubernetes בכל צומת, מתכנת את כלי השירות האלה כדי ליירט תנועה שמיועדת לשירות ולהפנות אותה לאחד מ-Pods של העורף. באשכולות 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 מפשט הרבה מורכבויות רגילות של רשתות, ומציג קבוצה פשוטה ויעילה יותר של פרימיטיבים לאפליקציות מבוססות-קונטיינרים. הוא מספק בסיס חזק וניתן להרחבה לאפליקציות מודרניות שמבוססות על קונטיינרים, באמצעות הפעלה של תקשורת ישירה בין פודים, נקודות קצה יציבות של שירותים, DNS משולב ואיזון עומסים.

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

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

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

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

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

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

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

בתרשים הבא מוצג זרימת התעבורה הנכנסת והיוצאת אל אשכולות GKE שנמצאים ב-VPC ומאחורי חומת אש בענן, ומהם. תנועת גולשים נכנסת כוללת תנועה מאוזנת עומסים מרכיבים כמו שרת 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 לכן, כדי לתכנן את אשכולות ה-GKE ולהגן עליהם, חשוב להבין את Google Cloud הרשתות.

למה חשוב להבין את היסודות של רשתות 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.

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