הגדרות של Ingress

סקירה כללית

בדף הזה מופיע מדריך מקיף להגדרת Kubernetes Ingress ב-Google Cloud. בדף הזה מוסבר איך להשתמש במשאבים מותאמים אישית של FrontendConfig כדי לנהל תכונות של קצה קדמי, כמו מדיניות SSL והפניות אוטומטיות ל-HTTPS, ובמשאבים מותאמים אישית של BackendConfig כדי לכוונן הגדרות של בק-אנד, כמו זמן קצוב לתפוגה של שירות, Cloud CDN, מדיניות אבטחה של Google Cloud Armor ו-Identity-Aware Proxy ‏(IAP).

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

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

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

השוואה בין תכונות

בטבלה הבאה מפורטת רשימה של תכונות נתמכות ל-Ingress ב- Google Cloud. מוצגת גם הזמינות של התכונה, זמינות לכלל המשתמשים (GA) או בטא.

סוג תעבורת נתונים נכנסת (Ingress)	תעבורת נתונים נכנסת (ingress) - חיצונית	תעבורת נתונים נכנסת (ingress) - פנימית	Multi Cluster Ingress
בקר Ingress	בקר Ingress באירוח של Google
Google Cloud סוג מאזן העומסים	מאזן עומסים חיצוני מסוג HTTP(S)	מאזן עומסים פנימי מסוג HTTP(S)	מאזן עומסים חיצוני מסוג HTTP(S)
היקף האשכול	אשכול יחיד	אשכול יחיד	אשכול מרובה
היקף מאזן העומסים	עולמי	אזורי	עולמי
תמיכה בסביבה	GKE	GKE	GKE
תמיכה ב-VPC משותף	GA	GA	GA
הערות שירות
איזון עומסים שמקורם בקונטיינר (NEGs)	GA	GA	GA
‫HTTPS ממאזן העומסים לקצה העורפי	GA	GA	GA
HTTP/2	GA	GA TLS Only	GA
הערות לגבי תעבורת נתונים נכנסת (Ingress)
כתובות IP סטטיות	GA	GA	GA
אישורים מבוססי-סודות ב-Kubernetes	GA	GA	GA
אישורי SSL בניהול עצמי	GA	GA	GA
אישורי SSL שמנוהלים על ידי Google	GA		GA
FrontendConfig
מדיניות SSL	GA	GA with Gateway	GA
הפניה אוטומטית מ-HTTP ל-HTTPS	GA 1.17.13-gke.2600+^GA		GA
BackendConfig
זמן קצוב לתפוגה של שירות לקצה העורפי	GA	GA	GA
Cloud CDN	GA		GA
הזמן הקצוב לתפוגה של זמן להשלמת תהליך (connection draining)	GA	GA	GA
הגדרת בדיקת תקינות של מאזן עומסים בהתאמה אישית	GA	GA	GA
כללי מדיניות האבטחה של Google Cloud Armor	GA 1.19.10-gke.700^G		GA
הגדרת רישום ביומן של גישת HTTP	GA	GA	GA
שרת proxy לאימות זהויות (IAP)	GA	GA	GA
זיקה לסשן	GA	GA	GA
כותרות בקשות שהוגדרו על ידי המשתמש	GA		GA
כותרות תגובה בהתאמה אישית	GA 1.25-gke+^G

‫^Bהתכונה הזו זמינה בגרסת בטא החל מהגרסה שצוינה. התכונות שלא מצוינת לגביהן גרסה נתמכות בכל הגרסאות הזמינות של GKE.

^Gהתכונה הזו נתמכת כ-GA החל מהגרסה שצוינה.

הגדרת Ingress באמצעות בקר ברירת המחדל

אי אפשר להגדיר ידנית את התכונות של LoadBalancer באמצעות Google Cloud SDK או מסוף Google Cloud . צריך להשתמש במשאבי Kubernetes מסוג BackendConfig או FrontendConfig.

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

‫FrontendConfig ו-BackendConfig הם הגדרות מותאמות אישית של משאבים (CRD) שמאפשרות לכם להתאים אישית את איזון העומסים. ה-CRD האלה מאפשרים להגדיר תכונות נוספות של מאזן העומסים באופן היררכי ומובנה יותר מאשר באמצעות הערות. כדי להשתמש ב-Ingress (וב-CRD האלה), צריך להפעיל את התוסף לאיזון עומסים של HTTP. באשכולות GKE, איזון עומסים של HTTP מופעל כברירת מחדל, ואסור להשבית אותו.

יש הפניה ל-FrontendConfigs באובייקט Ingress, ואפשר להשתמש בהם רק עם Ingresses חיצוניים. אובייקטים מסוג BackendConfig מפנים לאובייקט מסוג Service. אפשר להפנות לאותם CRD מכמה אובייקטים של Service או Ingress כדי לשמור על עקביות בהגדרות. ל-CRD‏ FrontendConfig ול-CRD‏ BackendConfig יש מחזור חיים זהה למשאבי ה-Ingress וה-Service התואמים שלהם, ולרוב הם נפרסים יחד.

התרשים הבא מדגים איך:

• הערה באובייקט Ingress או MultiClusterIngress מפנה אל CRD של FrontendConfig. ה-CRD‏ FrontendConfig מפנה אל Google Cloud מדיניות SSL.

• הערה באובייקט Service או MultiClusterService מפנה אל BackendConfig CRD. ה-CRD‏ BackendConfig מציין הגדרות מותאמות אישית לבדיקת תקינות של שירות הקצה העורפי התואם.

איור: סקירה כללית של BackendConfig ו-FrontendConfig

שיוך של FrontendConfig ל-Ingress

אפשר להשתמש ב-FrontendConfig רק עם External Ingresses.

אפשר לשייך FrontendConfig ל-Ingress או ל-MultiClusterIngress.

תעבורת נתונים נכנסת (Ingress)

משתמשים בהערה networking.gke.io/v1beta1.FrontendConfig:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

מחליפים את FRONTENDCONFIG_NAME בשם של FrontendConfig.

MultiClusterIngress

משתמשים בהערה networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

מחליפים את FRONTENDCONFIG_NAME בשם של FrontendConfig.

שיוך של BackendConfig ל-Ingress

אפשר להשתמש בהערה cloud.google.com/backend-config או beta.cloud.google.com/backend-config כדי לציין את השם של BackendConfig.

אותו BackendConfig לכל יציאות השירות

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

אפשר להשתמש במפתח default גם במשאבי Ingress וגם במשאבי MultiClusterIngress.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

‫BackendConfig ייחודי לכל יציאת שירות

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

‫GKE 1.16-gke.3 ואילך

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

כל הגרסאות הנתמכות

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

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

• ‫BACKENDCONFIG_REFERENCE_A: השם של BackendConfig קיים.
• ‫BACKENDCONFIG_REFERENCE_B: השם של BackendConfig קיים.
• ‫SERVICE_REFERENCE_A: משתמשים בערך PORT_NUMBER_1 או PORT_NAME_1. הסיבה לכך היא שההערה BackendConfig של שירות יכולה להתייחס לשם היציאה (spec.ports[].name) או למספר היציאה (spec.ports[].port).
• ‫SERVICE_REFERENCE_B: משתמשים בערך PORT_NUMBER_2 או PORT_NAME_2. הסיבה לכך היא שההערה BackendConfig של שירות יכולה להתייחס לשם היציאה (spec.ports[].name) או למספר היציאה (spec.ports[].port).

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

• כשמשתמשים באיזון עומסים מובנה בקונטיינר, מאזן העומסים שולח תנועה לנקודת קצה בקבוצת נקודות קצה ברשת (שמתאימה לכתובת IP של Pod) ביציאת השירות שאליה מתבצעת ההפניה targetPort (שחייבת להתאים ל-containerPort של Pod שמשרת בקשות). אחרת, מאזן העומסים שולח תעבורה לכתובת ה-IP של הצומת ביציאת השירות שאליה מתייחסים nodePort.

• כשמשתמשים ב-BackendConfig כדי לספק בדיקת תקינות מותאמת אישית למאזן העומסים, מספר היציאה שמשמש לבדיקת התקינות של מאזן העומסים יכול להיות שונה ממספר spec.ports[].port של השירות. פרטים על מספרי יציאות לבדיקות תקינות מופיעים במאמר הגדרה של בדיקות תקינות בהתאמה אישית.

הערה: צריך להשתמש ביציאת השירות שמשויכת ל-BackendConfig גם בשדה backend.service.port של הגדרת ה-Ingress. אם יציאת השירות לא נמצאת בשימוש באף אובייקט Ingress, המערכת מתעלמת מ-BackendConfig.

הגדרת תכונות של Ingress באמצעות פרמטרים של FrontendConfig

בקטע הבא מוסבר איך להגדיר את FrontendConfig כדי להפעיל תכונות ספציפיות של Ingress.

מדיניות SSL

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

השדה sslPolicy ב-FrontendConfig מפנה לשם של מדיניות SSL באותו פרויקט sslPolicyשבו נמצא אשכול GKE. Google Cloud הוא מצרף את מדיניות ה-SSL לשרת ה-proxy של HTTPS, שנוצר עבור מאזן העומסים החיצוני מסוג HTTP(S) על ידי Ingress. אפשר להפנות לכמה משאבי Ingress לאותו משאב FrontendConfig ולאותה מדיניות SSL. אם משנים מדיניות SSL שמפנים אליה, השינוי מועבר אל ממשקי הקצה של Google (GFE) שמפעילים את מאזן העומסים החיצוני של HTTP(S) שנוצר על ידי Ingress.

מניפסט FrontendConfig הבא מאפשר מדיניות SSL בשם gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

הפניות אוטומטיות מ-HTTP ל-HTTPS

מאזן עומסים חיצוני מסוג HTTP יכול להפנות בקשות HTTP לא מוצפנות למאזן עומסים מסוג HTTPS שמשתמש באותה כתובת IP. כשיוצרים Ingress עם הפניות אוטומטיות מ-HTTP ל-HTTPS, שני מאזני העומסים האלה נוצרים באופן אוטומטי. בקשות לכתובת ה-IP החיצונית של Ingress ביציאה 80 מופנות אוטומטית לאותה כתובת IP חיצונית ביציאה 443. הפונקציונליות הזו מבוססת על הפניות אוטומטיות מ-HTTP ל-HTTPS שמסופקות על ידי Cloud Load Balancing.

כדי לתמוך בהפניה אוטומטית מ-HTTP ל-HTTPS, צריך להגדיר Ingress שישרת תנועה של HTTP ו-HTTPS. אם משביתים את HTTP או HTTPS, ההפניה האוטומטית לא תפעל.

הפניות אוטומטיות מ-HTTP ל-HTTPS מוגדרות באמצעות השדה redirectToHttps במשאב מותאם אישית FrontendConfig. ההפניות האוטומטיות מופעלות לכל משאב ה-Ingress, כך שכל השירותים שמקושרים ל-Ingress יכללו הפניות אוטומטיות ל-HTTPS.

קובץ המניפסט FrontendConfig הבא מאפשר הפניות אוטומטיות מ-HTTP ל-HTTPS. מגדירים את השדה spec.redirectToHttps.enabled לערך true כדי להפעיל הפניות אוטומטיות ל-HTTPS. השדה spec.responseCodeName הוא אופציונלי. אם לא מציינים את סוג ההפניה, המערכת משתמשת בהפניה אוטומטית מסוג 301 Moved Permanently.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

מחליפים את RESPONSE_CODE באחד מהערכים הבאים:

• ‫MOVED_PERMANENTLY_DEFAULT כדי להחזיר קוד תגובה של הפניה אוטומטית מסוג 301 (ברירת המחדל אם לא מצוין responseCodeName).
• ‫FOUND כדי להחזיר קוד תגובה של הפניה לכתובת אחרת מסוג 302.
• ‫SEE_OTHER כדי להחזיר קוד תגובה מסוג 303 שמציין הפניה לכתובת אחרת.
• ‫TEMPORARY_REDIRECT כדי להחזיר קוד תגובה מסוג 307 של הפניה אוטומטית.
• ‫PERMANENT_REDIRECT כדי להחזיר קוד תגובה מסוג 308 של הפניה אוטומטית.

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

כדי לוודא שההפניה האוטומטית פועלת, משתמשים בפקודה curl:

curl http://IP_ADDRESS

מחליפים את IP_ADDRESS בכתובת ה-IP של ה-Ingress.

בתגובה מוצג קוד התגובה להפניה שהגדרתם. לדוגמה, הדוגמה הבאה היא של FrontendConfig שהוגדר עם הפניה אוטומטית 301: MovedPermanently:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

הגדרה של תכונות Ingress באמצעות פרמטרים של BackendConfig

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

מידע על מגבלות של BackendConfig זמין בקטע מגבלות.

זמן קצוב לתפוגה של שירות לקצה העורפי

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

במניפסט BackendConfig הבא מוגדר פסק זמן של 40 שניות:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

אפשר להפעיל את Cloud CDN באמצעות BackendConfig.

הערה: אי אפשר להפעיל גם IAP וגם Cloud CDN ב-BackendConfig. אם ב-BackendConfig אין בלוק iap, אז כל הגדרות ה-IAP הקיימות בשירות לקצה העורפי עוברות בירושה.

במניפסט הבא של BackendConfig מוצגים כל השדות שזמינים כשמפעילים את Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      # Specify only one of queryStringBlacklist and queryStringWhitelist.
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    # Time, in seconds, to continue serving a stale version after request expiry.
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

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

• ‫CDN_ENABLED: אם הערך הוא true, ‏ Cloud CDN מופעל עבור קצה עורפי של Ingress.
• ‫INCLUDE_HOST: אם הערך הוא true, בקשות למארחים שונים נשמרות במטמון בנפרד.
• ‫INCLUDE_PROTOCOL: אם הערך הוא true, בקשות HTTP ו-HTTPS נשמרות במטמון בנפרד.
• ‫INCLUDE_QUERY_STRING: אם הערך הוא true, פרמטרים של מחרוזת שאילתה נכללים במפתח המטמון בהתאם ל-queryStringBlacklist או ל-queryStringWhitelist. אם אף אחד מהם לא מוגדר, כל מחרוזת השאילתה נכללת. אם ההגדרה היא false, כל מחרוזת השאילתה מוחרגת ממפתח המטמון.
• ‫QUERY_STRING_DENYLIST: מציינים מערך מחרוזות עם השמות של פרמטרים של מחרוזות שאילתה שרוצים להחריג ממפתחות המטמון. כל שאר הפרמטרים נכללים. אפשר לציין queryStringBlacklist או queryStringWhitelist, אבל לא את שניהם.
• ‫QUERY_STRING_ALLOWLIST: מציינים מערך מחרוזות עם השמות של פרמטרים של מחרוזת שאילתה שרוצים לכלול במפתחות של מטמון. כל שאר הפרמטרים לא נכללים. אפשר להשתמש ב-queryStringBlacklist או ב-queryStringWhitelist, אבל לא בשניהם.

השדות הבאים נתמכים רק בגרסאות GKE‏ 1.23.3-gke.900 ואילך באמצעות GKE Ingress. לא נתמכים באמצעות Multi Cluster Ingress:

• CACHE_MODE: מצב מטמון.
• ‫CLIENT_TTL, ‏ DEFAULT_TTL, ו-MAX_TTL: הגדרת TTL. מידע נוסף מופיע במאמר שימוש בהגדרות TTL וביטול שלהן.
• ‫NEGATIVE_CACHING: אם הערך הוא true, השמירה במטמון של תשובות שליליות מופעלת. מידע נוסף זמין במאמר בנושא שימוש ב-negative caching.
• ‫NEGATIVE_CACHING_CODE ו-NEGATIVE_CACHING_TTL: הגדרת negative caching. מידע נוסף זמין במאמר בנושא שימוש ב-negative caching.
• ‫REQ_COALESCING: אם הערך מוגדר ל-true, ההסתרה מופעלת. מידע נוסף זמין במאמר בקשה לאיחוד (coalescing).
• ‫SERVE_WHILE_STALE: משך הזמן, בשניות, אחרי שתוקף התגובה פג, שבו Cloud CDN ממשיך להציג גרסה לא עדכנית. מידע נוסף זמין במאמר בנושא הצגת תוכן מיושן.
• ‫SIGNED_MAX_AGE: משך הזמן המקסימלי שבו אפשר לשמור תשובות במטמון, בשניות. מידע נוסף זמין במאמר בנושא התאמה אישית של הזמן המקסימלי לשמירה במטמון.
• ‫KEY_NAME, ‏ KEY_VALUE ו-SECRET_NAME: הגדרת מפתח של כתובת URL חתומה. מידע נוסף זמין במאמר בנושא יצירת מפתחות לבקשות חתומות.

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

דוגמה ל-Cloud CDN

כדי להשתמש ב-BackendConfig להגדרת Cloud CDN, מבצעים את המשימות הבאות:

1. יוצרים מרחב שמות ייעודי כדי להריץ את הדוגמה הזו:
   

   kubectl create namespace cdn-how-to
   

2. יוצרים קובץ פריסה בשם my-deployment.yaml על סמך מניפסט הפריסה הבא. המניפסט הזה מצהיר שרוצים להפעיל שני עותקים של אפליקציית האינטרנט ingress-gce-echo-amd64.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: cdn-how-to
     name: my-deployment
   spec:
     selector:
       matchLabels:
         purpose: demonstrate-cdn
     replicas: 2
     template:
       metadata:
         labels:
           purpose: demonstrate-cdn
       spec:
         containers:
         - name: echo-amd64
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app-cdn:1.0

3. יוצרים את משאב הפריסה:

   kubectl apply -f my-deployment.yaml
   

4. יוצרים BackendConfig בשם my-backendconfig.yaml על סמך מניפסט ה-BackendConfig הבא. המניפסט מציין מדיניות מטמון של Cloud CDN ומצהיר שצריך להפעיל את Cloud CDN:

     apiVersion: cloud.google.com/v1
     kind: BackendConfig
     metadata:
       namespace: cdn-how-to
       name: my-backendconfig
     spec:
       cdn:
         enabled: true
         cachePolicy:
           includeHost: true
           includeProtocol: true
           includeQueryString: false

5. יוצרים את משאב BackendConfig:

   kubectl apply -f my-backendconfig.yaml
   

6. יוצרים קובץ בשם my-service.yaml על סמך מניפסט השירות הבא:

   apiVersion: v1
   kind: Service
   metadata:
     namespace: cdn-how-to
     name: my-service
     labels:
       purpose: demonstrate-cdn
     # Use a custom BackendConfig for port 80 in the Service.
     annotations:
       cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
   spec:
     type: NodePort
     selector:
       purpose: demonstrate-cdn
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080

7. יוצרים את משאב השירות:

   kubectl apply -f my-service.yaml
   

8. כדי ליצור כתובת IP שמורה:

   gcloud compute addresses create cdn-how-to-address --global
   

9. יוצרים קובץ בשם my-ingress.yaml על סמך מניפסט ה-Ingress הבא:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     namespace: cdn-how-to
     name: my-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "cdn-how-to-address"
   spec:
     rules:
     # Route all incoming HTTP requests to port 80 in the example Service.
     - http:
         paths:
         - path: /*
           pathType: ImplementationSpecific
           backend:
             service:
               name: my-service
               port:
                 number: 80

10. יוצרים את משאב ה-Ingress:

    kubectl apply -f my-ingress.yaml
    

11. ממתינים כעשר דקות עד שמאזן העומסים מוגדר על ידי בקר ה-Ingress של Kubernetes, ואז מאחזרים את כתובת ה-IP שמשמשת את כללי ההעברה של מאזן העומסים ממשאב ה-Ingress. Google Cloud

    kubectl describe ingress my-ingress --namespace=cdn-how-to | grep "Address"
    

    פלט:
    ‫

    Address:         ADDRESS
    

    ‫ADDRESS היא כתובת ה-IP החיצונית של Ingress.

אימות של שמירה במטמון ב-Cloud CDN

כדי לוודא שהתוכן שלכם נשמר במטמון, מזינים את הפקודה curl הבאה פעמיים:

curl -v ADDRESS/?cache=true

מחליפים את ADDRESS בכתובת ה-IP החיצונית של Ingress.

בפלט מוצגים גוף התגובה וכותרות התגובה. בכותרות התגובה, אפשר לראות שהתוכן נשמר במטמון. הכותרת Age מציינת את מספר השניות שחלפו מאז שהתוכן נשמר במטמון:

HTTP/1.1 200 OK
Date: Fri, 25 Jan 2019 02:34:08 GMT
Content-Length: 70
Content-Type: text/plain; charset=utf-8
Via: 1.1 google
Cache-Control: max-age=86400,public
Age: 2716

Hello, world!
Version: 1.0.0
Hostname: my-deployment-7f589cc5bc-l8kr8
...

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

סידור וארגון

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

gcloud compute addresses delete cdn-how-to-address --global

זמן להשלמת תהליך (connection draining)

אפשר להגדיר זמן להשלמת תהליך (connection draining) באמצעות BackendConfig. הזמן הקצוב לתפוגה של זמן להשלמת תהליך הוא הזמן, בשניות, שבו המערכת מחכה עד שהחיבורים יסתיימו. במהלך משך הזמן שצוין לזמן קצוב לתפוגה, הבקשות הקיימות לבק-אנד שהוסר מקבלות זמן להשלמה. מאזן העומסים לא שולח בקשות חדשות לעורף הקצה שהוסר. אחרי שמגיעים לזמן הקצוב לתפוגה, כל החיבורים שנותרו לשרת העורפי נסגרים. משך הזמן של זמן קצוב לתפוגה יכול להיות בין 0 ל-3,600 שניות. ערך ברירת המחדל הוא 0, שגם משבית את זמן להשלמת תהליך (connection draining).

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

במניפסט BackendConfig הבא מוגדר זמן להשלמת תהליך (connection draining) של 60 שניות:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

הגדרת בדיקת תקינות בהתאמה אישית

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

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

הערה: ב-Ingress אין תמיכה ב-gRPC להגדרות מותאמות אישית של בדיקות תקינות.

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

במניפסט BackendConfig הבא מוצגים כל השדות שזמינים כשמגדירים בדיקת תקינות של BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    # Time, in seconds, between prober checks. Default is `5`.
    checkIntervalSec: INTERVAL
    # Probe timeout period. Must be less than or equal to checkIntervalSec.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    # Protocol to use. Must be `HTTP`, `HTTP2`, or `HTTPS`.
    type: PROTOCOL
    # Path for probe to use. Default is `/`.
    requestPath: PATH
    # Port number of the load balancer health check port. Default is `80`.
    port: PORT

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

• ‫INTERVAL: מציינים את check-interval בשניות לכל בודק בדיקות תקינות. זהו הזמן שחלף מתחילת הבדיקה של בודק אחד ועד לתחילת הבדיקה הבאה שלו. אם לא מציינים את הפרמטר הזה, המערכת תשתמש בברירת המחדל של 5 שניות. Google Cloud פרטים נוספים על ההטמעה זמינים במאמר בדיקות מרובות ותדירות.
• ‫TIMEOUT: מציינים את משך הזמן שבו Google Cloud ההמתנה לתשובה לבקשה לבדיקת תקינות (probe). הערך של TIMEOUT חייב להיות קטן מהערך של INTERVAL או שווה לו. היחידות הן שניות. כל בדיקה דורשת קוד תגובה HTTP 200 (OK) שיועבר לפני פסק הזמן של הבדיקה.
• ‫HEALTH_THRESHOLD ו-UNHEALTHY_THRESHOLD: מציינים את מספר הניסיונות הרצופים ליצירת חיבור שצריכים להצליח או להיכשל, לפחות בבדיקה אחת, כדי לשנות את מצב התקינות מ'תקין' ל'לא תקין' או להיפך. אם משמיטים אחד מהפרמטרים האלה, Google Cloud משתמש בערך ברירת המחדל 2.
• ‫PROTOCOL: מציינים פרוטוקול שמשמש את מערכות הבדיקה לבדיקת תקינות. BackendConfig תומך רק ביצירת בדיקות תקינות באמצעות הפרוטוקולים HTTP,‏ HTTPS או HTTP2. למידע נוסף, ראו קריטריונים להצלחה של HTTP,‏ HTTPS ו-HTTP/2. אי אפשר להשמיט את הפרמטר הזה.
• ‫PATH: בבדיקות תקינות של HTTP,‏ HTTPS או HTTP2, מציינים את request-path שאליו מערכת הבדיקה צריכה להתחבר. אם לא מציינים את הפרמטר הזה,Google Cloud משתמש בברירת המחדל /.

• ‫PORT: BackendConfig תומך רק בציון היציאה של בדיקת תקינות מאזן העומסים באמצעות מספר יציאה. אם לא מציינים את הפרמטר הזה, Google Cloud משתמש בערך ברירת המחדל 80.

  • כשמשתמשים באיזון עומסים מקורי של קונטיינר, צריך לבחור יציאה שתואמת ל-containerPort של Pod להצגת נתונים (בין אם containerPort הזה מפנה ל-targetPort של השירות ובין אם לא). מאזן העומסים שולח בדיקות לכתובת ה-IP של ה-Pod ישירות, ולכן אתם לא מוגבלים ל-containerPorts שמקושרים ל-targetPort של Service. מערכות בדיקת תקינות מתחברות לכתובת ה-IP של Pod שמשרת תנועה ביציאה שאתם מציינים.

  • לדוגמה, עבור קצוות עורפיים של קבוצות, צריך לבחור יציאה שתואמת ל-nodePort exposed by the Service. לאחר מכן, מערכות בדיקת תקינות מתחברות לכל צומת ביציאה הזו.

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

מדיניות אבטחה של Google Cloud Armor Ingress

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

מוסיפים את השם של מדיניות האבטחה ל-BackendConfig. מניפסט ה-BackendConfig הבא מציין מדיניות אבטחה בשם example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

אזהרה: אין לשנות ישירות את משאבי BackendService ב-Compute Engine כדי לצרף את מדיניות Cloud Armor לשירותי הקצה העורפי שמנוהלים על ידי GKE.

שני מקורות מידע אמינים

למרות שההגדרה מתבצעת דרך GKE, עדיין אפשר להשתמש בממשקי ה-API הבסיסיים של Compute Engine BackendService כדי לשנות ישירות את מדיניות האבטחה שרוצים להחיל. כך נוצרים שני מקורות אמת: GKE ו-Compute Engine. התנהגות של GKE Ingress Controller בתגובה לשדה securityPolicy בתוך BackendConfig מתועדת בטבלה שלמטה. כדי למנוע התנגשויות והתנהגות לא צפויה, מומלץ להשתמש ב-GKE BackendConfigכדי לנהל את מדיניות האבטחה שבה רוצים להשתמש.

שדה BackendConfig	ערך	התנהגות
spec.securityPolicy.name	CloudArmorPolicyName	בקר הכניסה (Ingress) של GKE מגדיר את מדיניות Cloud Armor שנקראת CloudArmorPolicyName למאזן העומסים. בקר הכניסה של GKE מחליף את המדיניות שהוגדרה קודם.
spec.securityPolicy.name	מחרוזת ריקה ("")	בקר הכניסה (Ingress) של GKE מסיר כל מדיניות Cloud Armor שהוגדרה ממאזן העומסים.
spec.securityPolicy	nil	ב-GKE Ingress Controller נעשה שימוש בהגדרה שנקבעה באובייקט BackendService שהוגדר באמצעות Compute Engine API באמצעות Google Cloud המסוף, ה-CLI של gcloud או Terraform.

כדי להגדיר GKE Ingress עם הגנה של Google Cloud Armor, אפשר לעיין במאמר Google Cloud Armor enabled Ingress.

רישום ביומן הגישה של HTTP

הערה: כברירת מחדל, ב-GKE מופעלת רישום ביומן של גישה לכל סוגי הכניסה (ingress) (כולל Multi Cluster Ingress). הגדרת רישום ביומן של גישה ל-GKE Ingress לא נתמכה בגרסאות GKE לפני 1.16.8-gke.10. בגרסאות GKE‏ ‎1.16.8-gke.10 ואילך, אפשר להגדיר את ההגדרה של רישום ביומן הגישה ל-GKE Ingress באמצעות BackendConfig.

Ingress יכול לרשום ביומן את כל בקשות ה-HTTP מהלקוחות אל Cloud Logging. אתם יכולים להפעיל ולהשבית רישום גישה ביומן באמצעות BackendConfig, וגם להגדיר את קצב הדגימה של רישום הגישה ביומן.

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

אפשר להגדיר את השדות הבאים:

• ‫enable: אם הערך מוגדר ל-true, רישום הגישה יופעל עבור ה-Ingress הזה והיומנים יהיו זמינים ב-Cloud Logging. אחרת, רישום הגישה מושבת עבור ה-Ingress הזה.
• ‫sampleRate: מציינים ערך מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום ביומן של מנות ו-1.0 אומר שמתבצע רישום ביומן של 100% מהמנות. השדה הזה רלוונטי רק אם הערך של enable הוא true. השדה sampleRate הוא אופציונלי, אבל אם הוא מוגדר, צריך להגדיר גם את השדה enable: true, אחרת הוא יפורש כ-enable: false.

המאניפסט הבא של BackendConfig מאפשר רישום ביומן של הגישה ומגדיר את שיעור הדגימה ל-50% מבקשות ה-HTTP עבור משאב Ingress נתון:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

שרת proxy לאימות זהויות (IAP)

כדי להגדיר את BackendConfig עבור שרת proxy לאימות זהויות (IAP), צריך לציין את הערכים enabled ו-secretName בבלוק iap ב-BackendConfig. כדי לציין את הערכים האלה, צריך לוודא שלסוכן השירות של GKE יש את ההרשאה compute.backendServices.update.

הערה: אי אפשר להפעיל גם IAP וגם Cloud CDN ב-BackendConfig. אם ב-BackendConfig אין בלוק iap, אז כל הגדרות ה-IAP הקיימות בשירות לקצה העורפי עוברות בירושה.

המניפסט הבא של BackendConfig מאפשר להשתמש בשרת proxy לאימות זהויות (IAP):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

הפעלת IAP באמצעות לקוח OAuth שמנוהל על ידי Google

החל מ-GKE 1.29.4-gke.1043000, אפשר להגדיר את IAP כך שישתמש בלקוח OAuth שמנוהל על ידי Google באמצעות BackendConfig. כדי להחליט אם להשתמש בלקוח OAuth שמנוהל על ידי Google או בלקוח OAuth בהתאמה אישית, אפשר לעיין במאמר מתי כדאי להשתמש בהגדרת OAuth בהתאמה אישית במסמכי ה-IAP.

כדי להפעיל IAP באמצעות לקוח OAuth שמנוהל על ידי Google, אל תספקו את OAuthCredentials ב-BackendConfig. למשתמשים שכבר הגדירו את IAP באמצעות OAuthCredentials, אין נתיב העברה למעבר לשימוש בלקוח OAuth שמנוהל על ידי Google: צריך ליצור מחדש את ה-Backend (להסיר את השירות מה-Ingress ולצרף אותו מחדש). מומלץ לבצע את הפעולה הזו במהלך חלון זמן לתחזוקה, כי היא תגרום להשבתה. אפשר גם לבצע את המעבר בכיוון ההפוך, כלומר לעבור מלקוח OAuth שמנוהל על ידי Google אל OAuthCredentials.

מניפסט BackendConfig הבא מאפשר שימוש בשרת Proxy לאימות זהויות (IAP) עם לקוח OAuth שמנוהל על ידי Google:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

הוראות מלאות זמינות במאמר בנושא הפעלת IAP ב-GKE במסמכי התיעוד של IAP.

הערה: אם אתם משתמשים ב-IAP בגרסאות אשכול GKE‏ 1.29.2-gke.1521000, 1.29.3-gke.1093000, 1.29.3-gke.1093002 או 1.29.3-gke.1282000, כדי למנוע הפסקה זמנית בשירות, עליכם לשדרג לגרסת אשכול GKE‏ 1.29.4-gke.1043000.

שרת proxy לאימות זהויות (IAP) עם תעבורת נתונים נכנסת (ingress) פנימית

כדי להגדיר Ingress פנימי ל-IAP, צריך להשתמש במסלול פרימיום. אם אתם לא משתמשים במסלול פרימיום, אתם לא יכולים להציג או ליצור מאזני עומסים פנימיים של אפליקציות עם שרת proxy לאימות זהויות (IAP). כדי להשתמש ב-Ingress פנימי עבור IAP, צריך גם מינוי ל-Chrome Enterprise Premium.

כדי להגדיר GKE Ingress מאובטח עם אימות מבוסס-שרת proxy לאימות זהויות (IAP), אפשר לעיין בדוגמה IAP enabled ingress.

זיקה לסשן (session affinity)

אפשר להשתמש ב-BackendConfig כדי להגדיר זיקה לסשן לכתובת IP של לקוח או לקובץ Cookie שנוצר.

חשוב: השתמשו באשכול המותאם ל-VPC אם רוצים להגדיר זיקה לסשן (session affinity). הזיקה לסשן (session affinity) שימושית רק לשירותים שמגובים על ידי קבוצות של נקודות קצה ברשת, וקבוצות של נקודות קצה ברשת דורשות אשכול המותאם ל-VPC.

זיקה לכתובת IP של לקוח

כדי להשתמש ב-BackendConfig כדי להגדיר זיקה לכתובת IP של לקוח, צריך להגדיר את affinityType ל-"CLIENT_IP", כמו בדוגמה הבאה:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

זיקה לקובץ Cookie שנוצר

כדי להשתמש ב-BackendConfig כדי להגדיר זיקה לקובצי Cookie שנוצרו, מגדירים את affinityType ל-GENERATED_COOKIE במניפסט של BackendConfig. אפשר גם להשתמש ב-affinityCookieTtlSec כדי להגדיר את משך הזמן שבו קובץ ה-Cookie יישאר פעיל.

במניפסט הבא, סוג הזיקה מוגדר כקובץ Cookie שנוצר, וקובצי ה-Cookie מקבלים TTL של 50 שניות:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

כותרות בקשה שהמשתמש מגדיר

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

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

כדי להפעיל כותרות בקשה שמוגדרות על ידי המשתמש, מציינים רשימה של כותרות במאפיין customRequestHeaders של משאב BackendConfig. מציינים כל כותרת כמחרוזת header-name:header-value.

במניפסט BackendConfig הבא מתווספות שלוש כותרות בקשה:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

כותרות תגובה מותאמות אישית

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

כדי להפעיל כותרות תגובה מותאמות אישית, צריך לציין רשימה של כותרות במאפיין customResponseHeaders של משאב BackendConfig. מציינים כל כותרת כמחרוזת header-name:header-value.

כותרות תגובה מותאמות אישית זמינות רק באשכולות GKE מגרסה 1.25 ואילך.

המניפסט הבא של BackendConfig הוא דוגמה להוספה של כותרת תגובה של HTTP Strict Transport Security ‏ (HSTS) ל-Ingress חיצוני:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

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

בתרגיל הבא מוסבר איך מגדירים פסק זמן (timeout) וריקון חיבורים (connection draining) באמצעות Ingress עם משאב BackendConfig.

כדי להגדיר את מאפייני ה-backend של Ingress, מבצעים את המשימות הבאות:

1. יצירת פריסה.
2. יוצרים BackendConfig.
3. יוצרים שירות ומשייכים אחת מהיציאות שלו ל-BackendConfig.
4. יוצרים Ingress ומשייכים אותו לצמד (שירות, יציאה).
5. מאמתים את המאפיינים של שירות לקצה העורפי.
6. ניקוי.

יצירת פריסה

לפני שיוצרים BackendConfig ושירות, צריך ליצור פריסה.

קובץ המניפסט הבא הוא של פריסה בשם my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

יוצרים את הפריסה באמצעות הפקודה הבאה:

kubectl apply -f my-deployment.yaml

יצירת BackendConfig

משתמשים ב-BackendConfig כדי לציין את התכונות של Ingress שרוצים להשתמש בהן.

המניפסט של BackendConfig, שנקרא my-backendconfig.yaml, מציין:

• פסק זמן של 40 שניות.
• זמן קצוב לתפוגה של 60 שניות להשלמת תהליך (connection draining).

# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

כדי ליצור את BackendConfig, מריצים את הפקודה הבאה:

kubectl apply -f my-backendconfig.yaml

יצירת שירות

‫BackendConfig מתאים לשילוב יחיד של Service-Port, גם אם ל-Service יש כמה יציאות. אפשר לשייך כל יציאה ל-CRD‏ (CustomResourceDefinition) יחיד של BackendConfig. אם יציאת שירות מפנה ל-Ingress, ויציאת השירות משויכת ל-BackendConfig, אז שירות הקצה העורפי של איזון העומסים מסוג HTTP(S) מקבל חלק מההגדרה שלו מ-BackendConfig.

זו דוגמה למניפסט שירות בשם my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  # Associate the Service with Pods that have the same label.
  labels:
    purpose: bsc-config-demo
  annotations:
    # Associate TCP port 80 with a BackendConfig.
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  # Forward requests from port 80 in the Service to port 8080 in a member Pod.
  - port: 80
    protocol: TCP
    targetPort: 8080

ההערה cloud.google.com/backend-config מציינת מיפוי בין יציאות לאובייקטים של BackendConfig. ב-my-service.yaml:

• כל Pod עם התווית purpose: bsc-config-demo הוא חבר בשירות.
• יציאת TCP מספר 80 של השירות משויכת ל-BackendConfig בשם my-backendconfig. ההערה cloud.google.com/backend-config מציינת את זה.
• בקשה שנשלחת ליציאה 80 של השירות מועברת לאחד מ-Pods החברים ביציאה 8080.

כדי ליצור את השירות, מריצים את הפקודה הבאה:

kubectl apply -f my-service.yaml

יצירת Ingress

הדוגמה הבאה מציגה מניפסט של Ingress בשם my-ingress.yaml.. בדוגמה הזו, בקשות נכנסות מנותבות ליציאה 80 של השירות בשם my-service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  # Route all HTTP requests to port 80 in a Service.
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

כדי ליצור את ה-Ingress, מריצים את הפקודה הבאה:

kubectl apply -f my-ingress.yaml

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

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

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

קודם כל, מתארים את משאב ה-my-ingress ומסננים את ההערה שמפרטת את שירותי ה-Backend שמשויכים ל-Ingress. לדוגמה:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

הפלט אמור להיראות כך:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

הפלט מספק מידע על שירותי ה-Backend. לדוגמה, האנוטציה הזו מכילה שני שירותי קצה עורפי:

• ‫"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" מספק מידע על שירות הקצה העורפי שמשויך ל-my-service Kubernetes Service.
  • ‫k8s1-27fde173 הוא גיבוב שמשמש לתיאור האוסף.
  • ‫default הוא מרחב השמות של Kubernetes.
  • ‫HEALTHY מציין שהקצה העורפי תקין.
• "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" מספק מידע על שירות לקצה העורפי שמשויך לBackend שמוגדר כברירת מחדל (404-server).
  • ‫k8s1-27fde173 הוא גיבוב שמשמש לתיאור האוסף.
  • ‫kube-system הוא מרחב השמות.
  • ‫default-http-backend הוא שם השירות ב-Kubernetes.
  • ‫80 היא יציאת המארח.
  • ‫HEALTHY מציין שהקצה העורפי תקין.

בשלב הבא, בודקים את שירות לקצה העורפי שמשויך ל-my-service באמצעות gcloud. מסננים לפי "drainingTimeoutSec" ו-"timeoutSec" כדי לוודא שהם הוגדרו במישור הבקרה של מאזן העומסים. Google Cloud לדוגמה:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

פלט:

  drainingTimeoutSec: 60
  timeoutSec: 40

אם רואים את drainingTimeoutSec ואת timeoutSec בפלט, זה אומר שהערכים שלהם הוגדרו בצורה נכונה דרך BackendConfig.

סידור וארגון

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

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

מגבלות של BackendConfig

יש מגבלות על BackendConfigs:

• רק זוג אחד (שירות, יציאה) יכול לצרוך רק BackendConfig אחד, גם אם כמה אובייקטים של Ingress מפנים אל (שירות, יציאה). כלומר, כל אובייקטי ה-Ingress שמפנים לאותו (שירות, יציאה) חייבים להשתמש באותה הגדרה עבור Cloud Armor, ‏ IAP ו-Cloud CDN.

• אי אפשר להפעיל את IAP ואת Cloud CDN באותו שירות לקצה העורפי של איזון עומסים ב-HTTP(S). המשמעות היא שאי אפשר להגדיר גם IAP וגם Cloud CDN באותו BackendConfig.

• כדי ליצור אינטראקציה עם BackendConfig, צריך להשתמש בגרסה kubectl 1.7 ואילך.

הסרת ההגדרה שצוינה ב-FrontendConfig או ב-BackendConfig

כדי לבטל תכונת Ingress, צריך להשבית באופן מפורש את הגדרת התכונה ב-CRD של FrontendConfig או BackendConfig. בקר Ingress מבצע התאמה רק של הגדרות שצוינו ב-CRD האלה.

כדי לנקות או להשבית הגדרה שהופעלה בעבר, צריך להגדיר את הערך של השדה למחרוזת ריקה ("") או לערך בוליאני false, בהתאם לסוג השדה.

במניפסט BackendConfig הבא מושבתים כללי מדיניות האבטחה של Google Cloud Armor ו-Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

מחיקה של FrontendConfig או BackendConfig

FrontendConfig

כדי למחוק FrontendConfig, פועלים לפי השלבים הבאים:

1. מסירים את השם של FrontendConfig מההערה networking.gke.io/v1beta1.FrontendConfig במניפסט של Ingress.

2. מחילים את מניפסט ה-Ingress ששונה על האשכול. לדוגמה, משתמשים ב-kubectl apply.

3. מחיקת FrontendConfig. לדוגמה, משתמשים ב-kubectl delete frontendconfig config my-frontendconfig.

זהירות: אל תמחקו אובייקט FrontendConfig לפני שתסירו את השם שלו מההערה networking.gke.io/v1beta1.FrontendConfig ותחילו את מניפסט ה-Ingress המעודכן. אם תעשו את זה, ההגדרה לא תוסר משירות לקצה העורפי של איזון העומסים ב-HTTP(S). בנוסף, השגיאות יוצגו כאובייקטים של Kubernetes ב-Ingress.

BackendConfig

כדי למחוק BackedConfig, פועלים לפי השלבים הבאים:

1. מסירים את השם של BackendConfig מההערה cloud.google.com/backend-config במניפסט של Service.

2. מחילים את מניפסט השירות ששונה על האשכול. לדוגמה, משתמשים ב-kubectl apply.

3. מוחקים את BackendConfig. לדוגמה, משתמשים ב-kubectl delete backendconfig my-backendconfig.

שימו לב: אל תמחקו אובייקט BackendConfig לפני שתסירו את השם שלו מההערה cloud.google.com/backend-config ותפעילו את מניפסט השירות המעודכן. אם תעשו את זה, ההגדרה לא תוסר משירות לקצה העורפי של איזון העומסים ב-HTTP(S). בנוסף, תוכלו לראות שגיאות כאירועי Kubernetes באובייקט Ingress.

פתרון בעיות

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

לא נמצא BackendConfig

השגיאה הזו מתרחשת כשמציינים BackendConfig ליציאת שירות בהערת השירות, אבל לא ניתן למצוא את משאב ה-BackendConfig בפועל.

כדי להעריך אירוע ב-Kubernetes, מריצים את הפקודה הבאה:

kubectl get event

פלט לדוגמה שמצביע על כך שלא נמצא BackendConfig:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

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

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

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

כדי להעריך אירוע ב-Kubernetes, מריצים את הפקודה הבאה:

kubectl get event

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

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

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

פתרון שגיאות מסדרה 500 באמצעות NEGs במהלך שינוי קנה מידה של עומסי עבודה ב-GKE

התסמין:

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

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

אבחון:

הסרת Pod ב-Kubernetes בלי להסיר את נקודת הקצה שלו ולהסיר אותו קודם מ-NEG מובילה לשגיאות מסדרה 500. כדי להימנע מבעיות במהלך סיום הפעולה של ה-Pod, צריך לשים לב לסדר הפעולות. בתמונות הבאות מוצגים תרחישים שבהם BackendService Drain Timeout לא מוגדר ו-BackendService Drain Timeout מוגדר עם BackendConfig.

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

תרחיש 1: הערך של BackendService Drain Timeout לא מוגדר.

בתמונה הבאה מוצג תרחיש שבו הערך של BackendService Drain Timeout לא מוגדר.

תרחיש 2: הערך של BackendService Drain Timeout מוגדר.

בתמונה הבאה מוצג תרחיש שבו הערך BackendService Drain Timeout מוגדר.

הזמן המדויק שבו מתרחשות השגיאות מסוג 500 תלוי בגורמים הבאים:

• זמן האחזור של ניתוק NEG API: זמן האחזור של ניתוק NEG API מייצג את הזמן הנוכחי שנדרש לסיום פעולת הניתוק ב- Google Cloud. הגורמים שמשפיעים על זה הם מגוונים ולא קשורים ל-Kubernetes, כולל סוג מאזן העומסים והאזור הספציפי.

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

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

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

פתרון אפשרי:

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

בתמונה הבאה אפשר לראות איך משאירים את ה-Pod פעיל באמצעות וו preStop:

כדי להימנע משגיאות מסדרה 500, מבצעים את השלבים הבאים:

1. מגדירים את BackendService Drain Timeout של השירות ל-1 דקה.

   הערה: אם זמן הבקשה הממוצע שלכם הוא יותר מ-30 שניות, כדאי לעיין במאמר בנושא התאמה אישית של הזמנים הקצובים לתפוגה כדי להתאים אישית את BackendService Drain Timeout.

   • משתמשי Ingress יכולים לעיין במאמר הגדרת פסק זמן ב-BackendConfig.

   • משתמשי Gateway יכולים לקרוא על הגדרת פסק הזמן ב-GCPBackendPolicy.

   • אם אתם מנהלים את BackendServices ישירות כשאתם משתמשים ב-Standalone NEGs, תוכלו לעיין במאמר בנושא הגדרת פסק זמן ישירות ב-Backend Service.

2. מאריכים את terminationGracePeriod בפוד.

   מגדירים את terminationGracePeriodSeconds ב-Pod ל-3.5 דקות. בשילוב עם ההגדרות המומלצות, ההגדרה הזו מאפשרת ל-Pods חלון של 30 עד 45 שניות לכיבוי מסודר אחרי שנקודת הקצה של ה-Pod הוסרה מ-NEG. אם אתם צריכים יותר זמן לסגירה מסודרת, אתם יכולים להאריך את תקופת החסד או לפעול לפי ההוראות שמפורטות בקטע התאמה אישית של פסק זמן.

   במניפסט של ה-Pod הבא מוגדר זמן קצוב לתפוגה של 210 שניות (3.5 דקות) לזמן להשלמת תהליך (connection draining):

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. החלת hook של preStop על כל מאגרי התגים.

   החלת וו preStop שיבטיח שה-Pod יפעל למשך 120 שניות נוספות בזמן שנקודת הקצה של ה-Pod מתרוקנת במאזן העומסים ונקודת הקצה מוסרת מה-NEG.

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

   spec:
     containers:
     - name: my-app
       ...
       lifecycle:
         preStop:
           exec:
             command: ["/bin/sh", "-c", "sleep 120s"]
     ...
   

התאמה אישית של פסק זמן

כדי להבטיח את המשכיות של ה-Pod ולמנוע שגיאות מסדרה 500, ה-Pod צריך להיות פעיל עד להסרת נקודת הקצה מה-NEG. כדי למנוע במיוחד שגיאות 502 ו-503, כדאי להטמיע שילוב של פסק זמן ו-preStophook.

הערה: אם הגדרת בדיקת התקינות מוגדרת לזיהוי מיידי של כשלים, יכול להיות שמאזני העומסים יפסיקו לשלוח בקשות מוקדם יותר, מה שעשוי להפחית את התדירות של שגיאות 503. עם זאת, חשוב לזכור ששגיאות 503 עדיין עשויות להתרחש במהלך משך הזמן של הסף הלא תקין. חשוב להבין שהגדרת בדיקות תקינות לא תמנע שגיאות 502, שמתרחשות כשחיבורים קיימים מסתיימים לפני הזמן.

כדי להאריך את משך הפעולה של ה-Pod במהלך תהליך ההשבתה, מוסיפים preStop hook ל-Pod. ה-hook‏ preStop מופעל לפני שמתקבל אות ליציאה מ-Pod, כך שאפשר להשתמש ב-hook‏ preStop כדי לשמור על הפעילות של ה-Pod עד שהנקודה המתאימה שלו מוסרת מ-NEG.

כדי להאריך את משך הזמן שבו ה-Pod נשאר פעיל במהלך תהליך הכיבוי, מוסיפים וו (hook) מסוג preStop להגדרת ה-Pod באופן הבא:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

הערה: ב-Pods עם כמה מאגרי תגים, חשוב להוסיף את ה-hook‏ preStop לכל מאגר תגים כדי שכל מאגרי התגים יישארו פעילים. רק קונטיינרים עם ה-hook פועלים, והשאר מפסיקים. אם אתם משתמשים בכלי שמוסיף מאגרי תגים, ודאו שגם למאגרי התגים שנוספו יש את preStop ה-hook

הנדרש.

אתם יכולים להגדיר פסק זמן והגדרות קשורות כדי לנהל את ההשבתה המבוקרת של ה-Pods במהלך צמצום של עומסי עבודה. אפשר לשנות את הגדרות הזמן הקצוב לתפוגה בהתאם לתרחישי שימוש ספציפיים. מומלץ להתחיל עם פרקי זמן ארוכים יותר להמתנה ואז לקצר אותם לפי הצורך. אפשר להתאים אישית את פסק הזמן על ידי הגדרת פרמטרים שקשורים לפסק זמן ו-hook של preStop באחת מהדרכים הבאות:

זמן קצוב לתפוגה של ניקוז שירות לקצה העורפי

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

אפשר להגדיר את הפרמטר Backend Service Drain Timeout באמצעות BackendConfig עם Ingress, ‏ GCPBackendPolicy עם Gateway או באופן ידני ב-BackendService עם NEGs עצמאיים. הזמן הקצוב לתפוגה צריך להיות ארוך פי 1.5 עד 2 מהזמן שנדרש לעיבוד הבקשה. כך, אם בקשה תתקבל ממש לפני תחילת הניקוז, היא תושלם לפני שהזמן הקצוב לתפוגה יסתיים. הגדרת הפרמטר Backend Service Drain Timeout לערך גדול מ-0 עוזרת לצמצם את מספר השגיאות 503, כי לא נשלחות בקשות חדשות לנקודות קצה שמתוזמנות להסרה. כדי שזמן קצוב לתפוגה זה יהיה אפקטיבי, עליך להשתמש בו עם ה-hook‏ preStop כדי לוודא שה-Pod יישאר פעיל בזמן ההתרוקנות. בלי השילוב הזה, בקשות קיימות שלא הושלמו יקבלו שגיאת 502.

preStop זמן הצפייה ברגע המושך

ה-hook‏ preStop צריך לעכב את השבתת ה-Pod מספיק זמן כדי שגם זמן האחזור של הניקוז וגם פסק הזמן של ניקוז שירות לקצה העורפי יושלמו. כך מובטח זמן להשלמת תהליך (connection draining) תקין והסרת נקודת הקצה מה-NEG לפני שה-Pod מושבת.

כדי לקבל תוצאות אופטימליות, צריך לוודא שpreStop זמן ההרצה של ה-hook גדול או שווה לסכום של Backend Service Drain Timeout ושל זמן האחזור של ההתרוקנות.

כדי לחשב את זמן ההפעלה האידיאלי של ה-hook, משתמשים בנוסחה הבאה:preStop

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

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

• ‫BACKEND_SERVICE_DRAIN_TIMEOUT: השעה שהגדרתם לBackend Service Drain Timeout.
• ‫DRAIN_LATENCY: זמן משוער של השהיית הניקוז. מומלץ להשתמש בדקה אחת כהערכה.

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

לחלופין, אפשר להעריך את התזמון על ידי בדיקת חותמת הזמן של המחיקה מה-Pod וחותמת הזמן שבה נקודת הקצה הוסרה מה-NEG ביומני הביקורת של Cloud.

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

צריך להגדיר את הפרמטר terminationGracePeriod כך שיהיה מספיק זמן עד שה-hook‏ preStop יסיים את הפעולה ועד שהפוד ישלים כיבוי תקין.

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

terminationGracePeriod >= preStop hook time + Pod shutdown time

כדי להגדיר את terminationGracePeriod בתצורה של ה-Pod באופן הבא:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

לא נמצא NEG כשיוצרים משאב Internal Ingress

יכול להיות שתקבלו את השגיאה הבאה כשאתם יוצרים Ingress פנימי ב-GKE:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

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

בסביבות של VPC משותף או באשכולות שמופעלת בהם מדיניות רשת, מוסיפים את ההערה cloud.google.com/neg: '{"ingress": true}' למניפסט של השירות.

‫504 Gateway Timeout: upstream request timeout

יכול להיות שתקבלו את השגיאה הבאה כשאתם ניגשים לשירות מ-Ingress פנימי ב-GKE:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

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

כדי לאפשר תעבורה מטווח תת-הרשת של שרת proxy בלבד, יוצרים כלל חומת אש ב-targetPort של השירות.

שגיאה 400: ערך לא תקין בשדה 'resource.target'

יכול להיות שתקבלו את השגיאה הבאה כשאתם ניגשים לשירות מ-Ingress פנימי ב-GKE:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

כדי לפתור את הבעיה, צריך ליצור רשת משנה לשרת proxy בלבד.

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

יכול להיות שתקבלו אחת מהשגיאות הבאות כשמישור הבקרה של GKE משודרג או כשמשנים אובייקט Ingress:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

או:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

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

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

בעיות מוכרות

אי אפשר להפעיל הפניות אוטומטיות ל-HTTPS באמצעות סכמת השמות V1 Ingress

אי אפשר להפעיל הפניות אוטומטיות ל-HTTPS במשאבי GKE Ingress שנוצרו בגרסאות GKE‏ 1.16.8-gke.12 ומטה. צריך ליצור מחדש את ה-Ingress כדי להפעיל הפניות אוטומטיות ל-HTTPS, אחרת נוצר אירוע שגיאה וה-Ingress לא מסתנכרן.

הודעת אירוע השגיאה דומה לזו:

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

השדות של כללי מדיניות האבטחה של Google Cloud Armor הוסרו מ-BackendConfig

יש בעיה ידועה שבזמן עדכון משאב BackendConfig באמצעות ה-API של v1beta1, מדיניות האבטחה הפעילה של Cloud Armor מוסרת מהשירות. הבעיה הזו משפיעה על גרסאות GKE הבאות:

• ‫1.18.19-gke.1400 עד 1.18.20-gke.5099
• ‫1.19.10-gke.700 עד 1.19.14-gke.299
• ‫1.20.6-gke.700 עד 1.20.9-gke.899

אם לא הגדרתם את Cloud Armor במשאבי ה-Ingress באמצעות BackendConfig, הבעיה הזו לא תשפיע על האשכולות שלכם.

באשכולות GKE שבהם מוגדר Cloud Armor באמצעות BackendConfig, מומלץ מאוד לעדכן משאבי BackendConfig רק באמצעות v1 API. החלת BackendConfig על האשכול באמצעות משאבי v1beta1BackendConfig תגרום להסרת מדיניות האבטחה של Cloud Armor מהשירות שאליו היא מפנה.

כדי לצמצם את הבעיה הזו, צריך לעדכן את BackendConfig רק באמצעות v1BackendConfig API. ‫v1 BackendConfig תומך בכל השדות שנתמכים ב-v1beta1, ולא חלים בו שינויים שעלולים לשבור את התאימות לאחור, כך שאפשר לעדכן את שדה ה-API באופן שקוף. מחליפים את השדה apiVersion בכל מניפסט פעיל של BackendConfig ב-cloud.google.com/v1, ולא משתמשים ב-cloud.google.com/v1beta1. במניפסט לדוגמה הבא מתואר משאב BackendConfig שמשתמש ב-v1API:

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

אם יש לכם מערכות או כלים של CI/CD שמעדכנים באופן קבוע משאבי BackendConfig, ודאו שאתם משתמשים בקבוצת cloud.google.com/v1 API במערכות האלה.

אם כבר עדכנתם את BackendConfig באמצעות v1beta1 API, יכול להיות שמדיניות האבטחה של Cloud Armor הוסרה. כדי לבדוק אם זה קרה, מריצים את הפקודה הבאה:

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

אם התשובה מחזירה פלט, המשמעות היא שהבעיה משפיעה על האשכול. הפלט של הפקודה הזו מחזיר רשימה של משאבי BackendConfig ‏(<namespace>/<name>) שהושפעו מהבעיה. אם הפלט ריק, סימן שה-BackendConfig לא עודכן באמצעות v1beta1 API מאז שהבעיה התחילה. כל עדכון עתידי של BackendConfig צריך להתבצע רק באמצעות v1.

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

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

אם אחד מהאשכולות שלכם הושפע, אפשר לתקן את זה על ידי שליחת עדכון למשאב BackendConfig שמשתמש ב-API‏ v1.

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

• ‫1.18.20-gke.5100 ואילך
• ‫1.19.14-gke.300 ואילך
• ‫1.20.9-gke.900 ואילך

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

• ‫GKE Ingress לאיזון עומסים באשכול יחיד.

• מדריך בנושא Ingress לפריסת ניתוב HTTP(S) לאפליקציות GKE

• הטמעה של GKE Ingress עם בדיקת תקינות HTTP בהתאמה אישית