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

טייס אוטומטי רגילה

הרשתות של Google Kubernetes Engine ‏ (GKE) משתמשות בתשתית של שירותי Networking מוגדרי-תוכנה (SDN) שסופקה על ידי ענן וירטואלי פרטי (VPC), ומרחיבות אותה. רשת GKE מאפשרת לרכיבים לתקשר בתוך אשכול Kubernetes ועם שירותים ורשתות חיצוניים. מודל הרשת של GKE מבוסס על העיקרון של רשת Kubernetes, שבו כל Pod מקבל כתובת IP משלו, כדי לספק כתובות IP, איזון עומסים, פענוח DNS ואכיפה של מדיניות רשת ב-Kubernetes. במסמך הזה מוסבר איך רכיבי ליבה כמו צמתים, 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 של הפוד: טווח כתובות IP משני ייעודי, לרוב בלוק CIDR גדול יותר, שנמצא ברשת המשנה. כל צומת מקבל מאגר של כתובות IP מהטווח הזה. ‫GKE מקצה את כתובות ה-IP האלה ל-Pods שפועלים בצומת הזה. כל Pod באשכול מקבל כתובת IP ייחודית מהטווח הזה. אפשר לנתב את כתובות ה-IP של ה-Pod באופן מקורי בענן הווירטואלי הפרטי. כברירת מחדל, כל צומת מקבל טווח /24, שמספק 256 כתובות IP. עם זאת, ב-GKE יש מגבלה של 110 פודים לכל היותר לכל צומת. המאגר הזה עוזר להבטיח שכתובות IP יהיו זמינות במהלך יצירה ומחיקה מהירות של Pods, תהליך שנקרא גם "שיעור נטישה". כתובות ה-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) בודדים מתקשרים זה עם זה בתוך האשכול.
• רשתות שירות: שכבה שמבוססת על רשתות Pod ומתארת איך שירותי Kubernetes מספקים נקודות קצה יציבות כדי לחשוף אפליקציות ללקוחות פנימיים או חיצוניים, כולל איזון עומסים וגילוי שירותים.
• רשת של אשכולות: השכבה החיצונית ביותר, שכוללת את אופן החיבור של כל אשכול GKE למערכת האקולוגית הרחבה של הרשת, כולל ניהול תעבורת נכנסת מהאינטרנט, תעבורת יוצאת לשירותים חיצוניים וקישוריות לשירותי Google Cloud ולמערכות מקומיות.

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

רשתות Pod

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

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

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

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

• הקצאת כתובות 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 מתחבר למרחב השמות של רשת הבסיס (root) של הצומת. כתובות ה-IP של Pods הן כתובות IP חלופיות שמוכרות לרשת ה-VPC, ולכן ניתוב רגיל של Linux בצומת מפנה את התנועה אל ה-Pod וממנו.
  • ‫GKE Dataplane V2: משתמש בתוכניות eBPF כדי לטפל ברישות של Pod, ולעתים קרובות עוקף גשרים רגילים של לינוקס וזוגות veth כדי לנהל ישירות את זרימות המנות בתוך הליבה לביצועים טובים יותר.
  • ‫Kubenet: משמש באשכולות שאינם אשכולות המותאמים ל-VPC. הקצה השני של זוג ה-veth מתחבר למכשיר גישור של Linux שנקרא cbr0במרחב השמות הבסיסי של הצומת. הגשר הזה מנהל את התעבורה בין ה-Pods באותו צומת ומשתמש ב-NAT לתעבורה שיוצאת מהצומת.
  • Calico: כשמדיניות רשת ב-Kubernetes מופעלת באמצעות Calico, הקצה השני של זוג veth מתחבר למרחב השמות הבסיסי של הצומת, ואז Calico מתכנת מסלולי מארח כדי לנתב את התנועה אל ה-Pods הנכונים.

יחידת שידור מקסימלית (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	עבר בירושה	האפשרות הזו משמשת כשמופעלות תכונות כמו visibility של Intranode, איחוד זהויות של עומסי עבודה ל-GKE או רשתות IPv4/IPv6 dual-stack.

באשכולות שמופעלות בהם גרסאות לפני 1.26.1, הפעלה של תכונות כמו Intranode visibility,‏ איחוד זהויות של עומסי עבודה ל-GKE או IPv4/IPv6 dual-stack networking גורמת ליחידת ה-MTU של ה-Pod להיות מושפעת מהממשק הראשי של הצומת.

זרימת התקשורת בין Pod ל-Pod

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

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

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

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

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

פודים של רשת מארחת

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

Service Networking

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

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

איך פועלת רשת השירותים

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

זיהוי שירותים: כדי שאפליקציות יוכלו למצוא אחת את השנייה ולתקשר ביניהן, GKE מספק שירות DNS פנימי (או kube-dns או Cloud DNS). כשיוצרים שירות, שירות ה-DNS יוצר באופן אוטומטי רשומת DNS תואמת. הרשומה הזו מאפשרת לאפליקציות להתחבר לשירות באמצעות שם ה-DNS שלו (לדוגמה, my-app-service) במקום לדעת את ה-ClusterIP שלו. למרות ש-kube-dns היא ברירת המחדל עבור אשכולות רגילים, Cloud DNS for 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 של היעד לאחד מה-Pods התקינים של ה-backend. איזון העומסים בין ה-Pods של ה-Backend הוא בדרך כלל אקראי או מסוג 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 ובוחרים אחד מה-Pods של הבק-אנד שפועלים בצורה תקינה בשביל my-server-service (לדוגמה, Pod 2 עם כתובת ה-IP 10.4.0.3). הכללים גם משכתבים את כתובת ה-IP של היעד של המנה לכתובת ה-IP של ה-Pod.
6. החבילה מנותבת דרך רשת הפודים השטוחה לפוד 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 controller הוא ההטמעה של Google ל-Gateway API, והוא נועד להיות יורש יותר אקספרסיבי, גמיש וניתן להרחבה של משאב ה-Ingress. ב-Gateway API נעשה שימוש במשאבים הבאים כדי להגדיר את מאזן העומסים:
  • ‫Gateway: מגדיר את הגדרות המאזין, כמו יציאות, פרוטוקולים ושמות מארחים. הוא משמש כנקודת הכניסה לתעבורה.
  • ‫HTTPRoute: מציין איך תעבורת נתונים שמתקבלת על ידי Gateway מנותבת לשירותים. הוא תומך בתכונות מתקדמות כמו ניתוב מבוסס-נתיב, התאמת כותרות וחלוקת התנועה.
  • מדיניות: מגדירה את אופן הפעולה של התשתית Google Cloud הבסיסית על ידי צירוף שלה ל-Gateway, ל-Route או לשירות.
• שילוב של Service mesh. לארכיטקטורות מורכבות של מיקרו-שירותים,‏ GKE תומך בטכנולוגיות של Service mesh. ‫Service mesh היא שכבת תשתית אופציונלית שמספקת תכונות מתקדמות לניהול תעבורה, לניראות ולאבטחה. כדי ליהנות מחוויה מנוהלת ומנתמכת באופן מלא, אפשר להשתמש ב-Cloud Service Mesh, שזמין ב-GKE ומבוסס על 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.

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

ניהול תנועה יוצאת

תעבורת נתונים יוצאת היא תנועה שיוצאת מהאשכול. כדי שאשכול 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 מספקת כמה שכבות של אמצעי בקרה לאבטחה של תנועה פנימית (ממזרח למערב) וחיצונית (מצפון לדרום).

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

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

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

בדוגמה הבאה מוצג מניפסט של NetworkPolicy. המדיניות הזו חלה על Pods עם התווית app: backend ומאפשרת תעבורת נתונים נכנסת (ingress) רק מ-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 נמצאים בתוך רשת VPC ומוגנים על ידי כללי חומת אש של VPC, ששולטים בתנועה אל צומתי האשכול וממנו. Google Cloud כללי חומת האש של VPC ומדיניות הרשת ב-Kubernetes פועלים יחד כדי לספק הגנה לעומק. חומות האש של VPC פועלות ברמת הצומת (שכבה 3 או שכבה 4), והן שולטות בתעבורת הנתונים למכונות הווירטואליות עצמן. מדיניות רשת ב-Kubernetes פועלת ברמת ה-Pod (שכבה 3 או שכבה 4), ומספקת שליטה מפורטת יותר בתעבורת נתונים בין אפליקציות בתוך האשכול.

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

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

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

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

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

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

מספר CNI בהתאמה אישית

‫GKE מציע אפשרויות CNI עם תמיכה מובנית, כולל Google CNI,‏ Calico ו-GKE Dataplane V2. יכול להיות ש-CNI מותאם אישית של צד שלישי יפעל באשכול שלכם, אבל GKE לא תומך בו באופן רשמי. אם משתמשים ב-CNI בהתאמה אישית, צריך לנהל את ההגדרה שלו ולפתור בעיות פוטנציאליות.

אם מזוהה CNI מותאם אישית באשכול, GKE מספק המלצה להסרת ה-CNI כדי להבטיח תצורה נתמכת. בנוסף, לא תומכים בהתקנות מותאמות אישית של Istio בתרחישי שימוש ב-Service Mesh. במקום זאת, מומלץ להשתמש ב-Cloud Service Mesh.

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

• איך יוצרים אשכול מקורי של VPC
• מידע נוסף על GKE Dataplane V2
• הטמעת מדיניות רשת ב-Kubernetes כדי לאבטח את התקשורת בין Pods.
• התנסות בדרכים שונות לחשיפת אפליקציות באמצעות שירותים והגדרת Ingress באמצעות Gateway API.