סקירה כללית
בדף הזה מופיע מדריך מקיף להגדרת Kubernetes Ingress ב-Google Cloud. בדף הזה מוסבר איך להשתמש במשאבים מותאמים אישית של FrontendConfig כדי לנהל תכונות של קצה קדמי כמו מדיניות SSL והפניות אוטומטיות של HTTPS, ובמשאבים מותאמים אישית של BackendConfig כדי לכוונן הגדרות של בק-אנד כמו זמן קצוב לתפוגה של שירות, Cloud CDN, מדיניות אבטחה של Google Cloud Armor ו-Identity-Aware Proxy (IAP).
סקירה כללית של היכולות האלה ושל הארכיטקטורה הבסיסית של GKE Ingress מופיעה במאמרים הבאים:
הדף הזה מיועד למומחי רשתות שתפקידם לתכנן את הרשת של הארגון, להתקין ציוד רשת, להגדיר אותו ולתת לו תמיכה. כדי לקבל מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בGoogle Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.
השוואה בין תכונות
בטבלה הבאה מפורטת רשימה של תכונות נתמכות ל-Ingress ב- Google Cloud. מוצגת גם הזמינות של התכונה, זמינות לכלל המשתמשים (GA) או בטא.
בהתכונה הזו זמינה בגרסת בטא החל מהגרסה שצוינה. תכונות שלא מצוינת לגביהן גרסה נתמכות בכל הגרסאות הזמינות של 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 ו-BackendConfig חולקים את אותו מחזור חיים כמו משאבי ה-Ingress וה-Service התואמים שלהם, ולרוב הם נפרסים יחד.
התרשים הבא מדגים איך:
הערה באובייקט Ingress או MultiClusterIngress מפנה אל CRD של FrontendConfig. ה-CRD FrontendConfig מפנה אל Google Cloud מדיניות SSL.
הערה באובייקט Service או MultiClusterService מפנה אל BackendConfig CRD. ה-CRD BackendConfig מציין הגדרות מותאמות אישית לבדיקת תקינות של שירות הקצה העורפי התואם.
שיוך של 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 Controller יוצר שירות קצה עורפי של מאזן עומסים כדי להפנות לאחת מהיציאות של Service, הוא משתמש באותו 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 של Service יכולה להתייחס לשם היציאה (spec.ports[].name) או למספר היציאה (spec.ports[].port). -
SERVICE_REFERENCE_B: משתמשים בערךPORT_NUMBER_2אוPORT_NAME_2. הסיבה לכך היא שההערה BackendConfig של Service יכולה להתייחס לשם היציאה (spec.ports[].name) או למספר היציאה (spec.ports[].port).
כשמתייחסים ליציאה של השירות לפי מספר, צריך להשתמש בערך port במקום בערך targetPort. מספר היציאה שמשמש כאן הוא רק לקישור BackendConfig. הוא לא שולט ביציאה שאליה מאזן העומסים שולח תנועה או בדיקות תקינות:
כשמשתמשים באיזון עומסים מובנה בקונטיינר, מאזן העומסים שולח תנועה לנקודת קצה בקבוצת נקודות קצה ברשת (שמתאימה לכתובת IP של Pod) ביציאת השירות שאליה מתבצעת ההפניה
targetPort(שחייבת להתאים ל-containerPortשל Pod שמשרת תנועה). אחרת, מאזן העומסים שולח תעבורה לכתובת ה-IP של צומת ביציאת השירות שאליה מתייחסיםnodePort.כשמשתמשים ב-BackendConfig כדי לספק בדיקת תקינות מותאמת אישית למאזן העומסים, מספר היציאה שמשמש לבדיקת התקינות של מאזן העומסים יכול להיות שונה ממספר
spec.ports[].portשל השירות. פרטים על מספרי יציאות לבדיקות תקינות מופיעים במאמר הגדרה של בדיקות תקינות בהתאמה אישית.
הגדרה של תכונות Ingress באמצעות פרמטרים של FrontendConfig
בקטע הבא מוסבר איך להגדיר את FrontendConfig כדי להפעיל תכונות ספציפיות של Ingress.
מדיניות SSL
מדיניות SSL מאפשרת לכם לציין קבוצה של גרסאות TLS וצפנים שמאזן העומסים משתמש בהם כדי לסיים תעבורת HTTPS מלקוחות. קודם צריך ליצור מדיניות SSL מחוץ ל-GKE. אחרי שיוצרים את ה-CRD, אפשר להפנות אליו ב-FrontendConfig CRD.
השדה sslPolicy ב-FrontendConfig מפנה לשם של מדיניות SSL באותו פרויקט sslPolicyשבו נמצא אשכול GKE. Google Cloud הוא מצרף את מדיניות ה-SSL לשרת ה-proxy של HTTPS,
שנוצר עבור מאזן העומסים החיצוני מסוג HTTP(S) על ידי Ingress. אפשר להפנות לכמה משאבי Ingress לאותו משאב FrontendConfig ולאותה מדיניות SSL. אם משנים מדיניות SSL שמפנים אליה, השינוי מועבר אל Google Front Ends (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.
במניפסט הבא של 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_CODEו-NEGATIVE_CACHING_TTL: הגדרת negative caching. מידע נוסף זמין במאמר בנושא שימוש בשמירה שלילית במטמון. -
REQ_COALESCING: אם הערך מוגדר ל-true, ההסתרה מופעלת. מידע נוסף זמין במאמר בנושא איחוד בקשות. -
SERVE_WHILE_STALE: משך הזמן, בשניות, אחרי שתוקף התגובה פג, שבו Cloud CDN ממשיך להציג גרסה לא עדכנית. מידע נוסף זמין במאמר בנושא הצגת תוכן מיושן. -
SIGNED_MAX_AGE: משך הזמן המקסימלי שבו אפשר לשמור תשובות במטמון, בשניות. מידע נוסף זמין במאמר בנושא התאמה אישית של זמן השהייה המקסימלי במטמון. -
KEY_NAME, KEY_VALUEו-SECRET_NAME: הגדרת מפתח של כתובת URL חתומה. מידע נוסף זמין במאמר בנושא יצירת מפתחות לבקשות חתומות.
כדי לראות דוגמה לפריסת Cloud CDN דרך Ingress, ואז לאימות שתוכן האפליקציה נשמר במטמון, מרחיבים את הקטע הבא.
הזמן הקצוב לתפוגה של ניתוק החיבור
אפשר להגדיר זמן קצוב לתפוגה של ניתוק חיבורים באמצעות BackendConfig. הזמן הקצוב לתפוגה של זמן להשלמת תהליך הוא הזמן, בשניות, להמתנה עד להשלמת התהליך. במהלך משך הזמן שצוין של זמן קצוב לתפוגה, הבקשות הקיימות לשרת העורפי שהוסר מקבלות זמן להשלמה. מאזן העומסים לא שולח בקשות חדשות לעורף הקצה שהוסר. אחרי שמגיעים למשך הזמן הקצוב לתפוגה, כל החיבורים שנותרו לשרת העורפי נסגרים. משך הזמן הקצוב לתפוגה יכול להיות בין 0 ל-3,600 שניות. ערך ברירת המחדל הוא 0, שגם משבית את זמן להשלמת תהליך (connection draining).
במניפסט BackendConfig הבא מוגדר פסק זמן של 60 שניות לניתוק החיבורים:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
connectionDraining:
drainingTimeoutSec: 60
הגדרת בדיקת תקינות בהתאמה אישית
יש מגוון דרכים שבהן GKE מגדיר בדיקות תקינות שלGoogle Cloud מאזן עומסים כשמבצעים פריסה דרך Ingress. מידע נוסף על פריסת בדיקות תקינות ב-GKE Ingress זמין במאמר בדיקות תקינות של Ingress.
ה-BackendConfig מאפשר לכם לשלוט במדויק בהגדרות של בדיקת תקינות מאזן העומסים.
אפשר להגדיר כמה שירותי 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 שמשרת את התוכן ביציאה שאתם מציינים.לדוגמה, עבור קצוות עורפיים של קבוצות, צריך לבחור יציאה שתואמת ל-
nodePortexposed by the Service. לאחר מכן, מערכות בדיקת תקינות מתחברות לכל צומת ביציאה הזו.
כדי להגדיר GKE Ingress עם בדיקת תקינות HTTP מותאמת אישית, אפשר לעיין במאמר בנושא GKE Ingress עם בדיקת תקינות HTTP מותאמת אישית.
מדיניות אבטחה של תעבורת נתונים נכנסת (ingress) ב-Google Cloud Armor
כללי מדיניות האבטחה של 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"
שני מקורות מידע אמינים
למרות שההגדרה מתבצעת דרך 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 |
null |
ב-GKE Ingress Controller נעשה שימוש בהגדרה שנקבעה באובייקט BackendService שהוגדר באמצעות Compute Engine API באמצעות Google Cloud המסוף, ה-CLI של gcloud או Terraform. |
כדי להגדיר GKE Ingress עם הגנה של Google Cloud Armor, אפשר לעיין במאמר Google Cloud Armor enabled Ingress.
רישום ביומן הגישה של HTTP
שער הכניסה יכול לרשום ביומן את כל בקשות ה-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 עבור Identity-Aware Proxy IAP, צריך לציין את הערכים enabled ו-secretName בבלוק iap ב-BackendConfig. כדי לציין את הערכים האלה, צריך לוודא שלסוכן השירות של GKE יש את ההרשאה compute.backendServices.update.
המניפסט הבא של 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, אל תציינו את oauthclientCredentials ב-BackendConfig. למשתמשים שכבר הגדירו את IAP באמצעות oauthclientCredentials, אין נתיב העברה למעבר לשימוש בלקוח OAuth שמנוהל על ידי Google: צריך ליצור מחדש את ה-Backend (להסיר את השירות מה-Ingress ולצרף אותו מחדש). מומלץ לבצע את הפעולה הזו במהלך חלון זמן לתחזוקה, כי היא תגרום לזמן השבתה. אפשר לבצע את ההעברה בכיוון ההפוך, כלומר לעבור מלקוח OAuth שמנוהל על ידי Google אל oauthclientCredentials.
מניפסט BackendConfig הבא מאפשר שימוש בשרת proxy לאימות זהויות (IAP) עם לקוח OAuth שמנוהל על ידי Google:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
iap:
enabled: true
הוראות מלאות זמינות במאמר בנושא הפעלת IAP ל-GKE במסמכי התיעוד של IAP.
שרת proxy לאימות זהויות (IAP) עם תעבורת נתונים נכנסת (ingress) פנימית
כדי להגדיר Ingress פנימי ל-IAP, צריך להשתמש במסלול פרימיום. אם אתם לא משתמשים במסלול פרימיום, אתם לא יכולים להציג או ליצור מאזני עומסים פנימיים של אפליקציות עם שרת proxy לאימות זהויות (IAP). כדי להשתמש ב-Ingress פנימי עבור IAP, צריך גם מינוי ל-Chrome Enterprise Premium.
כדי להגדיר GKE Ingress מאובטח עם אימות מבוסס-שרת proxy לאימות זהויות (IAP), אפשר לעיין בדוגמה IAP enabled ingress.
זיקה לסשן (session affinity)
אפשר להשתמש ב-BackendConfig כדי להגדיר זיקה לסשן (session affinity) לכתובת IP של לקוח או לקובץ Cookie שנוצר.
זיקה לכתובת 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 שנוצר וערך ה-TTL של קובצי ה-Cookie הוא 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}"
כותרות תגובה מותאמות אישית
כדי להפעיל כותרות תגובה מותאמות אישית, מציינים רשימה של כותרות במאפיין 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, מבצעים את המשימות הבאות:
- יצירת פריסה.
- יוצרים BackendConfig.
- יוצרים שירות ומשייכים אחת מהיציאות שלו ל-BackendConfig.
- יוצרים Ingress ומשייכים אותו לצמד (שירות, יציאה).
- מאמתים את המאפיינים של שירות לקצה העורפי.
- ניקוי.
יצירת פריסה
לפני שיוצרים 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 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-serviceKubernetes Service.-
k8s1-27fde173הוא גיבוב שמשמש לתיאור האוסף. -
defaultהוא מרחב השמות של Kubernetes. -
HEALTHYמציין שהקצה העורפי תקין.
-
"k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"מספק מידע על שירות הקצה העורפי שמשויך לקצה העורפי שמוגדר כברירת מחדל (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, צריך להשתמש בגרסה
kubectl1.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, פועלים לפי השלבים הבאים:
מסירים את השם של FrontendConfig מההערה
networking.gke.io/v1beta1.FrontendConfigבמניפסט של Ingress.מחילים את מניפסט ה-Ingress ששונה על האשכול. לדוגמה, משתמשים ב-
kubectl apply.מחיקת FrontendConfig. לדוגמה, משתמשים ב-
kubectl delete frontendconfig config my-frontendconfig.
BackendConfig
כדי למחוק BackedConfig, פועלים לפי השלבים הבאים:
מסירים את השם של BackendConfig מההערה
cloud.google.com/backend-configבמניפסט של Service.מחילים את מניפסט השירות ששונה על האשכול. לדוגמה, משתמשים ב-
kubectl apply.מוחקים את BackendConfig. לדוגמה, משתמשים ב-
kubectl delete backendconfig my-backendconfig.
פתרון בעיות
אפשר לזהות טעויות נפוצות בהגדרות באמצעות כלי האבחון של 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 שגיאות מתרחשות כאשר תרמילים מסתיימים לפני שחיבורים קיימים נסגרים, בעוד שגיאות 503 מתרחשות כאשר התנועה מופנית לתרמילים שנמחקו.
הבעיה הזו יכולה להשפיע על אשכולות אם אתם משתמשים במוצרים של GKE לניהול איזון עומסים שמשתמשים ב-NEGs, כולל Gateway, Ingress ו-NEGs עצמאיים. אם אתם משנים את גודל עומסי העבודה לעיתים קרובות, הסיכון שהאשכול יושפע גבוה יותר.
אבחון:
הסרה של Pod ב-Kubernetes בלי לנקז את נקודת הקצה שלו ולהסיר אותו קודם מ-NEG מובילה לשגיאות מסדרה 500. כדי להימנע מבעיות במהלך סיום הפעולה של ה-Pod, צריך לשים לב לסדר הפעולות. בתמונות הבאות מוצגים תרחישים שבהם BackendService Drain Timeout לא מוגדר ו-BackendService Drain Timeout מוגדר עם BackendConfig.
תרחיש 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 שצריך להגדיר בהגדרת עומס העבודה.
פתרון אפשרי:
כדי למנוע את שגיאות 5XX, צריך להחיל את ההגדרות הבאות. ערכי הזמן הקצוב לתפוגה הם בגדר הצעה, ויכול להיות שתצטרכו להתאים אותם לאפליקציה הספציפית שלכם. בקטע הבא מפורט תהליך ההתאמה האישית.
בתמונה הבאה אפשר לראות איך משאירים את ה-Pod פעיל באמצעות hook של preStop:
כדי להימנע משגיאות מסדרה 500, מבצעים את השלבים הבאים:
מגדירים את
BackendService Drain Timeoutשל השירות לדקה אחת.משתמשי Ingress יכולים לעיין במאמר הגדרת פסק זמן ב-BackendConfig.
משתמשי Gateway יכולים לקרוא על הגדרת פסק הזמן ב-GCPBackendPolicy.
אם אתם מנהלים את BackendServices ישירות כשאתם משתמשים ב-Standalone NEGs, תוכלו לעיין במאמר בנושא הגדרת זמן קצוב לתפוגה ישירות ב-Backend Service.
מאריכים את
terminationGracePeriodב-Pod.מגדירים את
terminationGracePeriodSecondsב-Pod ל-3.5 דקות. בשילוב עם ההגדרות המומלצות, ההגדרה הזו מאפשרת ל-Pods חלון של 30 עד 45 שניות לכיבוי מסודר אחרי שנקודת הקצה של ה-Pod הוסרה מ-NEG. אם אתם צריכים יותר זמן לסגירה מסודרת, אתם יכולים להאריך את תקופת החסד או לפעול לפי ההוראות שמפורטות בקטע התאמה אישית של פסק זמן.במניפסט של ה-Pod הבא מוגדר זמן קצוב לתפוגה של 210 שניות (3.5 דקות) לריקון החיבורים:
spec: terminationGracePeriodSeconds: 210 containers: - name: my-app ... ...החלת וו (hook) של
preStopעל כל מאגרי התגים.החלת וו
preStopשיבטיח שה-Pod יפעל למשך 120 שניות נוספות בזמן שנקודת הקצה של ה-Pod מתרוקנת במאזן העומסים ונקודת הקצה מוסרת מ-NEG.spec: containers: - name: my-app ... lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 120s"] ...
התאמה אישית של פסק זמן
כדי להבטיח את המשכיות של ה-Pod ולמנוע שגיאות מסדרה 500, ה-Pod צריך להיות פעיל עד להסרת נקודת הקצה מה-NEG. כדי למנוע שגיאות 502 ו-503, מומלץ להטמיע שילוב של פסק זמן ו-preStop hook.
כדי להאריך את משך הפעולה של ה-Pod במהלך תהליך ההשבתה, מוסיפים ל-Pod preStop hook. ה-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>"]
אתם יכולים להגדיר פסק זמן והגדרות קשורות כדי לנהל את ההשבתה המבוקרת של יחידות Pod במהלך צמצום של עומסי עבודה. אפשר לשנות את הגדרות הזמן הקצוב לתפוגה בהתאם לתרחישי שימוש ספציפיים. מומלץ להתחיל עם פסק זמן ארוך יותר ולקצר את משך הזמן לפי הצורך. אפשר להתאים אישית את פסק הזמן על ידי הגדרת פרמטרים שקשורים לפסק הזמן וה-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 מספיק זמן כדי לאפשר את השלמת זמן האחזור של הניקוז ואת פסק הזמן של ניקוז שירות ה-Backend, וכך לוודא שמתבצע ניקוז תקין של החיבורים והסרת נקודת הקצה מה-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 ולסיום תקין של ה-Pod.
כברירת מחדל, אם לא מגדירים את הערך במפורש, הערך של 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 עבור מאזני עומסים פנימיים של אפליקציות דורש קבוצות של נקודות קצה ברשת (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
upstream 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 שמשתמש ב-API v1:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backend-config
spec:
securityPolicy:
name: "ca-how-to-security-policy"
אם יש לכם מערכות או כלים של CI/CD שמעדכנים באופן קבוע משאבי BackendConfig, ודאו שאתם משתמשים בקבוצת ה-API cloud.google.com/v1 במערכות האלה.
אם כבר עדכנתם את 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 ואילך