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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פתרון: יצירת שירות Kubernetes. שירות ClusterIP מספק כתובת IP וירטואלית ושם DNS יציבים, עם איזון עומסים בין הפודים. מידע נוסף זמין במאמר הסבר על שירותי 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 בין השירותים גדל באופן משמעותי. מפתחים צריכים להבין איך לבנות אפליקציות עמידות בסביבה הזו, אבל לרוב צוותי הפלטפורמה והתפעול אחראים להטמעת פתרונות רשת שניתנים להתאמה לעומס (scaling).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תרחיש לדוגמה: בניית סביבת 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 ורשתות Tier 1.
  • שלב 4: פריסת מכשירי אבטחה מתקדמים באמצעות תמיכה בריבוי רשתות.
תרשים שמציג את הארכיטקטורה מקצה לקצה של אפליקציה מאובטחת למסחר קמעונאי עם כמה רמות ב-GKE, וממחיש את רכיבי הרשת לאורך ששת שלבי הפריסה וההתאמה לגודל.
איור 1. ארכיטקטורה מקצה לקצה של אפליקציית קמעונאות מאובטחת מרובת רמות ב-GKE, עם דגש על רכיבי הרשת העיקריים שמשמשים בכל שלב של הפריסה וההתאמה. הפרטים של כל שלב מפורטים בקטעים הבאים.

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

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

פתרון:

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

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

פתרון:

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

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

פתרון:

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

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

פתרון:

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

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

פתרון:

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

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

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

פתרון:

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