מידע על ארכיטקטורת הרשת של GKE

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

  • איך הרכיבים האלה פועלים יחד ב-VPC
  • איך כתובות IP מוקצות ומנוהלות
  • איך תעבורת הנתונים זורמת אל האשכול, בתוכו וממנו

ארכיטקטורה של רשת GKE

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

הבסיס של ה-VPC וטווחי כתובות ה-IP

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

  • טווח כתובות ה-IP של הצומת: זהו טווח כתובות ה-IP הראשי של רשת המשנה שבה נפרסים צמתי האשכול. כל צמתי העובדים של GKE, שהם מכונות וירטואליות ב-Compute Engine, מקבלים את כתובות ה-IP הראשיות שלהם מהטווח הזה. כתובות ה-IP האלה משמשות לתקשורת בין הצמתים ולבדיקות תקינות ממאזני עומסים. כתובת ה-IP של הצומת היא גם המקור של התנועה שמקורה בצומת עצמו. באשכולות מקוריים של VPC, התנועה מ-Pods משתמשת בכתובת ה-IP של ה-Pod ככתובת המקור, אלא אם כתובת ה-IP של ה-Pod מתורגמת על ידי תכונה כמו Cloud NAT.
  • טווח כתובות ה-IP של ה-Pod: טווח כתובות IP משני ייעודי, לרוב בלוק CIDR גדול יותר, שנמצא בתוך רשת המשנה. כל צומת מקבל מאגר של כתובות IP מהטווח הזה. מערכת GKE מקצה את כתובות ה-IP האלה ל-Pods שפועלים בצומת הזה. כל פוד באשכול מקבל כתובת IP ייחודית מהטווח הזה. אפשר לנתב את כתובות ה-IP של ה-Pod באופן מקורי בענן הווירטואלי הפרטי. כברירת מחדל, כל צומת מקבל טווח של /24, שמספק 256 כתובות IP. עם זאת, ב-GKE יש מגבלה של 110 פודים לכל צומת. המאגר הזה עוזר להבטיח שכתובות ה-IP יהיו זמינות במהלך יצירה ומחיקה מהירות של Pod, תהליך שנקרא גם churn. כתובות ה-IP האלה מאפשרות תקשורת ישירה בין Pods בצמתים שונים, בלי שנדרש תרגום כתובות רשת (NAT).
  • טווח כתובות IP של שירות (ClusterIP): טווח משני של כתובות IP לכתובות ה-IP הווירטואליות (ClusterIP) שהוקצו לשירותי Kubernetes. כתובות ה-IP הקבועות האלה משמשות רק לתקשורת בתוך האשכול.
  • כתובת ה-IP של מישור הבקרה: לכל מישור בקרה יש כתובת IP ציבורית או פנימית, בהתאם לסוג האשכול, לגרסה ולתאריך היצירה. כתובת ה-IP הזו משמשת צמתי עובד ולקוחות חיצוניים, כמו kubectl, כדי לתקשר בצורה מאובטחת עם שרת ה-API של Kubernetes. ‫GKE Frontend‏ (GKFE) מספק נקודת קצה מבוססת-DNS לכל אשכול, ומציע דרך מאובטחת ואמינה לגשת למישור הבקרה בלי לנהל כתובות IP באופן ישיר.

שלושת עמודי התווך של רשתות GKE

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

  • רשת Pod: השכבה הבסיסית, שמגדירה איך קונטיינרים (Pods) בודדים מתקשרים זה עם זה בתוך האשכול.
  • Service networking: השכבה הזו מבוססת על Pod networking ומתארת איך שירותי Kubernetes מספקים נקודות קצה יציבות כדי לחשוף אפליקציות ללקוחות פנימיים או חיצוניים, כולל איזון עומסים וגילוי שירותים.
  • רישות של אשכולות: השכבה החיצונית ביותר, שכוללת את אופן החיבור של אשכול GKE שלכם למערכת האקולוגית הרחבה של הרשת, כולל ניהול תעבורת נתונים נכנסת (ingress) מהאינטרנט, תעבורת נתונים יוצאת (egress) לשירותים חיצוניים וקישוריות לשירותים של Google Cloud ולמערכות מקומיות.

השכבות האלה פועלות יחד כדי ליצור מודל תקשורת מקיף שתומך בקישוריות פנימית וחיצונית, באבטחה ובגמישות. בקטעים הבאים מפורט כל אחד מהעקרונות.

רשתות Pod

רשתות של Pod הן הבסיס לכל התקשורת באשכול GKE. הוא מגדיר איך אפליקציות שפועלות בתוך קבוצות Pod יכולות למצוא אחת את השנייה ולקיים אינטראקציה ביניהן. ב-Kubernetes, ‏ Pod היא היחידה הכי קטנה והכי בסיסית שאפשר לפרוס. ‫Pod משמש כמארח לוגי לאפליקציות שלכם. הוא מריץ מאגר אחד או יותר שמשתפים משאבי רשת. כשמגדירים תזמון של Pod בצומת, Kubernetes יוצר מרחב שמות ייעודי ברשת בשבילו בקרנל של Linux בצומת, שמבודד את הרשת שלו מ-Pods אחרים באותו צומת.

איך פועלת רשת ה-Pod

הקישוריות בין הפודים מתבססת על שילוב של כתובות IP ייחודיות, מכשירי רשת וירטואליים ותוספים ייעודיים שמנהלים את הקישוריות.

ממשק רשת של קונטיינר (CNI): ‏ GKE משתמש בפלאגינים של CNI כדי להטמיע ולנהל את הרשת של ה-Pod. באשכולות המותאמים ל-VPC, ברירת המחדל היא Google CNI. אפשרויות נוספות כוללות את kubenet (למערכות לא מקוריות של VPC), Calico ו-GKE Dataplane V2 (שמבוסס על Cilium). התוספים האלה אחראים לחיבור של ה-Pods לרשת ולאכיפה של מדיניות הרשת.

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

  • מרחבי שמות ברשת וזוגות של אתרנט וירטואלי (veth): כדי לאפשר תקשורת, Kubernetes מחבר את מרחב השמות המבודד ברשת של ה-Pod למרחב השמות הראשי או הבסיסי ברשת של הצומת. ‫Kubernetes יוצר את החיבור הזה באמצעות זוג אתרנט וירטואלי, או זוג veth, שפועל כמו כבל רשת וירטואלי. קצה אחד של הצמד ממוקם במרחב השמות של ה-Pod ומופיע כ-eth0. הקצה השני מתחבר לגשר רשת או ישירות למערך הרשת של הצומת במרחב השמות הבסיסי של הצומת, וכך מאפשר זרימת חבילות אל ה-Pod וממנו.

    שיטת החיבור הספציפית תלויה בפלאגין CNI שבו משתמשים באשכול:

    • ‫Google CNI: זהו CNI ברירת המחדל עבור אשכולות מקוריים של VPC. זוג ה-veth של ה-Pod מתחבר למרחב השמות של רשת הבסיס של הצומת. כתובות ה-IP של ה-Pod הן כתובות IP של כינוי שמוכרות לרשת ה-VPC, ולכן הניתוב הרגיל של Linux בצומת מכוון את התנועה אל ה-Pod וממנו.
    • ‫GKE Dataplane V2: משתמש בתוכניות eBPF כדי לטפל ברישות של Pod, ולעתים קרובות עוקף גשרים רגילים של לינוקס וזוגות veth כדי לנהל ישירות את זרימות המנות בתוך הליבה, וכך לשפר את הביצועים.
    • ‫Kubenet: משמש באשכולות שלא מותאמים ל-VPC. הקצה השני של זוג veth מתחבר למכשיר גישור של Linux שנקרא cbr0במרחב השמות הבסיסי של הצומת. הגשר הזה מנהל את התעבורה בין ה-Pods באותו צומת ומשתמש ב-NAT לתעבורה שיוצאת מהצומת.
    • Calico: כשמדיניות הרשת מופעלת באמצעות Calico, הקצה השני של זוג veth מתחבר למרחב השמות הבסיסי של הצומת, ואז Calico מתכנת מסלולי מארח כדי לנתב את התנועה אל ה-Pods הנכונים.

‫Maximum Transmission Unit (MTU): הערך הזה קובע את הגודל המקסימלי של חבילת נתונים שאפשר לשלוח ברשת בלי שהיא תפוצל. ב-GKE,‏ MTU לממשק של Pod היא הגדרה קריטית שתלויה בתוסף GKE CNI שבו נעשה שימוש באשכול ובהגדרות ה-MTU של רשת ה-VPC הבסיסית. אי-התאמה בערכי MTU עלולה לגרום לאובדן מנות או לירידה בביצועים. ערך ה-MTU של ממשק ה-Pod הוא 1,460 בייט קבוע או שהוא עובר בירושה מממשק הרשת הראשי של הצומת, כמו שמוצג בטבלה הבאה.

CNI MTU Usage
Google CNI 1460 ברירת המחדל לאשכולות מקוריים של VPC שמשתמשים בגרסאות GKE מוקדמות מ-1.26.1.
Google CNI עבר בירושה ברירת המחדל לאשכולות מקוריים של VPC שמשתמשים בגרסאות GKE 1.26.1 ואילך.
Calico 1460 ההגדרה הזו משמשת כשהמדיניות לגבי רשת מופעלת (--enable-network-policy).
GKE Dataplane V2 עבר בירושה האפשרות הזו משמשת כש-GKE Dataplane V2 מופעל (--enable-dataplane-v2).
netd עבר בירושה הערך הזה משמש כשתכונות כמו 'Intranode' visibility,‏ איחוד זהויות של עומסי עבודה ל-GKE או IPv4/IPv6 dual-stack networking מופעלות.

תהליך התקשורת בין פודים

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

תקשורת באותו צומת

כש-Pod שולח תנועה ל-Pod אחר באותו צומת, הבקשה עוברת ממרחב השמות של הרשת של ה-Pod הראשון, דרך זוג ה-veth שלו, אל מרחב השמות של רשת הבסיס של הצומת. התנועה הזו נשארת בתוך הצומת. בהתאם לתוסף ה-CNI שבו נעשה שימוש, תוסף ה-CNI מעביר את התעבורה לזוג veth של הפוד השני. לדוגמה, עם kubenet, מכשיר גישור מעביר את התנועה. ב-GKE Dataplane V2, תוכניות eBPF מנהלות את זרימת המנות ישירות.

תקשורת בין צמתים שונים

כש-Pod בצומת אחת שולח תנועה ל-Pod בצומת אחרת, התנועה זורמת למרחב השמות של רשת הבסיס של הצומת הראשונה. תעבורת הנתונים יוצאת מממשק הרשת הראשי של הצומת הראשון ונכנסת לרשת ה-VPC. מכיוון שכתובות ה-IP של הפוד ניתנות לניתוב באופן מקורי באשכול GKE מקורי של VPC, רשת ה-VPC מנתבת את תעבורת הנתונים ישירות לצומת השני. הצומת השני מעביר את התנועה אל ה-Pod של היעד.

אירוח של Pods ברשת

בתרחישי שימוש ספציפיים, אפשר להגדיר Pod עם ההגדרה hostNetwork: true. ההגדרה הזו עוקפת את רשת ה-Pod המבודדת ומאפשרת ל-Pod לשתף ישירות את מרחב השמות של הרשת של הצומת. בגישה ישירה כזו, ה-Pod משתמש בכתובת ה-IP של הצומת ויכול לתקשר עם כל שאר ה-Pods בלי צורך ב-NAT. באשכולות שמשתמשים בתוסף kubenet CNI, ההתנהגות הזו שונה מההתנהגות של Pods רגילים. לפודים רגילים נדרש NAT לתעבורת נתונים יוצאת, כי אי אפשר לנתב את כתובות ה-IP שלהם ישירות ברשת ה-VPC. לעומת זאת, ברשתות של GKE שמוגדרות כ-VPC-native, התרגום הזה לא נדרש לכל ה-Pods. עם זאת, כשמגדירים Pods באמצעות ההגדרה hostNetwork: true, צריך להיזהר כדי למנוע התנגשויות בין יציאות לבין תהליכים או Pods אחרים שפועלים באותו צומת. בקטעי קוד שמשתמשים ב-kubenetCNI, גשר הרשת הווירטואלית cbr0 נוצר רק אם לצומת יש Pods עם ההגדרה hostNetwork: false.

Service Networking

למרות שרשתות של פודים מספקות את הקישוריות הבסיסית בין פודים נפרדים, הן לא מספיקות לבניית אפליקציות חזקות וניתנות להרחבה. תאי Pod הם זמניים. אפשר ליצור אותם, להרוס אותם ולתזמן אותם מחדש בכל שלב. במצב הזה, כתובות ה-IP שלהם משתנות. רשתות שירותים פותרות את הבעיה הזו על ידי מתן דרך יציבה ואמינה לחשיפת אפליקציות ולניהול האופן שבו הן מתקשרות, גם בתוך האשכול וגם עם העולם החיצוני.

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

איך פועל Service networking

רשת השירותים מסתמכת על שני מנגנונים מרכזיים לניתוב תעבורה מנקודת קצה יציבה של שירות לתרמילי ה-Backend הדינמיים שלו: גילוי שירותים ואיזון עומסים.

זיהוי שירותים: כדי שאפליקציות יוכלו למצוא אחת את השנייה ולתקשר ביניהן,‏ GKE מספק שירות DNS פנימי (או kube-dns או Cloud DNS). כשיוצרים שירות, שירות ה-DNS יוצר באופן אוטומטי רשומת DNS תואמת. הרשומה הזו מאפשרת לאפליקציות להתחבר לשירות באמצעות שם ה-DNS שלו (לדוגמה, my-app-service) במקום להצטרך לדעת את ה-ClusterIP שלו. למרות ש-kube-dns היא ברירת המחדל עבור אשכולות רגילים, Cloud DNS ל-GKE הוא הפתרון המומלץ לרוב סביבות הייצור. זה גם הפתרון הנתמך היחיד עבור אשכולות GKE Autopilot. השירות הזה מנוהל במלואו, ניתן להרחבה וזמין מאוד. הוא משתלב עם רשתות VPC ועם Cloud Logging, ומציע ביצועים משופרים ויכולת מעקב בלי לדרוש מכם לנהל את ה-Pods של kube-dns.

מנגנוני איזון עומסים: ההטמעה של איזון עומסים בשירות תלויה במצב הרשת של אשכול GKE.

  • ‫GKE Dataplane V2: אשכולות שמשתמשים ב-GKE Dataplane V2 (שמבוסס על Cilium) לא משתמשים ב-kube-proxy לאיזון עומסים של שירותים. במקום זאת, ב-GKE Dataplane V2 נעשה שימוש בתוכניות eBPF שפועלות בקרנל של Linux. תוכניות ה-eBPF האלה יעילות מאוד ביירוט תעבורת נתונים ל-Service ClusterIPs ובאיזון עומסים ישירות לתעבורת נתונים ל-Pods המתאימים בעורף. הגישה הזו מובילה לביצועים טובים יותר ומשולבת באופן הדוק עם יכולות האכיפה של מדיניות הרשת ב-GKE Dataplane V2.

  • ‫kube-proxy (באשכולות ללא GKE Dataplane V2): בכל צומת באשכול GKE שלא משתמש ב-GKE Dataplane V2, רכיב בשם kube-proxy מטמיע את מנגנון כתובת ה-IP הווירטואלית לשירותים. ‫kube-proxy עוקב אחרי שרת ה-API של Kubernetes כדי לזהות שינויים ב-Services וב-Endpoints, ואז מתכנת כללי רשת בצומת כדי ליירט תעבורה שמיועדת ל-ClusterIP של Service.

    אפשר להשתמש ב-kube-proxy במצבים שונים, כולל:

    • מצב iptables: זהו מצב ברירת המחדל. ‫kube-proxy מוסיף ומסיר כללי NAT של יעד (DNAT) במערכת המשנה iptables של הצומת. כשמגיע תנועה ל-ClusterIP של שירות, הכללים האלה מבצעים תרגום NAT ומשנים את כתובת ה-IP של היעד לאחת מכתובות ה-IP של פודים בריאים בעורף. איזון העומסים בין ה-Pods בקצה העורפי הוא בדרך כלל אקראי או מסוג round-robin.
    • מצב ipvs: במצב הזה נעשה שימוש ב-IP Virtual Server ‏ (IPVS) של Linux כדי לאזן עומסים ברמה גבוהה. ‫kube-proxy מגדיר כללי IPVS, שיכולים לטפל במספר גדול של שירותים ולספק אלגוריתמים מתוחכמים יותר לאיזון עומסים.

דוגמה לזרימת תקשורת פנימית

ברשימה הבאה מתואר איך בקשה זורמת מ-Pod של לקוח ל-Pod של שרת באמצעות Service באשכול שלא נעשה בו שימוש ב-GKE Dataplane V2:

  1. אפליקציית הלקוח מבצעת שאילתת DNS עבור my-server-service.
  2. שירות ה-DNS הפנימי של האשכול מתאים את השם הזה ל-ClusterIP היציב של השירות (לדוגמה, 10.0.32.8).
  3. ה-Pod של הלקוח שולח בקשה ל-ClusterIP של השירות.
  4. הכללים של iptables בצומת של הלקוח, שמנוהלים על ידי kube-proxy, מיירטים את הבקשה הזו.
  5. הכללים האלה iptables מבצעים DNAT ובוחרים אחד מ-Pod הבק-אנד התקינים עבור my-server-service (לדוגמה, Pod 2 עם כתובת ה-IP 10.4.0.3). הכללים גם משכתבים את כתובת ה-IP של היעד של המנה לכתובת ה-IP של ה-Pod.
  6. המנה מנותבת דרך רשת ה-Pod השטוחה אל Pod 2, שמעבד את הבקשה.

באשכולות שמשתמשים ב-GKE Dataplane V2, תוכניות eBPF מטפלות בחסימה ובאיזון העומסים של התעבורה אל Service ClusterIP, תוך עקיפה של kube-proxy ושל iptables.

מניפסט של שירות לדוגמה

בדוגמה הבאה מוצג מניפסט של שירות. השדה selector מציין אילו פודים מקבלים תנועה על סמך התוויות שלהם.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

תכונות של Service Networking

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

  • איזון עומסים פנימי וחיצוני. בשירותים שצריך לגשת אליהם רק מתוך האשכול, kube-proxy (או GKE Dataplane V2) מטפל באיזון העומסים באופן פנימי. בשביל שירותים שצריכים להיות חשופים לאינטרנט, GKE מקצה באופן אוטומטי מאזן עומסים בענן כדי להפיץ תעבורה חיצונית לצמתים באשכול.
  • מאזני עומסים של אפליקציות לניתוב HTTP(S). לתנועת HTTP(S),‏ GKE משתמש במאזן עומסים ייעודי בשכבה 7, מאזן העומסים של האפליקציות. כדי להגדיר את מאזן העומסים הזה, משתמשים ב-Kubernetes Gateway API, שזו הגישה המומלצת לכל האפליקציות החדשות. בקר GKE Gateway הוא ההטמעה של Google של Gateway API, והוא נועד להיות מחליף יותר גמיש, מפורט וניתן להרחבה של משאב Ingress. ‫Gateway API משתמש במשאבים הבאים כדי להגדיר את מאזן העומסים:
    • Gateway: מגדיר את ההגדרות של מאזין כמו יציאות, פרוטוקולים ושמות מארחים. הוא משמש כנקודת הכניסה לתעבורה.
    • ‫HTTPRoute: מציין איך תעבורה שמתקבלת על ידי Gateway מנותבת לשירותים. הוא תומך בתכונות מתקדמות כמו ניתוב מבוסס-נתיב, התאמת כותרות ופיצול תנועה.
    • מדיניות: מגדירה איך התשתית הבסיסית Google Cloud צריכה לפעול על ידי צירוף שלה לשער, למסלול או לשירות.
  • שילוב Service mesh. במקרה של ארכיטקטורות מיקרו-שירותים מורכבות,‏ GKE תומך בטכנולוגיות Service mesh. ‫Service mesh היא שכבת תשתית אופציונלית שמספקת תכונות מתקדמות לניהול תעבורה, לניראות ולאבטחה. כדי ליהנות מחוויה מנוהלת ומנתמכת באופן מלא, GKE מציע את Cloud Service Mesh, שמבוסס על Istio.

נטוורקינג באשכול

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

ניהול של תנועה נכנסת

תנועת נתונים נכנסת היא תנועה שנכנסת לאשכול שלכם מהעולם החיצוני. ‫GKE משתמש בכמה תכונות משולבות Google Cloud כדי לנהל את התעבורה הזו ולאבטח אותה.

זרימת נתונים של גישה חיצונית: כשלקוח מהאינטרנט שולח בקשה לאפליקציה שלכם (בדרך כלל דרך שירות מסוג LoadBalancer או משאב Ingress או Gateway), הבקשה מגיעה קודם למאזן עומסים Google Cloud . מאזן העומסים מעביר את הבקשה לצומת תקין באשכול. הצומת מעביר את התנועה אל ה-Pod המתאים. ‫kube-proxy מטפל בהעברה הזו באשכולות שלא משתמשים ב-GKE Dataplane V2, או שתוכניות eBPF מטפלות בה באשכולות שמשתמשים ב-GKE Dataplane V2. יכול להיות ש-Pod היעד נמצא באותו צומת או בצומת אחר.

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

אופטימיזציה של זרימת תנועה חיצונית: כשמאזן עומסים שולח תנועה לצומת, יכול להיות שהצומת יצטרך להעביר את התנועה הזו ל-Pod בצומת אחר, מה שדורש עוד קפיצות ברשת. כדי למנוע את המצב הזה, צריך להגדיר את השדה externalTrafficPolicy לערך Local במניפסט השירות. כשהמדיניות הזו פעילה, מאזן העומסים משתמש בבדיקת תקינות כדי לזהות אילו צמתים כוללים פודים תקינים עבור שירות היעד. מאזן העומסים שולח תנועה רק ל-Pods תקינים, וכך מונע את הצעד הנוסף ברשת. החיסרון הוא שהמדיניות הזו עלולה להוביל לחלוקת תעבורה לא אחידה אם ה-Pods של ה-Backend לא מחולקים באופן שווה בין הצמתים באשכול.

ניהול טראפיק יוצא

תעבורת נתונים יוצאת (egress) היא תנועה שיוצאת מהאשכול. כדי שאשכול GKE יפעל והאפליקציות שלכם יוכלו לגשת לשירותים חיצוניים, אתם צריכים לנהל כמה נתיבי קישוריות.

דרישות בסיסיות לקישוריות: כל אשכולות GKE צריכים קישוריות יוצאת לדומיינים *.googleapis.com, *.gcr.io ו-*.pkg.dev. גם הקישוריות היוצאת לכתובת ה-IP של מישור הבקרה צריכה לפעול בצורה תקינה. גישה לאינטרנט ל-Pods באמצעות Cloud NAT: באשכולות פרטיים שבהם ל-Pods אין כתובות IP ציבוריות, אפשר להשתמש ב-Cloud NAT כדי לאפשר גישה לאינטרנט יוצא. ‫Cloud NAT הוא שירות מנוהל שמאפשר ל-Pods להתחבר לאינטרנט כדי לבצע משימות כמו הורדת עדכונים או גישה לממשקי API חיצוניים, בלי לחשוף אותם לחיבורים נכנסים.

קישוריות ל Google Cloud שירותים: אם אתם צריכים לאפשר לאשכול לתקשר בצורה מאובטחת עם Google Cloud שירותים אחרים, כמו Cloud Storage או Cloud SQL, בלי להעביר את התקשורת באינטרנט הציבורי, אתם יכולים להשתמש בגישה פרטית ל-Google. זהו מנגנון חשוב לתעבורת נתונים יוצאת (egress) של אשכולות פרטיים שמתקשרים עם Google APIs.

קישוריות היברידית ומרובת אשכולות

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

אמצעי בקרה לאבטחת רשת

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

אבטחת תנועה פנימית (מזרח-מערב) באמצעות כללי מדיניות רשת

כברירת מחדל, כל ה-Pods באשכול GKE יכולים לתקשר אחד עם השני באופן חופשי. כדי לאבטח תנועה פנימית ולאכוף את העיקרון של הרשאות מינימליות, אפשר להשתמש ב-NetworkPolicy. NetworkPolicy הוא משאב Kubernetes שפועל כחומת אש עבור ה-Pods שלכם על ידי שליטה בתעבורת הרשת ביניהם. NetworkPolicy מאפשרים להגדיר כללים להגבלת תעבורת הנתונים הנכנסת והיוצאת לקבוצה נבחרת של Pods על סמך שילוב של תוויות, טווחי כתובות IP ומספרי יציאות. כשיוצרים את NetworkPolicy הראשון במרחב שמות, כל התנועה שלא אושרה במפורש על ידי המדיניות הזו נדחית. האכיפה של המדיניות הזו מוטמעת ישירות ב-GKE Dataplane V2, או שמטופלת על ידי פלאגין CNI של האשכול, כמו Calico.

דוגמה לקובץ מניפסט NetworkPolicy

בדוגמה הבאה מוצג מניפסט של NetworkPolicy. המדיניות הזו חלה על Pods עם התווית app: backend ומאפשרת תעבורת נתונים נכנסת רק מ-Pods עם התווית app: frontend ביציאת TCP‏ 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

גישה חיצונית מאובטחת לאשכול

שליטה בתנועה שנכנסת לאשכול ויוצאת ממנו היא קריטית להגנה על האפליקציות מפני איומים חיצוניים.

כללי חומת אש ב-VPC

אשכולות GKE נמצאים ברשת Google Cloud VPC ומוגנים על ידי כללי חומת אש של VPC ששולטים בתעבורה אל צמתי האשכול וממנו. כללי חומת אש ב-VPC ומדיניות רשת פועלים יחד כדי לספק הגנה מעמיקה. חומות האש של VPC פועלות ברמת הצומת (שכבה 3 או שכבה 4), והן שולטות בתעבורה למכונות הווירטואליות עצמן. מדיניות הרשת פועלת ברמת ה-Pod (שכבה 3 או שכבה 4), והיא מספקת שליטה מפורטת יותר בתנועה בין אפליקציות בתוך האשכול.

יצירת כללי חומת אש של תעבורת נתונים נכנסת או יוצאת שמטרגטים צמתים באשכול עלולה להוביל להשפעות שליליות. לדוגמה, החלת כללי egress-deny על צמתים באשכול עלולה לשבור תכונות כמו NodePort ו-kubectl exec.

הגבלת הגישה למאזני עומסים

כשחושפים אפליקציות באמצעות Kubernetes Service או Ingress, אפשר להחיל אמצעי בקרה נוספים על האבטחה ברמת איזון העומסים. למאזני עומסים חיצוניים, כדאי לשקול את האפשרויות הבאות:

  • אם חושפים שירות באמצעות השדה type: LoadBalancer, אפשר לציין את השדה loadBalancerSourceRanges במניפסט השירות. השדה הזה מגביל את הגישה לשירות רק לטווחי כתובות ה-IP שאתם מגדירים.

  • כשחושפים אפליקציות HTTP (S), אפשר להשתמש בשירותי אבטחה מתקדמים יותר למאזני עומסים של אפליקציות(Ingress):

    • ‫Google Cloud Armor: שירות זה הוא חומת אש ליישומי אינטרנט (WAF) שעוזרת להגן על האפליקציות מפני מתקפות DDoS ואיומים אחרים באינטרנט.
    • שרת proxy לאימות זהויות (IAP): כדי להגדיר בקרת גישה פרטנית, אפשר להפעיל IAP בנקודות הקצה. ‫IAP מאמת את זהות המשתמש ומשתמש בה כדי לקבוע אם המשתמש צריך לקבל גישה לאפליקציה.

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