מידע על ניתוב ואבטחה של GKE Ingress

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

הדף הזה מבוסס על המושגים הבסיסיים שמתוארים בסקירה הכללית של GKE Ingress. הוראות מפורטות ודוגמאות להטמעה באמצעות משאבים בהתאמה אישית כמו FrontendConfig ו-BackendConfig מופיעות במאמר הגדרת תכונות של Ingress לאפליקציות GKE.

הדף הזה מיועד למומחי רשתות שמתכננים ומעצבים את הרשת של הארגון שלהם, ומתקינים, מגדירים ותומכים בציוד הרשת. כדי לקבל מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהם בCloud de Confiance by S3NS תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

אבטחת תעבורת נתונים נכנסת (Ingress) באמצעות HTTPS

‫GKE Ingress מאבטח את התנועה בין הלקוח לבין מאזן העומסים של האפליקציות, וממאזן העומסים לפודים של האפליקציה.

הגדרת TLS בין הלקוח לבין מאזן העומסים

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

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

שיטות לאספקת אישורי SSL

אפשר לספק אישורי SSL למאזן עומסים מסוג HTTP(S) באמצעות השיטות הבאות:

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

• אישורים בניהול עצמי שמשותפים עם Cloud de Confiance: אתם יכולים להקצות אישור SSL משלכם וליצור משאב אישור בפרויקט Cloud de Confiance . לאחר מכן, מפרטים את משאב האישור בהערה ב-Ingress כדי ליצור מאזן עומסים מסוג HTTP(S) שמשתמש באישור. מידע נוסף זמין במאמר בנושא שימוש באישורים ששותפו מראש.

• אישורים בניהול עצמי שמשתמשים ב-Secrets של Kubernetes: אתם יכולים להקצות אישור SSL משלכם וליצור Secret כדי לשמור אותו. לאחר מכן, תוכלו להפנות לסוד בשדה tls של מניפסט Ingress כדי ליצור מאזן עומסים מסוג HTTP(S). מידע נוסף זמין במאמר שימוש בסודות של Kubernetes.

הצגת תנועת HTTPS עם כמה אישורים

אפשר להגדיר את Application Load Balancer כך שיציג ללקוח עד 15 אישורי TLS. שימוש בכמה אישורים חיוני כשצריך להציג תוכן מכמה שמות מארחים, שכל אחד מהם דורש אישור שונה (לדוגמה, אישורים נפרדים ל-your-store.example ול-your-experimental-store.example). מציינים את האישורים המרובים האלה במניפסט של Ingress.

בחירת אישורים ועדיפות

כדי לקבוע איזה אישור להציג ללקוח, מאזן העומסים משתמש ב-Server Name Indication‏ (SNI).

• אם הלקוח משתמש ב-SNI או בשם דומיין שתואם לשם הנפוץ (CN) באחד מהאישורים הזמינים, מאזן העומסים משתמש באישור שהשם הנפוץ שלו הוא ההתאמה הכי קרובה לשם המארח שהלקוח ביקש.

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

  • לגבי סודות שמופיעים בבלוק tls: האישור הראשי הוא הסוד הראשון בבלוק tls.
  • לאישורים ששותפו מראש בהערה pre-shared-cert: האישור הראשי הוא האישור הראשון שמופיע בהערה.
  • לאישורים שמנוהלים על ידי Google בהערה managed-certificates: כל האישורים המנוהלים ממוינים לפי סדר אלפביתי של השמות. האישור הראשי הוא האישור הראשון שמופיע ברשימה האלפביתית הזו. כדי להגדיר אישור ספציפי כאישור הראשי, צריך לתת שמות לאובייקטים של ManagedCertificate בהתאם כדי לשלוט בסדר המיון. לדוגמה, כדי להגדיר את my-default-cert כראשי במקום another-cert, אפשר לתת להם את השמות 0-my-default-cert ו-1-another-cert.

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

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

שיטות מומלצות לרוטציית אישורים

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

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

כדי להימנע מניהול של חידוש האישורים בעצמכם, תוכלו להשתמש באישורי SSL בניהול Google.

אכיפת תנועה ב-HTTPS בלבד

אם רוצים שכל התנועה בין הלקוח לבין מאזן העומסים מסוג HTTP(S) תשתמש ב-HTTPS, אפשר להשבית את ה-HTTP על ידי הכללת ההערה kubernetes.io/ingress.allow-http במניפסט של Ingress והגדרת הערך ל-"false". מידע נוסף זמין במאמר השבתת HTTP.

הגדרת הצפנה בין מאזן העומסים לבין האפליקציה

בקטע הזה מוסבר איך לאבטח את החיבור בין מאזן העומסים לבין ה-Pods של האפליקציה.

הפעלת פרוטוקול בק-אנד של HTTPS או HTTP/2

מאזן העומסים החיצוני של אפליקציות (ALB) פועל כשרת proxy בין הלקוחות לבין אפליקציית GKE. למרות שהלקוחות יכולים להתחבר למאזן העומסים באמצעות HTTPS (להצפנה) ופרוטוקולים שונים (HTTP/1.1 או HTTP/2), החיבור ממאזן העומסים ל-Pods של הבק-אנד מוגדר כברירת מחדל ל-HTTP/1.1 לא מוצפן.

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

• ‫HTTP/2: כדי לשפר את הביצועים אם ה-Pods תומכים בזה.
• ‫HTTPS‏ (TLS): כדי לאכוף הצפנה מקצה לקצה של תעבורת נתונים בין שרת ה-proxy של מאזן העומסים לבין ה-Pods.

אתם יכולים לשלוט בפרוטוקול (HTTP או HTTPS) ובגרסת ה-HTTP ‏ (HTTP/1.1 או HTTP/2) שמשמשים לחיבור לקצה העורפי באמצעות ההערה cloud.google.com/app-protocols במניפסט של שירות Kubernetes. המניפסט של השירות הזה חייב לכלול את type: NodePort, אלא אם אתם משתמשים באיזון עומסים מובנה בקונטיינר. אם אתם משתמשים באיזון עומסים שמקורם בקונטיינר, השתמשו ב-type: ClusterIP.

כתובות IP סטטיות למאזני עומסים מסוג HTTPS

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

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

ניתוב תנועה

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

כמה שירותים לקצה העורפי

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

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

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

באשכול GKE, יוצרים ומגדירים מאזן עומסים מסוג HTTP(S) באמצעות יצירת אובייקט Ingress של Kubernetes. אובייקט Ingress חייב להיות משויך לאובייקט שירות אחד או יותר, שכל אחד מהם משויך לקבוצת Pods.

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

זוהי מניפסט של Ingress בשם my-ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
 rules:
  - host: your-store.example
    http:
      paths:
      - path: /products
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

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

בדוגמה הקודמת, נניח ששייכתם את כתובת ה-IP של מאזן העומסים לשם הדומיין your-store.example. כשלקוח שולח בקשה ל-your-store.example/products, הבקשה מנותבת לשירות Kubernetes בשם my-products ביציאה 60000. כשלקוח שולח בקשה ל-your-store.example/discounted, הבקשה מנותבת לשירות Kubernetes בשם my-discounted-products ביציאה 80.

התו הכללי היחיד לחיפוש שנתמך בשדה path של Ingress הוא התו *. התו * חייב להופיע אחרי קו נטוי (/) ולהיות התו האחרון בתבנית. לדוגמה, /*, /foo/* ו-/foo/bar/* הן תבניות תקינות, אבל *, /foo/bar* ו-/foo/*/bar לא תקינות.

תבנית ספציפית יותר מקבלת עדיפות על פני תבנית פחות ספציפית. אם יש לכם גם /foo/* וגם /foo/bar/*, המערכת תשתמש ב-/foo/bar/bat כדי להתאים ל-/foo/bar/*.

מידע נוסף על מגבלות הנתיב והתאמת התבניות זמין במסמכי התיעוד בנושא מפות URL.

קובץ המניפסט של שירות my-products עשוי להיראות כך:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

שימו לב לפרטים הבאים במניפסט שלמעלה:

• השדה spec.type תלוי בשיטה שבה אתם משתמשים לאיזון עומסים:

  • אם אתם משתמשים באיזון עומסים שמקורם בקונטיינר, אתם צריכים להשתמש ב-type: ClusterIP.
  • אם אתם משתמשים בקבוצות של מכונות, השתמשו ב-type: NodePort.

• השדה selector מציין שכל Pod שיש לו גם את התווית app: products וגם את התווית department: sales הוא חבר בשירות הזה.

• כשמגיעה בקשה לשירות ביציאה 60000, היא מנותבת לאחד מה-Pods החברים ביציאת TCP‏ 50000.

• לכל פוד של חבר צריך להיות קונטיינר שמקשיב ליציאת TCP מספר 50000.

קובץ המניפסט של שירות my-discounted-products עשוי להיראות כך:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

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

• השדה selector מציין שכל Pod שיש לו גם את התווית app: discounted-products וגם את התווית department: sales הוא חבר בשירות הזה.

• כשבקשה מגיעה לשירות ביציאה 80, היא מנותבת לאחד מ-Pods החברים ביציאת TCP‏ 8080.

• לכל Pod חבר צריך להיות קונטיינר שמאזין ליציאת TCP‏ 8080.

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

אתם יכולים לציין קצה עורפי (backend) שמוגדר כברירת מחדל ל-Ingress על ידי הוספת השדה spec.defaultBackend למניפסט של ה-Ingress. הוא יטפל בכל הבקשות שלא תואמות לנתיבים שהוגדרו בשדה rules. לדוגמה, ב-Ingress הבא, כל הבקשות שלא תואמות ל-/discounted נשלחות לשירות בשם my-products ביציאה 60001.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  defaultBackend:
    service:
      name: my-products
      port:
        number: 60001
  rules:
  - http:
      paths:
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

אם לא מציינים קצה עורפי שמוגדר כברירת מחדל, GKE מספק קצה עורפי שמוגדר כברירת מחדל ומחזיר 404. הוא נוצר כשירות default-http-backend NodePort באשכול במרחב השמות kube-system.

תגובת ה-HTTP‏ 404 דומה לזו:

response 404 (backend NotFound), service rules for the path non-existent

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

בדיקות תקינות

כשחושפים שירות אחד או יותר דרך Ingress באמצעות בקר ברירת המחדל של Ingress, ‏ GKE יוצר מאזן עומסים קלאסי של אפליקציות או מאזן עומסים פנימי של אפליקציות. שני מאזני העומסים האלה תומכים בכמה שירותי לקצה העורפי במפת URL יחידה. כל אחד מהשירותים לקצה העורפי תואם לשירות Kubernetes, וכל שירות לקצה העורפי צריך להפנות לCloud de Confiance בדיקת תקינות. בדיקת התקינות הזו שונה מבדיקת תקינות או מוכנות של Kubernetes, כי היא מיושמת מחוץ לאשכול.

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

‫GKE יוצר בדיקות תקינות על סמך אחת מהשיטות הבאות:

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

‫GKE משתמש בהליך הבא כדי ליצור בדיקת תקינות לכל שירות לקצה העורפי שמתאים לשירות Kubernetes:

• אם השירות מפנה ל-CRD של BackendConfig עם מידע על healthCheck, ‏GKE משתמש בו כדי ליצור את בדיקת התקינות. אפשר ליצור בדיקות תקינות בדרך הזו גם בבקר ה-Ingress של GKE Enterprise וגם בבקר ה-Ingress של GKE.

• אם השירות לא מפנה ל-CRD של BackendConfig:

  • ‫GKE יכול להסיק חלק מהפרמטרים של בדיקת תקינות או את כולם, אם ה-Pods המשרתים משתמשים בתבנית Pod עם קונטיינר שבדיקת המוכנות שלו כוללת מאפיינים שאפשר לפרש כפרמטרים של בדיקת תקינות. במאמר פרמטרים מתוך בדיקת מוכנות מפורטים פרטי ההטמעה, ובמאמר פרמטרים שמוגדרים כברירת מחדל ופרמטרים שמוסקים מופיעה רשימה של מאפיינים שאפשר להשתמש בהם כדי ליצור פרמטרים של בדיקת תקינות. רק בקר ה-Ingress של GKE תומך בהסקת פרמטרים מבדיקת מוכנות.

  • אם בתבנית ה-Pod של ה-Pods להצגת מודעות של השירות אין מאגר עם בדיקת מוכנות שאפשר לפרש את המאפיינים שלה כפרמטרים של בדיקת תקינות, המערכת משתמשת בערכי ברירת המחדל כדי ליצור את בדיקת התקינות. גם בקר ה-Ingress של GKE Enterprise וגם בקר ה-Ingress של GKE יכולים ליצור בדיקת תקינות באמצעות ערכי ברירת המחדל בלבד.

פרמטרים שמוגדרים כברירת מחדל ופרמטרים שמוסקים

הפרמטרים הבאים משמשים כשלא מציינים פרמטרים של בדיקת תקינות לשירות המתאים באמצעות CRD BackendConfig.

פרמטרים מבדיקת מוכנות

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

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

אם ה-Pods שלכם להצגת שירות מכילים כמה קונטיינרים, או אם אתם משתמשים בבקר GKE Enterprise Ingress, אתם צריכים להשתמש ב-BackendConfigCRD כדי להגדיר פרמטרים של בדיקת תקינות. מידע נוסף זמין במאמר מתי כדאי להשתמש ב-CRD של BackendConfig.

מתי כדאי להשתמש ב-CRD‏ BackendConfig

במקום להסתמך על פרמטרים מבדיקות מוכנות של Pod, כדאי להגדיר במפורש פרמטרים של בדיקות תקינות לשירות לקצה העורפי על ידי יצירת BackendConfig CRD לשירות במצבים הבאים:

• אם אתם משתמשים ב-GKE Enterprise: בקר ה-Ingress של GKE Enterprise לא תומך בקבלת פרמטרים של בדיקת תקינות מבדיקות המוכנות של Pods להצגת מודעות. הוא יכול ליצור בדיקות תקינות רק באמצעות פרמטרים מרומזים או כפי שמוגדר ב-CRD‏ BackendConfig.

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

• אם אתם צריכים שליטה על היציאה שמשמשת לבדיקות התקינות של מאזן העומסים: GKE משתמש ב-containers[].readinessProbe.httpGet.port של בדיקת המוכנות לבדיקת התקינות של שירות הקצה העורפי רק כשהיציאה הזו תואמת ליציאת השירות של השירות שאליו מפנה ה-Ingress‏ spec.rules[].http.paths[].backend.servicePort.

פרמטרים מ-CRD של BackendConfig

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

בדוגמה הזו, ה-CRD‏ BackendConfig מגדיר את פרוטוקול בדיקת התקינות (type), נתיב בקשה, יציאה ומרווח בדיקה במאפיין spec.healthCheck:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

כדי להגדיר את כל השדות שזמינים כשמגדירים בדיקת תקינות של BackendConfig, משתמשים בדוגמה של הגדרה מותאמת אישית של בדיקת תקינות.

כדי להגדיר GKE Ingress עם בדיקת תקינות HTTP בהתאמה אישית, קראו את המאמר GKE Ingress עם בדיקת תקינות HTTP בהתאמה אישית.

מוכנות של Pod

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

ב-Pods הרלוונטיים, בקר ה-Ingress התואם מנהל שער מוכנות מסוג cloud.google.com/load-balancer-neg-ready. בקר ה-Ingress דוגם את סטטוס בדיקת התקינות של מאזן העומסים, שכולל את התקינות של כל נקודות הקצה ב-NEG. כשסטטוס בדיקת תקינות של מאזן העומסים מציין שנקודת הקצה שמתאימה ל-Pod מסוים תקינה, בקר ה-Ingress מגדיר את ערך שער המוכנות של ה-Pod ל-True. לאחר מכן, ה-kubelet שפועל בכל צומת מחשב את המוכנות בפועל של ה-Pod, תוך התחשבות בערך של שער המוכנות הזה, ואם הוגדר, גם בבדיקת המוכנות של ה-Pod.

שערי מוכנות של Pod מופעלים אוטומטית כשמשתמשים באיזון עומסים מקורי של קונטיינרים דרך Ingress.

שערי מוכנות שולטים בקצב של עדכון מתגלגל. כשמתחילים עדכון בהדרגה (rolling), מערכת GKE יוצרת Podים חדשים, ונקודת קצה לכל Pod חדש מתווספת ל-NEG. כשהסטטוס של נקודת הקצה תקין מבחינת מאזן העומסים, בקר ה-Ingress מגדיר את שער המוכנות כ-True. ‫Pod שנוצר לאחרונה חייב לעבור את שער המוכנות שלו לפני ש-GKE מסיר Pod ישן. כך אפשר לוודא שנקודת הקצה המתאימה של ה-Pod כבר עברה את בדיקת התקינות של מאזן העומסים, ושהקיבולת של ה-Backend נשמרת.

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

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

מערכת GKE מגדירה את הערך של cloud.google.com/load-balancer-neg-ready עבור Pod ל-True אם מתקיים אחד מהתנאים הבאים:

• אף אחת מכתובות ה-IP של ה-Pod לא משמשת כנקודת קצה ב-GCE_VM_IP_PORT NEG שמנוהלת על ידי מישור הבקרה של GKE.
• כתובת IP אחת או יותר של ה-Pod הן נקודות קצה ב-GCE_VM_IP_PORTNEG שמנוהל על ידי מישור הבקרה של GKE. ה-NEG מצורף לשירות קצה עורפי. שירות הקצה העורפי עבר בהצלחה בדיקת תקינות של מאזן העומסים.
• אחת או יותר מכתובות ה-IP של ה-Pod הן נקודות קצה ב-NEG של GCE_VM_IP_PORT שמנוהל על ידי מישור הבקרה של GKE. ה-NEG מצורף לשירות קצה עורפי. בדיקת התקינות של מאזן העומסים בשירות הקצה העורפי פג הזמן הקצוב לתפוגה.
• כתובת IP אחת או יותר של ה-Pod הן נקודות קצה ב-NEG אחד או יותר של GCE_VM_IP_PORT. אף אחת מקבוצות ה-NEG לא מצורפת לשירות בקצה העורפי. אין נתונים זמינים לגבי בדיקת התקינות של מאזן העומסים.

תמיכה ב-WebSocket

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

אם אתם מתכוונים להשתמש בפרוטוקול WebSocket, כדאי להגדיר ערך של זמן קצוב לתפוגה שגדול מ-30 שניות (ברירת המחדל). בתנועת WebSocket שנשלחת דרךCloud de Confiance מאזן עומסים חיצוני של אפליקציות (ALB), הזמן הקצוב לתפוגה של השירות לקצה העורפי מפורש כמשך הזמן המקסימלי שחיבור WebSocket יכול להישאר פתוח, לא משנה אם הוא פעיל או לא פעיל.

כדי להגדיר את ערך הזמן הקצוב לתפוגה של שירות backend, אפשר לעיין במאמר בנושא זמן קצוב לתפוגה של תגובת backend.

תרחישים מתקדמים של הגדרות רשת

‫GKE Ingress תומך בהגדרות רשת מתקדמות, כמו שיתוף משאבי רשת בין פרויקטים ושימוש בבקרי Ingress בהתאמה אישית.

VPC משותף

יש תמיכה במשאבי Ingress ו-MultiClusterIngress ב-VPC משותף, אבל נדרשת הכנה נוספת.

בקר ה-Ingress פועל במישור הבקרה של GKE ומבצע קריאות ל-API אל Cloud de Confiance by S3NS באמצעות חשבון השירות של GKE בפרויקט של האשכול. כברירת מחדל, כשמשתמשים ברשת VPC משותפת עבור אשכול שנמצא בפרויקט שירות של VPC משותף, בקר התעבורה הנכנסת (ingress) לא יכול להשתמש בחשבון השירות של GKE בפרויקט השירות כדי ליצור ולעדכן כללי חומת אש שמאפשרים תעבורה נכנסת בפרויקט המארח.

אתם יכולים לתת לחשבון השירות של GKE בפרויקט השירות הרשאות ליצור ולנהל כללי חומת אש של VPC בפרויקט המארח. כשמעניקים את ההרשאות האלה, GKE יוצר כללי חומת אש של תעבורת Ingress עבור:

• מערכות לבדיקת תקינות ושרתי proxy של ממשק הקצה של Google‏ (GFE) שמשמשים מאזני עומסים חיצוניים של אפליקציות (ALB) לכניסה חיצונית. מידע נוסף זמין במאמר סקירה כללית על מאזן עומסים חיצוני של אפליקציות.

• מערכות לבדיקת תקינות של מאזני עומסים פנימיים של אפליקציות (ALB) שמשמשים את Ingress הפנימי.

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

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

כדי להקצות כלל באופן ידני:

1. צפייה באירוע של משאב Ingress:

   kubectl describe ingress INGRESS_NAME
   

   מחליפים את INGRESS_NAME בשם של Ingress.

   הפלט אמור להיראות כמו בדוגמה הבאה:

   Events:
   Type    Reason  Age                    From                     Message
   ----    ------  ----                   ----                     -------
   Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`
   

   ההצעה לכלל חומת האש הנדרש מופיעה בעמודה Message.

2. מעתיקים את הכללים המוצעים לחומת האש מפרויקט המארח ומחילים אותם. החלת הכלל מספקת גישה ל-Pods ממאזן העומסים ומבודקי התקינותCloud de Confiance .

מתן הרשאה לבקר ה-Ingress לנהל את כללי חומת האש של הפרויקט המארח

אם אתם רוצים שאשכול GKE בפרויקט שירות ייצור וינהל את משאבי חומת האש בפרויקט המארח, צריך להעניק לחשבון השירות של GKE בפרויקט השירות את הרשאות ה-IAM המתאימות, באמצעות אחת מהשיטות הבאות:

• מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד אדמין אבטחה ב-Compute בפרויקט המארח. הדוגמה הבאה ממחישה את השיטה הזו.

• כדי להגדיר הרשאות באופן מפורט יותר, צרו תפקיד IAM בהתאמה אישית שכולל רק את ההרשאות הבאות: compute.networks.updatePolicy,‏ compute.firewalls.list,‏ compute.firewalls.get,‏ compute.firewalls.create,‏ compute.firewalls.update,‏ compute.firewalls.delete ו-compute.subnetworks.list. מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד המותאם אישית הזה בפרויקט המארח.

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

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

מחליפים את מה שכתוב בשדות הבאים:

• ‫HOST_PROJECT_ID: מזהה הפרויקט של הפרויקט המארח של ה-VPC המשותף.
• ‫SERVICE_PROJECT_NUMBER: מספר הפרויקט של פרויקט השירות שמכיל את האשכול.

שימוש בבקר Ingress בהתאמה אישית

אפשר להפעיל בקר Ingress בהתאמה אישית על ידי השבתת התוסף HttpLoadBalancing. כך נמנעת האפשרות של בקר GKE Ingress לעבד משאבי Ingress.

אם רוצים להפעיל בקר Ingress בהתאמה אישית עם התוסף HttpLoadBalancing מופעל, למשל כדי להשתמש בתכונות כמו subsetting ו-Private Service Connect, אפשר להשתמש באחת מהגישות הבאות:

• במניפסט של Ingress, מגדירים את ההערה kubernetes.io/ingress.class. ההגדרה הזו נתמכת באשכולות שמריצים את כל גרסאות GKE.
• מגדירים את השדה ingressClassName.
• הגדרת מחלקת Ingress שמוגדרת כברירת מחדל.

חשוב לוודא שאף תהליך לא מחליף בטעות את spec.ingressClassName. פעולת עדכון שמשנה את spec.IngressClassName מערך תקין למחרוזת ריקה ("") גורמת לבקר GKE Ingress לעבד את ה-Ingress.

הגדרת השדה ingressClassName

אפשר להשתמש בבקר Ingress בהתאמה אישית על ידי הגדרת השדה ingressClassName במניפסט של Ingress. במניפסט הבא מתואר Ingress שבו מצוין cilium בקר Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

הגדרת סוג Ingress שמוגדר כברירת מחדל

כדי להגדיר מחלקת Ingress כברירת מחדל לכל משאבי ה-Ingress באשכול, יוצרים משאב IngressClass עם ההערה ingressclass.kubernetes.io/is-default-class שמוגדרת ל-true:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

סיכום של התנהגות בקר GKE Ingress

באשכולות שפועלות בהם גרסאות GKE 1.18 ואילך, העיבוד של Ingress על ידי בקר GKE Ingress תלוי בערך של ההערה kubernetes.io/ingress.class ובשדה ingressClassName במניפסט של Ingress. מידע נוסף זמין במאמר בנושא התנהגות של בקר GKE Ingress.

תבניות להגדרת Ingress

• במאמר GKE Networking Recipes, בקטע Ingress, תוכלו למצוא תבניות ש-GKE מספק לשימושים נפוצים רבים ב-Ingress.