רשתות ב-Google Kubernetes Engine (GKE) כוללות מגוון רחב של מושגים, כולל Pods, שירותים, DNS, איזון עומסים, אבטחה וניהול כתובות IP. התיעוד מסביר כל תכונה בפירוט, אבל יכול להיות שיהיה לכם קשה לדעת מאיפה להתחיל כשאתם נתקלים בבעיה בעולם האמיתי.
המסמך הזה עוזר לכם להתמצא במסמכי התיעוד של רשתות GKE. הוא מקשר בין אתגרים נפוצים לבין התכונות והקטעים שבהם מוסבר איך לפתור אותם. כל תרחיש לדוגמה מציג תרחיש, מזהה את האתגר ומפנה אתכם לתיעוד הרלוונטי. המסמך הזה מיועד לארכיטקטים של ענן, למפתחים ולצוותי תפעול שצריכים להבין ולפתור בעיות נפוצות ברשת ב-GKE.
אם אתם כבר מכירים אתגרים נפוצים ברשתות ומעדיפים לעבור ישר לפרטים הטכניים, כדאי לעיין במקורות המידע הבאים כדי לבנות ידע בסיסי על רשתות GKE:
- מידע בסיסי על רשתות 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 יציבים, עם איזון עומסים בין ה-Pods. מידע נוסף זמין במאמר הסבר על שירותי Kubernetes.
אתגר: חשיפת השירות לגישה חיצונית
תרחיש: צריך שתהיה גישה למיקרו-שירות מהאינטרנט לצורך הדגמה.
הפתרון: יוצרים שירות LoadBalancer. GKE מקצה מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי עם כתובת IP גלויה. לתעבורת נתונים מסוג HTTP(S), מומלץ להשתמש ב-Ingress או ב-Gateway, שמספקים תכונות של Layer 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) שמבצע התאמת נתונים (resolve) של שמות DNS יציבים לשירותים, וכך מאפשר תקשורת אמינה בין פודים. מידע נוסף מופיע במאמר גילוי שירותים ו-DNS.
אתגר: שיפור הביצועים של DNS בקנה מידה נרחב
תרחיש: נפח גבוה של שאילתות גורם לעיכובים בחיפוש.
פתרון: מפעילים את NodeLocal DNSCache. כל צומת שומר במטמון שאילתות DNS באופן מקומי, כדי להקטין את זמן האחזור. מידע נוסף זמין במאמר סקירה כללית על הגדרת NodeLocal DNSCache.
אתגר: לספק זיהוי שירותים ברחבי ה-VPC
תרחיש: מכונות וירטואליות ב-Compute Engine צריכות לגשת לשירותים בתוך האשכול.
פתרון: משלבים עם Cloud DNS כדי שרשומות ה-DNS של השירות יפענחו בכל ה-VPC. מידע נוסף מופיע במאמר בנושא שימוש ב-Cloud DNS ל-GKE.
תרחיש לדוגמה: אבטחת אפליקציה מרובת רמות
בתרחיש השימוש הזה, אתם חברים בצוות הנדסת פלטפורמות שמבצע פריסה של אפליקציה בת 3 רמות (קצה קדמי, חיוב ומסד נתונים), ואתם צריכים לאכוף תקשורת במודל אבטחה של אפס אמון.
אתגר: אכיפת כללי תנועה מחמירים
תרחיש: רק שירותים ספציפיים צריכים לתקשר זה עם זה.
פתרון: מפעילים את האכיפה של מדיניות הרשת ומחילים מדיניות default deny, ואז מגדירים כללי הרשאה מפורשים (לדוגמה, חזית האתר מאפשרת תנועה לחיוב, החיוב מאפשר תנועה למסד הנתונים). מידע נוסף מופיע במאמר בנושא הגדרת מדיניות רשת לאפליקציות.
אתגר: ביצוע ביקורת ואימות של מדיניות הרשת
תרחיש: האבטחה מחייבת הוכחה לאכיפה ולשקיפות.
פתרון: מפעילים את הרישום ביומן של מדיניות הרשת כדי לתעד חיבורים שאושרו ונדחו. מידע נוסף זמין במאמר בנושא שימוש ברישום ביומן של מדיניות הרשת.
אתגר: חשיפת שירות באופן פרטי לצרכנים
תרחיש: שירות לקצה העורפי, כמו מסד נתונים או API, צריך להיות נגיש לצרכנים ברשתות VPC אחרות בלי לחשוף אותו לאינטרנט הציבורי או להתמודד עם מורכבויות של קישור בין רשתות שכנות (peering).
פתרון: משתמשים ב-Private Service Connect כדי לפרסם את השירות. לאחר מכן, הצרכנים יכולים ליצור נקודת קצה (endpoint) מסוג PSC ב-VPC שלהם כדי לגשת לשירות שלכם באופן פרטי ומאובטח. מידע נוסף זמין במאמר חשיפת שירותים באמצעות Private Service Connect.
תרחיש לדוגמה: השגת זמינות גבוהה בכמה אשכולות
בתרחיש השימוש הזה, אתם מהנדסי SRE שמריצים עומסי עבודה עבור חברת מסחר אלקטרוני בכמה אשכולות GKE באזורים שונים, כדי לשפר את המהימנות.
אתגר: הפעלת תקשורת בין אשכולות
תרחיש: שירותים באשכול אחד צריכים לגלות שירותים באשכול אחר ולהפעיל אותם.
פתרון: משתמשים בשירותים מרובי-אשכולות של GKE (MCS) כדי ליצור שם DNS גלובלי ולנתב תנועה באופן אוטומטי לשרתי קצה תקינים. למידע נוסף, קראו את המאמר שירותים מרובי אשכולות.
אתגר: הקפדה על מעבר גיבוי אוטומטי עמיד
תרחיש: אם שירות אזורי אחד הופך ללא זמין, התעבורה צריכה להיות מנותבת מחדש באופן אוטומטי.
פתרון: MCS מספק גילוי שירותים שמודע למצב התקינות, ומאפשר ללקוחות לפתור שם DNS יחיד לשרת קצה תקין באשכול הזמין הקרוב ביותר. הגישה הזו מאפשרת מעבר גיבוי (failover) עמיד. מידע נוסף זמין במאמר בנושא שירותים מרובי-אשכולות.
תרחיש שימוש: בניית סביבת GKE מאובטחת ויעילה עם מספר דיירים (tenants)
כחלק מצוות הנדסת פלטפורמות, אתם מספקים אשכולות GKE לכמה צוותים של אפליקציות. אתם צריכים לרכז את השליטה ברשת, לחסוך בכתובות IP ולאכוף אבטחה מחמירה.
אתגר: שליטה מרכזית על הרשת
תרחיש: כמה צוותים של אפליקציות צריכים אשכולות משלהם, אבל צריך לנהל את הרשת באופן מרכזי.
פתרון: שימוש ב-VPC משותף. משאבי הרשת נמצאים בפרויקט מארח, אבל אשכולות האפליקציות פועלים בפרויקטים של שירות. מידע נוסף זמין במאמר הגדרת אשכולות עם VPC משותף.
אתגר: ניהול יעיל של כתובות IP מוגבלות
תרחיש: מרחב כתובות ה-IP מוגבל וצריך להשתמש בו בצורה יעילה.
פתרון: משנים את המספר המקסימלי של Pods לכל צומת, ואם צריך, משתמשים בטווחים שאינם RFC 1918 לכתובות ה-IP של ה-Pods. מידע נוסף זמין במאמר בנושא ניהול העברת כתובות IP ב-GKE.
אתגר: שימוש במישור נתונים מודרני ומאובטח, והקצאת אשכולות באמצעות מישור הנתונים החדש
תרחישים:
- הארגון דורש ביצועים גבוהים ואכיפת מדיניות מובנית כדי לתמוך בעומסי עבודה תובעניים ובגישת אבטחה של אפס אמון. לדוגמה, יכול להיות שאתם מפעילים מיקרו-שירותים בקנה מידה גדול שרגישים לזמן האחזור ברשת, או שאתם צריכים לאכוף גבולות אבטחה מחמירים בין אפליקציות באשכול מרובה דיירים כדי לעמוד בדרישות התאימות לתקנות.
- צריך להגדיר את האשכולות כך שישתמשו במישור נתונים מודרני של רשת כדי להשיג ביצועים גבוהים ואבטחה, וצריך לפרוס אותם במסגרת מבנה הרשת שמנוהל באופן מרכזי בארגון.
הפתרון: משתמשים ב-GKE Dataplane V2, שמבוסס על eBPF ומספק ביצועים גבוהים ואכיפה מובנית של מדיניות הרשת. מידע נוסף זמין במאמר בנושא GKE Dataplane V2.
תרחיש שימוש: מעקב אחר תנועה ופתרון בעיות שקשורות לתנועה
בתור מהנדסי SRE, אתם בודקים למה שירות התשלומים לא מצליח להתחבר לשירות התשלומים.
אתגר: פתרון בעיות בקישוריות
תרחיש: מנות נשמטות, אבל הסיבה לא ברורה.
פתרון: מפעילים את האפשרות 'יכולת צפייה' ב-GKE Dataplane V2. מדדים כמו hubble_drop_total מאשרים שמנות נדחו. מידע נוסף זמין במאמר פתרון בעיות באמצעות Hubble.
אתגר: זיהוי שורש הבעיה של מנות שאבדו
תרחיש: אחרי שמאשרים שחבילות הרשת מושמטות (לדוגמה, באמצעות hubble_drop_total), צריך לזהות איזו מדיניות רשת ספציפית חוסמת את התנועה בין השירותים.
פתרון: משתמשים בממשק שורת הפקודה או בממשק המשתמש של Hubble כדי לעקוב אחרי זרימות. ממשק המשתמש של Hubble מספק ייצוג חזותי של התנועה, ומדגיש את המדיניות הלא מוגדרת שמונעת את החיבור. הוויזואליזציה הזו מאפשרת לצוות לזהות במהירות את שורש הבעיה ולתקן את המדיניות. מידע נוסף זמין במאמר מעקב אחרי התנועה באמצעות יכולות התצפית של GKE Dataplane V2.
תרחיש לדוגמה מקצה לקצה: פריסה והרחבה של אפליקציה מאובטחת לקמעונאות
בתרחיש מקצה לקצה הזה, צוות הנדסת פלטפורמה בונה פלטפורמת GKE סטנדרטית לכמה צוותי אפליקציות. הצוות פורס ומבצע אופטימיזציה של אפליקציית קמעונאות בשלוש שכבות (קצה קדמי, חיוב ומסד נתונים). התהליך הזה כולל אבטחה, הרחבה, שיפור הביצועים של עומסי עבודה של למידת מכונה ושילוב של מכשירי אבטחה מתקדמים.
בתרשים הבא מוצגת ארכיטקטורה מקצה לקצה של אפליקציה מאובטחת למסחר קמעונאי, עם כמה רמות, שפרוסה ב-GKE. הארכיטקטורה מתפתחת בכמה שלבים:
- שלב 1: בניית הגדרה בסיסית באמצעות VPC משותף ו-GKE Dataplane V2.
- שלב 2: חשיפת האפליקציה באמצעות Gateway API ושירותים מרובי אשכולות לזמינות גבוהה.
- שלב 3: שיפור הביצועים של משימות למידת מכונה באמצעות gVNIC ורשתות Tier 1.
- שלב 4: פריסת מכשירי אבטחה מתקדמים באמצעות תמיכה בריבוי רשתות.
שלב 1: בניית הבסיס של הפלטפורמה
אתגר: ריכוז של הרישות עבור כמה צוותים של אפליקציות והקצאה של מספיק כתובות IP כדי להתמודד עם שינויים בהיקף השימוש.
פתרון:
- שימוש ב-VPC משותף לשליטה מרכזית.
- תכנון של הקצאת כתובות IP כדי להבטיח יכולת התאמה לעומס.
- הפעלה של GKE Dataplane V2 לקבלת מישור נתונים מאובטח ועתיר ביצועים.
- אפשר להשתמש ב-Private Service Connect כדי להתחבר באופן מאובטח למישור הבקרה של GKE.
שלב 2: פריסה של האפליקציה ואבטחה שלה
אתגר: לוודא שתקשורת משירות לשירות היא אמינה ולאכוף אבטחה של אפס אמון.
פתרון:
- יוצרים שירותים מסוג ClusterIP לנקודות קצה פנימיות יציבות.
- החלת כללי מדיניות רשת עם בסיס של דחייה כברירת מחדל וכללי הרשאה מפורשים.
שלב 3: חשיפת האפליקציה והתאמה לצמיחה
אתגר: לספק גישה חיצונית ולהפחית את זמן האחזור של חיפושי DNS ככל שתעבורת הנתונים גדלה.
פתרון:
- חשיפת ממשק הקצה באמצעות Gateway API לניהול מתקדם של תעבורת נתונים.
- הקצאת כתובת IP סטטית עם DNS.
- הפעלת NodeLocal DNSCache לחיפושים מהירים יותר.
שלב 4: השגת זמינות גבוהה ופתרון בעיות
אתגר: לוודא שיש יתירות כשל אזורית, ולנפות באגים בתעבורת נתונים שהופסקה.
פתרון:
- משתמשים בשירותים מרובי אשכולות ליתירות כשל באזור אחר.
- מפעילים את היכולת של GKE Dataplane V2 לניטור באמצעות Hubble כדי לאבחן ולתקן מדיניות רשת שהוגדרה בצורה שגויה.
שלב 5: האצת עומסי עבודה של למידת מכונה
האתגר: ביטול צווארי בקבוק ברשת לאימון מודלים מבוססי-GPU.
פתרון:
- כדי ליהנות מרוחב פס גדול יותר, מומלץ להפעיל את gVNIC.
- כדי להשיג תפוקה מקסימלית, מגדירים רשת ברמה 1 בצמתים קריטיים.
שלב 6: פריסת מכשירי אבטחה מתקדמים
אתגר: פריסת חומת אש ומערכת IDS של צד שלישי עם ניהול נפרד ותנועת נתונים במישור הנתונים עם זמן אחזור נמוך במיוחד.
פתרון:
- מפעילים תמיכה בכמה רשתות כדי לצרף כמה ממשקים ל-Pods.
- מגדירים רשת במצב מכשיר (DPDK).