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

הגדרת משאבי Gateway באמצעות מדיניות

בדף הזה מוסבר איך להגדיר את מאזן העומסים ש-Google Kubernetes Engine ‏ (GKE) יוצר כשפורסים שער באשכול GKE.

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

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים של Autopilot או Standard. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

דרישות של GKE Gateway controller

‫Gateway API נתמך רק באשכולות VPC-native.
אם אתם משתמשים ב-GatewayClasses אזוריים או חוצי-אזורים, אתם צריכים להפעיל רשת משנה ל-proxy בלבד.
צריך להפעיל את התוסף HttpLoadBalancing באשכול.
אם אתם משתמשים ב-Istio, אתם צריכים לשדרג את Istio לאחת מהגרסאות הבאות:
- גרסה 1.15.2 ואילך
- ‫1.14.5 ואילך
- גרסה 1.13.9 ואילך.
אם משתמשים ב-VPC משותף, צריך להקצות את התפקיד Compute Network User לחשבון השירות של GKE בפרויקט המארח של פרויקט השירות.

הגבלות

בנוסף להגבלות והמגבלות של בקר GKE Gateway, המגבלות הבאות חלות ספציפית על מדיניות שמוחלת על משאבי Gateway:

אפשר לצרף משאבי GCPGatewayPolicy רק אל gateway.networking.k8s.io Gateway.
המשאבים GCPGatewayPolicy צריכים להיות באותו מרחב שמות כמו היעד Gateway.
כשמשתמשים בשער של אשכול יחיד, GCPBackendPolicy, משאבי HealthCheckPolicy צריכים להפנות למשאב Service.
כשמשתמשים בשער (Gateway) מרובה אשכולות, GCPBackendPolicy ו-HealthCheckPolicy, המשאבים צריכים להתייחס למשאב ServiceImport.
אפשר לצרף רק GCPBackendPolicy אחד לשירות בכל רגע נתון. כשיוצרים שתי מדיניות GCPBackendPolicy שמכוונות לאותו Service או ServiceImport, המדיניות הישנה יותר מקבלת עדיפות והמדיניות השנייה לא מצורפת.
אין תמיכה במדיניות היררכית ב-GKE Gateway.
המשאבים HealthCheckPolicy ו-GCPBackendPolicy צריכים להיות באותו מרחב שמות כמו משאב היעד Service או ServiceImport.
המשאבים של GCPBackendPolicy ושל HealthCheckPolicy בנויים כך שהם יכולים להפנות רק לשירות קצה עורפי אחד.
הפונקציה GCPBackendPolicy לא תומכת באפשרויות HEADER_FIELD או HTTP_COOKIE עבור שיוך סשן.
כשמשתמשים בשערי כניסה עם היקפים שונים (כמו חיצוני גלובלי ופנימי אזורי), אי אפשר להשתמש באותו קצה עורפי Service אם שערי הכניסה דורשים הגדרות שונות באמצעות GCPBackendPolicy. לדוגמה, אי אפשר להחיל GCPBackendPolicy גלובלי על שער בהיקף אזורי, ולהפך. מומלץ ליצור Service נפרד לכל היקף של שער, כדי לוודא שכל Service מוגדר עם המדיניות המתאימה להיקף הספציפי.

הגדרת גישה גלובלית לשער פנימי אזורי

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

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

קובץ המניפסט GCPGatewayPolicy הבא מאפשר גישה גלובלית לשער פנימי אזורי:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

הגדרת האזור בשער מרובה אשכולות

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.30.3-gke.1225000 ואילך.

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

כדי להגדיר אזור לשער מרובה אשכולות, משתמשים בשדה region ב-GCPGatewayPolicy. בדוגמה הבאה, השער מוגדר באזור us-central1:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

הגדרת כללי מדיניות SSL כדי לאבטח את התנועה מלקוח למאזן עומסים

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

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

חשוב ליצור מדיניות SSL לפני שמפנים למדיניות ב-GCPGatewayPolicy.

המניפסט הבא GCPGatewayPolicy מציין מדיניות אבטחה בשם gke-gateway-ssl-policy:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

הגדרת בדיקות תקינות

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

כברירת מחדל, בשירותי קצה עורפיים שמשתמשים בפרוטוקולי האפליקציה HTTP או kubernetes.io/h2c, בדיקת תקינות היא מסוג HTTP. עבור פרוטוקול HTTPS, בדיקת בריאות ברירת המחדל היא מסוג HTTPS. בפרוטוקול HTTP2, בדיקת בריאות ברירת המחדל היא מסוג HTTP2.

אתם יכולים להשתמש ב-HealthCheckPolicy כדי לשלוט בהגדרות של בדיקת התקינות של מאזן העומסים. לכל סוג של בדיקת תקינות (http, ‏https, ‏grpc, ‏http2 ו-tcp) יש פרמטרים שאפשר להגדיר.‏ Google Cloudיוצר בדיקת תקינות ייחודית לכל שירות לקצה העורפי עבור כל שירות GKE.

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

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

שירות

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

‫INTERVAL: מציין את check-interval, בשניות, לכל בודק בדיקות תקינות. זהו הזמן שחלף מתחילת הבדיקה של בודק אחד ועד לתחילת הבדיקה הבאה שלו. אם לא מציינים את הפרמטר הזה, ערך ברירת המחדל הוא 15 שניות אם לא מציינים את HealthCheckPolicy, ו-5 שניות אם מציינים את HealthCheckPolicy בלי ערך checkIntervalSec. Google Cloud מידע נוסף זמין במאמר בנושא בדיקות מרובות ותדירות.
‫TIMEOUT: מציין את משך הזמן שבוGoogle Cloud ממתין לתגובה לבקשה לבדיקת תקינות (probe). הערך של TIMEOUT חייב להיות קטן מהערך של INTERVAL או שווה לו. היחידות הן שניות. כל בקשה לבדיקת תקינות (probe) דורשת קוד תגובה HTTP 200 (OK) שיועבר לפני זמן קצוב לתפוגה של הבדיקה.
‫HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD: מציינים את מספר הניסיונות הרצופים ליצירת חיבור שצריכים להצליח או להיכשל, לפחות עבור בודק אחד, כדי לשנות את מצב התקינות מ'תקין' ל'לא תקין' או מ'לא תקין' ל'תקין'. אם משמיטים אחד מהפרמטרים האלה, ברירת המחדל היא 2. Google Cloud
‫PROTOCOL: מציין פרוטוקול שמשמש את מערכות הבדיקה לבדיקת תקינות. מידע נוסף זמין במאמרים קריטריונים להצלחה עבור HTTP,‏ HTTPS ו-HTTP/2,‏ קריטריונים להצלחה עבור gRPC וקריטריונים להצלחה עבור TCP. חובה לכלול את הפרמטר הזה.
‫ENABLED: מציין אם הרישום ביומן מופעל או מושבת.
‫PORT_SPECIFICATION: מציין אם בדיקת תקינות משתמשת ביציאה קבועה (USE_FIXED_PORT), ביציאה עם שם (USE_NAMED_PORT) או ביציאת שרת (USE_SERVING_PORT). אם לא מצוין, בדיקת התקינות פועלת בהתאם להתנהגות שצוינה בשדה port. אם לא מציינים את port, ערך ברירת המחדל של השדה הזה הוא USE_SERVING_PORT.
‫PORT: HealthCheckPolicy תומך רק בציון היציאה של בדיקת תקינות מאזן העומסים באמצעות מספר יציאה. אם לא מציינים את הפרמטר הזה, Google Cloud ברירת המחדל היא 80. מאזן העומסים שולח בדיקות לכתובת ה-IP של ה-Pod ישירות, ולכן צריך לבחור יציאה שתואמת ל-containerPort של קבוצות Pod שמספקות שירות, גם אם containerPort מפנה ל-targetPort של השירות. אתם לא מוגבלים ל-containerPorts שאליהם מתייחס targetPort של שירות.
‫HOST: הערך של כותרת המארח בבקשת בדיקת תקינות. הערך הזה מוגדר לפי RFC 1123 של שם מארח, אבל אי אפשר להשתמש בכתובות IP מספריות. אם לא מציינים ערך או משאירים את השדה ריק, ערך ברירת המחדל הוא כתובת ה-IP של בדיקת תקינות.
‫REQUEST: מציין את נתוני האפליקציה שיישלחו אחרי יצירת חיבור TCP. אם לא מציינים ערך, ברירת המחדל היא ערך ריק. אם הבקשה והתשובה ריקות, החיבור שנוצר מעיד על תקינות. הנתונים בבקשה יכולים להיות רק בפורמט ASCII.
‫REQUEST_PATH: מציין את נתיב הבקשה של בקשת בדיקת תקינות. אם לא מציינים ערך או משאירים את השדה ריק, ברירת המחדל היא /.
‫RESPONSE: מציין את הבייטים שצריך להתאים לתחילת נתוני התגובה. אם לא מציינים ערך או משאירים את השדה ריק, מערכת GKE מפרשת כל תגובה כהתקינה. נתוני התגובה יכולים להיות רק בפורמט ASCII.
‫PROXY_HEADER: מציין את סוג הכותרת של שרת ה-proxy. אפשר להשתמש ב-NONE או ב-PROXY_V1. ברירת המחדל היא NONE.
‫GRPC_SERVICE_NAME: שם אופציונלי של שירות gRPC. כדי לציין את כל השירותים, משמיטים את השדה הזה.

מידע נוסף על השדות של HealthCheckPolicy זמין healthChecks במאמר בנושא הפניה.

הגדרת מדיניות אבטחה לקצה העורפי ב-Cloud Armor כדי לאבטח את שירותי הקצה העורפי

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

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

חשוב לוודא שיצרתם מדיניות אבטחה של קצה עורפי ב-Cloud Armor לפני שאתם מפנים למדיניות ב-GCPBackendPolicy. אם מפעילים שער אזורי, צריך ליצור כללי מדיניות אזוריים לאבטחת עורף השרת ב-Cloud Armor.

בGCPBackendPolicy מניפסט הבא מוגדרת מדיניות אבטחה של קצה עורפי בשם example-security-policy:

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

הגדרת IAP

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

שרת proxy לאימות זהויות (IAP) אוכף מדיניות של בקרת גישה בשירותי בק-אנד שמשויכים ל-HTTPRoute. האכיפה הזו מאפשרת רק למשתמשים מאומתים או לאפליקציות עם התפקיד הנכון בניהול הזהויות והרשאות הגישה (IAM) לגשת לשירותי הקצה העורפי האלה.

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

כדי להגדיר את IAP עם Gateway:

מפעילים את IAP ל-GKE לא מגדירים את ה-backend (הגדרת BackendConfig) כי BackendConfig תקף רק במקרה של פריסת Ingress.
יוצרים סוד לרכישות מתוך האפליקציה:
1. נכנסים לדף Credentials במסוף Google Cloud :
  
  כניסה לדף Credentials
2. לוחצים על שם הלקוח ומורידים את קובץ לקוח ה-OAuth.
3. מעתיקים את סוד ה-OAuth ללוח הגזירה מקובץ לקוח ה-OAuth.
4. יוצרים קובץ בשם iap-secret.txt.
5. מדביקים את סוד ה-OAuth בקובץ iap-secret.txt באמצעות הפקודה הבאה:
```
echo -n CLIENT_SECRET > iap-secret.txt
kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
```

כדי לציין מדיניות IAP שמתייחסת ל-Secret:

יוצרים את קובץ המניפסט GCPBackendPolicy הבא, מחליפים את SECRET_NAME ואת CLIENT_ID בהתאם. שומרים את קובץ המניפסט בשם backend-policy.yaml:

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

החלת מניפסט backend-policy.yaml:
```
kubectl apply -f backend-policy.yaml
```

אימות ההגדרה:

אחרי שיוצרים את GCPBackendPolicy עם רכישות מתוך האפליקציה, צריך לוודא שהמדיניות הוחלה:
```
kubectl get gcpbackendpolicy
```
הפלט אמור להיראות כך:
```
NAME             AGE
backend-policy   45m
```

כדי לקבל פרטים נוספים, משתמשים בפקודה describe:

kubectl describe gcpbackendpolicy

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

Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPBackendPolicy "default/backend-policy" was a success

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

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

במניפסט GCPBackendPolicy הבא מוגדר זמן קצוב לתפוגה של שירות קצה עורפי של 40 שניות. ברירת המחדל של השדה timeoutSec היא 30 שניות.

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

הגדרת בחירת הקצה העורפי באמצעות `GCPBackendPolicy`

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

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

המערך customMetrics[], בשדה backends[], מכיל את השדות הבאים:

‫name: מציין את השם המוגדר על ידי המשתמש של המדד המותאם אישית.
‫maxUtilization: הגדרת יעד או ניצול מקסימלי למדד הזה. הטווח התקין הוא [0, 100].
‫dryRun: שדה בוליאני. אם הערך הוא true, נתוני המדד מדווחים ל-Cloud Monitoring, אבל לא משפיעים על החלטות איזון העומסים.

דוגמה

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

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

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  # Attach to the super-service Service.
  targetRef:
    kind: Service
    name: super-service
  default:
    backends:
    # Configuration for all locations.
    - location: "*"
      # Use the rate balancing mode for the load balancer.
      balancingMode: RATE
      # Maximum number of requests per second for each endpoint.
      maxRatePerEndpoint: 9000
    # Configuration for us-central1-a
    - location: us-central1-a
      # maxRatePerEndpoint: 9000 inherited from the * configuration.
      # Use the custom metrics balancing mode for the load balancer.
      balancingMode: CUSTOM_METRICS
      # Configure the custom metrics for the load balancer to use.
      customMetrics:
      - name: gpu-load
        maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [0.0, 1.0]
        dryRun: false

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-backend-policy.yaml
```

מאזן העומסים מחלק את התנועה על סמך מצב האיזון RATE והמדד המותאם אישית gpu-load.

הגדרת ניתוב ברמת נקודת הקצה באמצעות GCPTrafficDistributionPolicy

‫GCPTrafficDistributionPolicy מגדיר את אלגוריתם איזון העומסים לבחירת נקודת קצה בקצה העורפי. כשבוחרים באפשרות WEIGHTED_ROUND_ROBIN, מאזן העומסים משתמש במשקלים שנגזרים ממדדים מדווחים (כולל מדדים מותאמים אישית) כדי להפיץ את התנועה למופעים או לנקודות קצה נפרדים.

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

המערך customMetrics[] בתוך ההגדרה GCPTrafficDistributionPolicy מכיל את השדות הבאים:

‫name: מציין את השם המוגדר על ידי המשתמש של המדד המותאם אישית.
‫dryRun: שדה בוליאני. אם הערך הוא true, נתוני המדדים מדווחים ל-Cloud Monitoring אבל לא משפיעים על איזון העומסים.

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

דוגמה

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

שומרים את קובץ המניפסט לדוגמה הבא בשם GCPTrafficDistributionPolicy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: echoserver-v2
  namespace: team1
spec:
  targetRefs:
  # Attach to the echoserver-v2 Service in the cluster.
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    # Use custom metrics to distribute traffic across endpoints.
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    # Configure metrics from an ORCA load report to use for traffic
    # distribution.
    customMetrics:
    - name: orca.named_metrics.bescm11
      dryRun: false
    - name: orca.named_metrics.bescm12
      dryRun: true

מחילים את המניפסט על האשכול:

kubectl apply -f GCPTrafficDistributionPolicy.yaml

מאזן העומסים מפזר את התנועה לנקודות קצה על סמך WEIGHTED_ROUND_ROBINהאלגוריתם, ועל סמך המדדים המותאמים אישית שסופקו.

הגדרת זיקה לסשן

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

אפשר להגדיר זיקה לסשן (session affinity) על סמך הקריטריונים הבאים:

כתובת ה-IP של הלקוח
קובץ Cookie שנוצר

כשמגדירים זיקה לסשן בשירות, ההגדרה localityLbPolicy של שער הכניסה מוגדרת ל-MAGLEV.

כשמסירים הגדרת זיקה לסשן מ-GCPBackendPolicy, שער ה-API מחזיר את ההגדרה localityLbPolicy לערך ברירת המחדל, ROUND_ROBIN.

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

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

בGCPBackendPolicyמניפסט הבא מוגדרת זיקה לסשן שמבוססת על קובץ Cookie שנוצר, ומוגדר זמן החיים (TTL) של קובצי ה-Cookie ל-50 שניות:

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

אפשר להשתמש בערכים הבאים בשדה sessionAffinity.type:

CLIENT_IP
GENERATED_COOKIE
NONE

הגדרת זמן קצוב להשלמת תהליך (connection draining)

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

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

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

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

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

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות GKE בגרסה 1.24 ואילך.

כברירת מחדל:

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

יש שלוש דרכים להשבית את רישום הגישה ב-Gateway באמצעות GCPBackendPolicy:

אפשר להשאיר את הקטע GCPBackendPolicy בלי logging
אפשר להגדיר את logging.enabled ל-false
אפשר להגדיר את logging.enabled ל-true ואת logging.sampleRate ל-0

אפשר גם להגדיר את קצב הדגימה של רישום הגישה ואת רשימת השדות האופציונליים, למשל tls.cipher או orca_load_report.

כדי להפעיל את הרישום ביומן של השדות האופציונליים:

מגדירים את logging.OptionalMode להיות CUSTOM.
מזינים את רשימת השדות האופציונליים שרוצים לרשום ביומן logging.optionalFields. ראו רישום ביומן ומעקב לקבלת רשימת השדות הנתמכים.

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

אפשר להסיר את כל הרשומות מ-logging.optionalFields.
אפשר להגדיר את logging.OptionalMode ל-EXCLUDE_ALL_OPTIONAL.

במניפסט GCPBackendPolicy הבא משנים את קצב הדגימה שמוגדר כברירת מחדל לרישום ביומן של הגישה, ומגדירים אותו ל-50% מבקשות ה-HTTP. קובץ המניפסט מאפשר גם רישום ביומן של שני שדות אופציונליים עבור משאב שירות נתון:

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

קובץ המניפסט הזה כולל את השדות הבאים:

‫enable: true: הפעלה מפורשת של רישום גישה ביומן. היומנים זמינים ב'רישום ביומן'.
‫sampleRate: 500000: מציין ש-50% מהחבילות מתועדות. אפשר להשתמש בערך בין 0 ל-1,000,000. ‫GKE ממיר את הערך הזה לערך נקודה צפה בטווח [0, 1] על ידי חלוקה ב-1,000,000. השדה הזה רלוונטי רק אם בשדה enable מוגדר הערך true. sampleRate הוא שדה אופציונלי, אבל אם הוא מוגדר, חובה להגדיר גם את enable: true. אם המדיניות enable מוגדרת לערך true והמדיניות sampleRate לא מוגדרת,‏ GKE מגדיר את enable לערך false.
‫optionalMode: CUSTOM: מציין שצריך לכלול קבוצה של optionalFields ברשומות ביומן.
‫optionalFields: tls.cipher, orca_load_report.cpu_utilization: מציין שרשומות ביומן צריכות לכלול גם את שם ההצפנה שמשמש ללחיצת היד של TLS וגם את ניצול המעבד של השירות, בכל פעם שהם זמינים.

הגדרת התאמה אוטומטית לעומס (autoscaling) על סמך תנועה בשער חד-אשכולי

מוודאים שבאשכול GKE פועלת גרסה 1.31.1-gke.2008000 ואילך.

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

כדי להגדיר את הקיבולת של שירות, יוצרים שירות וGCPBackendPolicy משויך. קובץ המניפסט GCPBackendPolicy משתמש בשדה maxRatePerEndpoint כדי להגדיר ערך מקסימלי של בקשות לשנייה (RPS) לכל Pod בשירות. קובץ המניפסט GCPBackendPolicy הבא מגדיר RPS מקסימלי של 10:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

מידע נוסף על התאמה אוטומטית לעומס על סמך תנועה זמין במאמר התאמה אוטומטית לעומס על סמך תנועה במאזן עומסים (LB).

פתרון בעיות

כמה קבצים `GCPBackendPolicy` שצורפו לאותו `Service`

התסמין:

יכול להיות שתיתקלו בתנאי הסטטוס הבא כשמצרפים GCPBackendPolicy ל-Service או ל-ServiceImport:

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

הסיבה:

תנאי הסטטוס הזה מציין שאתם מנסים להחיל GCPBackendPolicy שני על Service או ServiceImport שכבר צורף אליהם GCPBackendPolicy.

GKE Gateway לא תומך בכמה GCPBackendPolicy שמצורפים לאותו Service או ServiceImport. פרטים נוספים זמינים במאמר הגבלות.

פתרון עקיף:

מגדירים GCPBackendPolicy אחד שכולל את כל ההגדרות בהתאמה אישית ומצרפים אותו אל Service או אל ServiceImport.

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

התסמין:

יכול להיות שתופיע הודעת השגיאה הבאה כשמפעילים את Cloud Armor בשער אזורי:

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

הסיבה:

הודעת השגיאה מציינת שמדיניות האבטחה האזורית של Cloud Armor שצוינה לא קיימת בפרויקט Google Cloud שלך.

פתרון עקיף:

יוצרים מדיניות אבטחה אזורית של Cloud Armor בפרויקט ומפנים למדיניות הזו ב-GCPBackendPolicy.

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

לפני שמתחילים

דרישות של GKE Gateway controller

הגבלות

הגדרת גישה גלובלית לשער פנימי אזורי

הגדרת האזור בשער מרובה אשכולות

הגדרת כללי מדיניות SSL כדי לאבטח את התנועה מלקוח למאזן עומסים

הגדרת בדיקות תקינות

שירות

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

הגדרת מדיניות אבטחה לקצה העורפי ב-Cloud Armor כדי לאבטח את שירותי הקצה העורפי

שירות

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

הגדרת IAP

שירות

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

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

שירות

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

הגדרת בחירת הקצה העורפי באמצעות GCPBackendPolicy

הגדרת ניתוב ברמת נקודת הקצה באמצעות GCPTrafficDistributionPolicy

הגדרת זיקה לסשן

שירות

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

שירות

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

הגדרת זמן קצוב להשלמת תהליך (connection draining)

שירות

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

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

שירות

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

הגדרת התאמה אוטומטית לעומס (autoscaling) על סמך תנועה בשער חד-אשכולי

פתרון בעיות

כמה קבצים GCPBackendPolicy שצורפו לאותו Service

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

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

הגדרת משאבי Gateway באמצעות מדיניות

הגדרת בחירת הקצה העורפי באמצעות `GCPBackendPolicy`

כמה קבצים `GCPBackendPolicy` שצורפו לאותו `Service`