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 כדי לשמור אותו. אחר כך אפשר להפנות אל הסוד בשדה 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: האישור הראשי הוא האישור הראשון שמופיע בהערה.
- בביאור managed-certificates של אישורים שמנוהלים על ידי Google: כל האישורים המנוהלים ממוינים בסדר אלפביתי לפי שם. האישור הראשי הוא האישור הראשון ברשימה האלפביתית הזו. כדי להגדיר אישור ספציפי כאישור הראשי, צריך לתת לשמות של אובייקטים ManagedCertificate בהתאם כדי לשלוט בסדר המיון. לדוגמה, כדי להגדיר את my-default-cert כראשי במקום another-cert, אפשר לתת להם את השמות 0-my-default-cert ו-1-another-cert.

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

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

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

ניתוב תנועה

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

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

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

לדוגמה, אפשר להגדיר את מאזן העומסים כך שינתב בקשות לשירותי קצה עורפיים שונים בהתאם לנתיב כתובת ה-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.
לכל פוד של חבר צריך להיות מאגר שמקשיב ליציאת 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.
לכל פוד של חבר צריך להיות מאגר שמקשיב ליציאת 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. הוא נוצר כשירות NodePort באשכול במרחב השמות kube-system.default-http-backend

תגובת ה-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 מוכן לשרת תעבורה. בקר ה-Ingress של GKE יוצר את בדיקת תקינות לשרת הקצה העורפי של השירות על סמך בדיקת המוכנות שמשמשת את תרמילי ה-Serving של השירות. אפשר לגזור את הפרמטרים של בדיקת תקינות, כמו נתיב, יציאה ופרוטוקול, מההגדרה של בדיקת המוכנות.
ערכי ברירת מחדל: הפרמטרים שבהם נעשה שימוש כשלא מגדירים CRD או מאפיינים לבדיקת המוכנות.BackendConfig

שיטה מומלצת:

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

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

אם השירות מפנה אל CRD‏ BackendConfig עם מידע על healthCheck, ‏ GKE משתמש במידע הזה כדי ליצור את בדיקת תקינות. גם בבקר GKE Enterprise Ingress וגם בבקר GKE Ingress יש תמיכה ביצירת בדיקות תקינות בדרך הזו.
אם השירות לא מפנה אל CRD‏ BackendConfig:
- מערכת GKE יכולה להסיק חלק מהפרמטרים של בדיקת תקינות, או את כולם, אם ה-Serving 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 cannot be changed
סף לא בריא	לאיזון עומסים שמקורם בקונטיינר: 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 the Ingress matches `spec.ports[].name` defined in the corresponding Service ‫`spec.rules[].http.paths[].backend.service.port.number` in the Ingress matches `spec.ports[].port` defined in the corresponding Service
כתובת ה-IP של היעד	באיזון עומסים שמקורו בקונטיינר: כתובת ה-IP של ה-Pod לקבוצות של מכונות: כתובת ה-IP של הצומת	זהה לברירת המחדל: באיזון עומסים שמקורו בקונטיינר: כתובת ה-IP של ה-Pod לקבוצות של מכונות: כתובת ה-IP של הצומת

תומכות רק בהגדרת הכותרת Host.

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

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

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

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

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

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

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

הערה: גם אם אתם משתמשים ב-VPC משותף וגם אם לא, אם האשכול שלכם משתמש ב-Ingress פנימי, אתם צריכים ליצור ידנית כללי חומת אש שמאפשרים תעבורת נתונים נכנסת כדי לאפשר תעבורה מרשת המשנה של ה-proxy בלבד ברשת ה-VPC ובאזור של האשכול. צריך ליצור את הכללים האלה באופן ידני כי בקר הכניסה (ingress) של GKE לא יכול ליצור כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) כדי לאפשר תעבורה לתת-רשת של שרת 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 מופעל, למשל כדי להשתמש בתכונות כמו 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

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

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

תבניות להגדרת תעבורת נתונים נכנסת (ingress)

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