עיון במאמרי עזרה ובדוגמאות לתרחישי שימוש ברשתות GKE

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

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

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

תרחיש לדוגמה: תכנון הבסיס של הרשת ב-GKE

בתרחיש השימוש הזה, אתם Cloud Architect שצריכים לתכנן תשתית רשת ניתנת להרחבה, מאובטחת ואמינה לפלטפורמת GKE חדשה.

אתגר: מניעת מיצוי של כתובות IP

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

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

אתגר: אכיפת אבטחה מקיפה

תרחיש: אתם צריכים לאבטח את גבולות האשכול ולאכוף כללי Pod-to-Pod של אפס אמון.

הפתרון: משתמשים במדיניות חומת אש להיקפי אשכולות. מידע נוסף זמין במאמר בנושא שליטה בתקשורת בין Pods לבין Services באמצעות מדיניות רשת.

אתגר: ניתוב תנועה לסוגים שונים של אפליקציות

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

הפתרון: משתמשים במאזני עומסים פנימיים עבור קצה עורפי פרטי. לאפליקציות (HTTP(S ציבוריות, משתמשים ב-Ingress או ב-Gateway API. מידע נוסף זמין במאמר מידע על איזון עומסים ב-GKE.

אתגר: שימוש בכלים לתצפית כדי לעקוב אחרי בעיות בעומסי עבודה ולפתור אותן

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

הפתרון: מטמיעים כלי ניטור כדי לעקוב אחרי התנועה ברשת ולפתור בעיות שקשורות אליה. מידע נוסף זמין במאמר מעקב אחרי התנועה באמצעות ניטור של GKE Dataplane V2.

תרחיש לדוגמה: חשיפת מיקרו-שירות חדש

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

אתגר: לספק נקודת קצה יציבה לתקשורת בין פודים

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

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

אתגר: חשיפת השירות לגישה חיצונית

תרחיש: צריך להיות אפשר להגיע למיקרו-שירות מהאינטרנט לצורך הדגמה.

פתרון: יוצרים שירות LoadBalancer. ‫GKE מקצה מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי עם כתובת IP ציבורית. לתנועת נתונים מסוג HTTP(S), מומלץ להשתמש ב-Ingress או ב-Gateway, שמספקים תכונות של שכבה 7. מידע נוסף זמין במאמר מידע על שירותי LoadBalancer.

האתגר: הקצאת כתובת URL קבועה וידידותית למשתמש

תרחיש: השירות צריך שם דומיין יציב ללקוחות.

הפתרון: שמירת כתובת IP סטטית והגדרת DNS לדומיין מותאם אישית. מידע נוסף זמין במאמר בנושא הגדרת שמות דומיין עם כתובות IP סטטיות.

אתגר: ניהול מתקדם של ניתוב תנועה

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

  • כדי לחסוך בעלויות, אפשר לארח כמה אתרים (כמו api.example.com ו-shop.example.com) במאזן עומסים יחיד.
  • הפניית בקשות לשירותים שונים על סמך נתיב כתובת ה-URL (לדוגמה, שליחת / לעומס העבודה של חזית האפליקציה ושליחת /api/v1 לעומס העבודה של הקצה העורפי).
  • כדי לאבטח את האפליקציה באמצעות HTTPS, צריך לנהל אישורי TLS.
  • אפשר לפרוס תכונות חדשות בשלבים בצורה בטוחה באמצעות גרסאות איטרטיביות לקהל מצומצם (canary release), שבהן שולחים חלק קטן מהתנועה לגרסה חדשה לפני פריסה מלאה.

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

תרחיש לדוגמה: התאמה לעומס של זיהוי שירותים באפליקציה שגדלה

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

אתגר: הפעלת תקשורת שירות לשירות

תרחיש: ל-Pods צריך להיות דרך אמינה לאתר שירותים אחרים.

פתרון:‏ GKE מספק שירות DNS בתוך האשכול (כמו kube-dns או Cloud DNS) שמבצע רזולוציה של שמות DNS יציבים עבור שירותים, וכך מאפשר תקשורת אמינה בין פודים. מידע נוסף מופיע במאמר גילוי שירותים ו-DNS.

אתגר: שיפור הביצועים של DNS בקנה מידה נרחב

תרחיש: נפח גבוה של שאילתות גורם לעיכובים בחיפוש.

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

אתגר: לספק זיהוי שירותים בכל ה-VPC

תרחיש: מכונות וירטואליות של Compute Engine צריכות לגשת לשירותים בתוך האשכול.

הפתרון: שילוב עם Cloud DNS כדי שרשומות ה-DNS של השירות יתאימו לכל ה-VPC. מידע נוסף מופיע במאמר בנושא שימוש ב-Cloud DNS ל-GKE.

תרחיש לדוגמה: אבטחת אפליקציה בכמה שכבות

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

אתגר: אכיפת כללי תנועה מחמירים

תרחיש: רק שירותים ספציפיים צריכים לתקשר ביניהם.

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

אתגר: ביקורת ואימות של מדיניות רשת ב-Kubernetes

תרחיש: נדרשת הוכחה לאכיפה ולשקיפות של האבטחה.

פתרון: מפעילים את הרישום ביומן של מדיניות רשת ב-Kubernetes כדי לתעד חיבורים שאושרו ונדחו. מידע נוסף זמין במאמר בנושא שימוש ברישום ביומן של מדיניות רשת ב-Kubernetes.

אתגר: חשיפת שירות באופן פרטי לצרכנים

תרחיש: שירות בקצה העורפי, כמו מסד נתונים או API, צריך להיות נגיש לצרכנים ברשתות VPC אחרות בלי לחשוף אותו לאינטרנט הציבורי או להתמודד עם מורכבויות של קישור (peering) בין רשתות VPC שכנות.

פתרון: משתמשים ב-Private Service Connect כדי לפרסם את השירות. לאחר מכן, הצרכנים יכולים ליצור נקודת קצה של PSC ב-VPC שלהם כדי לגשת לשירות שלכם באופן פרטי ומאובטח. מידע נוסף זמין במאמר חשיפת שירותים באמצעות Private Service Connect.

תרחיש לדוגמה: השגת זמינות גבוהה בכמה אשכולות

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

אתגר: הפעלת תקשורת בין אשכולות

תרחיש: שירותים באשכול אחד צריכים לגלות שירותים באשכול אחר ולהפעיל אותם.

הפתרון: משתמשים בשירותים מרובי-אשכולות (MCS) של GKE כדי ליצור שם DNS גלובלי ולנתב את התנועה באופן אוטומטי לקצוות עורפיים תקינים. למידע נוסף, קראו את המאמר שירותים בכמה אשכולות.

אתגר: איך לוודא מעבר גיבוי אוטומטי עמיד

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

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

תרחיש לדוגמה: בניית סביבת GKE מאובטחת ויעילה עם כמה דיירים

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

אתגר: שליטה מרכזית על הרשת

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

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

אתגר: ניהול יעיל של כתובות IP מוגבלות

תרחיש: מרחב כתובות ה-IP מוגבל וצריך להשתמש בו ביעילות.

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

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

תרחישים:

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

פתרון: אפשר להשתמש ב-GKE Dataplane V2, שמבוסס על eBPF ומספק ביצועים גבוהים ואכיפה מובנית של מדיניות רשת ב-Kubernetes. מידע נוסף זמין במאמר בנושא GKE Dataplane V2.

תרחיש לדוגמה: מעקב אחרי תנועה ופתרון בעיות

אתם מהנדסי אמינות אתר (SRE) ואתם בודקים למה שירות תשלום בקופה לא מצליח להתחבר לשירות תשלומים.

אתגר: פתרון בעיות בקישוריות

תרחיש: מנות נשמטות, אבל הסיבה לא ברורה.

הפתרון: מפעילים את יכולת הצפייה של GKE Dataplane V2. מדדים כמו hubble_drop_total מאשרים שהמנות נדחו. מידע נוסף זמין במאמר פתרון בעיות באמצעות Hubble.

אתגר: זיהוי שורש הבעיה של מנות שנשמטו

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

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

תרחיש לדוגמה מקצה לקצה: פריסה והרחבה של אפליקציה מאובטחת לקמעונאות

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

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

  • שלב 1: בניית הגדרה בסיסית באמצעות VPC משותף ו-GKE Dataplane V2.
  • שלב 2: חשיפת האפליקציה באמצעות Gateway API ושירותים בכמה אשכולות לזמינות גבוהה.
  • שלב 3: האצת משימות למידת מכונה באמצעות gVNIC ורשתות ברמה 1.
  • שלב 4: פריסת מכשירי אבטחה מתקדמים באמצעות תמיכה בריבוי רשתות.
דיאגרמה שמציגה את הארכיטקטורה מקצה לקצה של אפליקציה מאובטחת לקמעונאות בכמה שכבות ב-GKE, וממחישה את רכיבי הרישות ב-6 שלבים של פריסה והתאמה לעומס.
תרשים 1. ארכיטקטורה מקצה לקצה של אפליקציית קמעונאות מאובטחת ורב-שכבתית ב-GKE, עם דגש על רכיבי הרשת העיקריים שמשמשים בכל שלב של הפריסה וההתאמה. הפרטים של כל שלב מתוארים בקטעים הבאים.

שלב 1: בניית הבסיס של הפלטפורמה

האתגר: ריכוז הרשתות של כמה צוותי אפליקציות והקצאת מספיק כתובות IP כדי להתמודד עם התאמה לעומס.

פתרון:

שלב 2: פריסת האפליקציה ואבטחה שלה

האתגר: לוודא שתקשורת משירות לשירות היא אמינה, ולאכוף אבטחה במודל של אפס אמון.

פתרון:

שלב 3: חשיפת האפליקציה והרחבתה לצורך צמיחה

האתגר: לספק גישה חיצונית ולהפחית את זמן האחזור של חיפושי DNS ככל שהתנועה גדלה.

פתרון:

שלב 4: השגת זמינות גבוהה ופתרון בעיות

אתגר: לוודא שיש יתירות כשל אזורית, ולנפות באגים בתעבורת נתונים שהופסקה.

פתרון:

שלב 5: האצת עומסי עבודה של למידת מכונה

האתגר: ביטול צווארי בקבוק ברשת לאימון מודלים מבוסס-GPU.

פתרון:

  • כדי לקבל רוחב פס גדול יותר, צריך להפעיל את gVNIC.
  • מגדירים רשת ברמה 1 בצמתים קריטיים כדי להשיג תפוקה מקסימלית.

שלב 6: פריסת מכשירי אבטחה מתקדמים

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

הפתרון:

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