Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

אבטחת Ingress באמצעות HTTPS

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

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

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

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

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

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

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

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

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

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

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

אם הלקוח משתמש ב-SNI או בשם דומיין שתואם לשם הנפוץ (CN) באחד מהאישורים הזמינים, מאזן העומסים משתמש באישור שהשם הנפוץ שלו הוא ההתאמה הקרובה ביותר לשם המארח שהלקוח מבקש.
אם הלקוח לא תומך ב-SNI, או אם שם הדומיין המבוקש לא תואם ל-CN של אף אישור זמין, מאזן העומסים משתמש באישור הראשון שמופיע במניפסט של Ingress כברירת מחדל. מאזן העומסים בוחר את האישור הזה לפי הכללים הבאים:
- עבור Secrets המפורטים בקטע tls: האישור הראשי הוא ה-Secret הראשון בקטע tls.
- במקרה של אישורים ששותפו מראש בהערה pre-shared-cert: האישור הראשי הוא האישור הראשון שמופיע בהערה.
- בביאור managed-certificates של אישורים שמנוהלים על ידי Google: כל האישורים שמנוהלים על ידי Google ממוינים בסדר אלפביתי לפי שם. האישור הראשי הוא האישור הראשון ברשימה האלפביתית הזו. כדי להגדיר אישור ספציפי כאישור הראשי, צריך לתת לשמות של אובייקטים ManagedCertificate בהתאם כדי לשלוט בסדר המיון. לדוגמה, כדי להגדיר את my-default-cert כראשי במקום another-cert, אפשר לתת להם את השמות 0-my-default-cert ו-1-another-cert.

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

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

אישורי SSL מרובים עם דיאגרמת מערכת Ingress

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

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

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

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

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

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

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

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

הפעלת פרוטוקול בק-אנד של 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 Service. המניפסט של השירות הזה צריך לכלול את type: NodePort, אלא אם אתם משתמשים באיזון עומסים מובנה בקונטיינר. אם משתמשים באיזון עומסים שמקורם בקונטיינר, צריך להשתמש ב-type: ClusterIP.

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

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

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

ניתוב תנועה

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

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

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

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

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

באשכול GKE, יוצרים ומגדירים מאזן עומסים ב-HTTP(S) על ידי יצירת אובייקט Kubernetes Ingress. אובייקט Ingress צריך להיות משויך לאובייקט Service אחד או יותר, שכל אחד מהם משויך לקבוצת 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) או מאזן עומסים פנימי של אפליקציות (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.
לכל Pod של חבר צריך להיות מאגר שמקשיב ליציאת 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-backendNodePort באשכול במרחב השמות kube-system.

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

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

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

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

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

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

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

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

שיטה מומלצת:

כדי לקבל את השליטה המקסימלית על הגדרות בדיקת התקינות של מאזן העומסים, כדאי להשתמש ב-BackendConfig CRD.

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

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

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

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

פרמטר של בדיקת תקינות	ערך ברירת המחדל	ערך שאפשר להסיק
פרוטוקול	HTTP	אם הוא מופיע בהערה של השירות `cloud.google.com/app-protocols`
נתיב הבקשה	`/`	אם הוא מופיע ב-Pod של השרת `spec`: `containers[].readinessProbe.httpGet.path`
כותרת בקשה של מארח	`Host: backend-ip-address`	אם הוא מופיע ב-Pod של השרת `spec`: `containers[].readinessProbe.httpGet.httpHeaders`
התשובה הצפויה	‫HTTP 200 (OK)	אי אפשר לשנות את קוד הסטטוס HTTP 200 (OK)
Check interval	לאיזון עומסים שמקורם בקונטיינר: 15 שניות לקבוצות של מכונות: 60 שניות	אם הוא קיים ב-Pod של השרת `spec`: לאיזון עומסים שמקורם בקונטיינר: `containers[].readinessProbe.periodSeconds` לדוגמה, לקבוצות של מופעים: `containers[].readinessProbe.periodSeconds + 60 seconds`
Check timeout	‫5 שניות	אם הוא מופיע ב-Pod של השרת `spec`: `containers[].readinessProbe.timeoutSeconds`
הסף לסטטוס תקין	1	‫1 לא ניתן לשינוי
סף לא בריא	לאיזון עומסים שמקורם בקונטיינר: 2 לקבוצות של מכונות: 10	זהה לברירת המחדל: לאיזון עומסים שמקורם בקונטיינר: 2 לקבוצות של מכונות: 10
מפרט היציאה	באיזון עומסים שמקורם בקונטיינר: `port` של השירות לדוגמה, לקבוצות של מכונות וירטואליות: השירות `nodePort`	בדיקות התקינות נשלחות למספר היציאה שצוין על ידי התג `spec.containers[].readinessProbe.httpGet.port`, בתנאי שכל התנאים הבאים מתקיימים: מספר היציאה של בדיקת המוכנות חייב להיות זהה לזה של ה-Pod שמשרת את התוכן. `containers[].spec.ports.containerPort` ה-Pod של השרת `containerPort` תואם ל-`targetPort` של השירות מפרט היציאה של קצה העורף של שירות Ingress מפנה ליציאה חוקית מ-`spec.ports[]` של השירות. אפשר לעשות זאת באחת משתי דרכים: ‫`spec.rules[].http.paths[].backend.service.port.name` in התאמה לתעבורת נתונים נכנסת `spec.ports[].name` שמוגדרת בשירות המתאים ‫`spec.rules[].http.paths[].backend.service.port.number` in התאמה לתעבורת נתונים נכנסת `spec.ports[].port` שמוגדרת בשירות המתאים
כתובת ה-IP של היעד	באיזון עומסים שמקורם בקונטיינר: כתובת ה-IP של ה-Pod לקבוצות של מכונות: כתובת ה-IP של הצומת	זהה לברירת המחדל: באיזון עומסים שמקורם בקונטיינר: כתובת ה-IP של ה-Pod לקבוצות של מכונות: כתובת ה-IP של הצומת

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

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

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

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

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

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

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

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

אם אתם משתמשים ב-GKE Enterprise: בבקר GKE Enterprise Ingress אין תמיכה בהשגת פרמטרים של בדיקת תקינות מתוך בדיקות המוכנות של ה-Pods שמשרתים את התעבורה. הוא יכול ליצור בדיקות תקינות רק באמצעות פרמטרים מרומזים או כפי שמוגדר ב-CRD‏ BackendConfig.
אם יש לכם יותר ממאגר אחד בתרמילי ה-Serving: ב-GKE אין דרך לבחור את בדיקת המוכנות של מאגר ספציפי שממנו אפשר להסיק פרמטרים של בדיקת תקינות. מכיוון שלכל קונטיינר יכולה להיות בדיקת מוכנות משלו, ומכיוון שבדיקת מוכנות היא לא פרמטר חובה לקונטיינר, צריך להגדיר את בדיקת התקינות לשירות לקצה העורפי המתאים על ידי הפניה אל BackendConfigCRD המתאים בשירות.
אם אתם צריכים שליטה ביציאה שמשמשת לבדיקות התקינות של מאזן העומסים:‏ GKE משתמש רק ב-containers[].readinessProbe.httpGet.port של בדיקת המוכנות לבדיקת התקינות של שירות הבק-אנד, כשהיציאה הזו תואמת ליציאת השירות של השירות שאליו מתייחס ה-Ingress‏ spec.rules[].http.paths[].backend.servicePort.

פרמטרים מ-`BackendConfig` CRD

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

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

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

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

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

אם שער המוכנות של ה-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 הן נקודות קצה ב-GCE_VM_IP_PORTNEG שמנוהל על ידי מישור הבקרה של GKE. ה-NEG מצורף לשירות לקצה העורפי. בדיקת התקינות של מאזן העומסים בשירות הקצה העורפי פג הזמן הקצוב לתפוגה.
כתובת IP אחת או יותר של ה-Pod הן נקודות קצה באחת או יותר מ-GCE_VM_IP_PORT NEGs. אף אחת מקבוצות ה-NEG לא מצורפת לשירות לקצה העורפי. אין נתונים זמינים של בדיקת תקינות של מאזן עומסים.

תמיכה ב-WebSocket

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

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

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

תרחישים מתקדמים של רשת

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

VPC משותף

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

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

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

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

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

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

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

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

צפייה באירוע של משאב 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.

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

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

מתן הרשאה לבקר 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.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

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

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

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

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

אם רוצים להפעיל בקר Ingress בהתאמה אישית עם התוסף HttpLoadBalancing מופעל, למשל כדי להשתמש בתכונות כמו חלוקה לקבוצות משנה ו-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

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

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

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

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