יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

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

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

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

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

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

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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.
כשמשתמשים בשער (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 של שיוך סשנים. כדי להגדיר הצמדה לסשן ב-HEADER_FIELD או ב-HTTP_COOKIE, משתמשים במשאב GCPTrafficDistributionPolicy.
אל תשתמשו באותו קצה עורפי Service בשערי גישה מסוגים שונים של GatewayClass (כמו גלובלי לעומת אזורי, פנימי לעומת חיצוני או מנוהל לעומת קלאסי) אם שערי הגישה האלה דורשים הגדרות לא תואמות. לדוגמה, אי אפשר להחיל GCPBackendPolicy שהוגדר עם תכונות שלא נתמכות על ידי GatewayClass מסוג 'קלאסי' על Service שמשמש גם Gateway מסוג 'קלאסי'. כדי לוודא שההגדרה נכונה, יוצרים Service נפרד לכל שער שנדרשות בו הגדרות מדיניות שונות.
הגדרה של שיוך סשן באמצעות GCPTrafficDistributionPolicy נתמכת רק בשערי כניסה של אשכול יחיד.
GCPTrafficDistributionPolicy זיקה לסשן לא תואמת למשאבי InferencePool כי הם משתמשים באלגוריתמים ייעודיים לאיזון עומסים לפי מיקום.
‫GCPTrafficDistributionPolicy לא תומך בהגדרת מדיניות של שיוך סשנים או של איזון עומסים מקומי למאזן עומסים של אפליקציות בגרסה הקלאסית.
כשמשתמשים בשער עם אשכול אחד, משאבי GCPBackendPolicy ו-HealthCheckPolicy צריכים להתייחס למשאב Service או InferencePool.
כשמשתמשים בשער (Gateway) של כמה אשכולות, משאבי GCPBackendPolicy ו-HealthCheckPolicy צריכים להפנות למשאב ServiceImport או GCPInferencePoolImport.
בכל רגע נתון, אפשר לצרף רק GCPBackendPolicy אחד למשאב יעד יחיד (Service, ‏ ServiceImport, ‏ InferencePool או GCPInferencePoolImport). כשיוצרים כמה משאבים מסוג GCPBackendPolicy שמכוונים לאותו משאב, המדיניות הישנה ביותר מקבלת עדיפות והמדיניות החדשה יותר לא מצורפת.
המשאבים HealthCheckPolicy ו-GCPBackendPolicy צריכים להיות באותו מרחב שמות כמו משאב היעד Service, ServiceImport, InferencePool או GCPInferencePoolImport.
משאבי GCPBackendPolicy ו-HealthCheckPolicy יכולים לטרגט רק משאב אחד (כמו Service או InferencePool).

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

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

בקטע הזה מתוארת פונקציונליות שזמינה באשכולות 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 מוגדרת ומצורפת ל-Gateway.

חשוב ליצור מדיניות 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) יש פרמטרים שאפשר להגדיר. Cloud de Confiance יוצר בדיקת תקינות ייחודית לכל שירות קצה עורפי עבור כל שירות 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

InferencePool

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 an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    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 multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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

‫INTERVAL: מציין את check-interval, בשניות, לכל בודק בדיקות תקינות. זהו הזמן שחלף מתחילת הבדיקה של בודק אחד ועד לתחילת הבדיקה הבאה שלו. אם לא מציינים את הפרמטר הזה, ערך ברירת המחדל הוא 15 שניות אם לא מציינים את HealthCheckPolicy, ו-5 שניות אם מציינים את HealthCheckPolicy בלי ערך checkIntervalSec. Cloud de Confiance מידע נוסף זמין במאמר בנושא בדיקות מרובות ותדירות.
‫TIMEOUT: מציין את משך הזמן שבוCloud de Confiance ממתין לתגובה לבדיקה. הערך של TIMEOUT חייב להיות קטן מהערך של INTERVAL או שווה לו. היחידות הן שניות. כל בדיקה דורשת קוד תגובה HTTP 200 (OK) שיועבר לפני פסק הזמן של הבדיקה.
‫HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD: מציינים את מספר הניסיונות הרצופים ליצירת חיבור שצריכים להצליח או להיכשל, לפחות בבודק אחד, כדי לשנות את מצב התקינות ממצב תקין למצב לא תקין או ממצב לא תקין למצב תקין. אם משמיטים אחד מהפרמטרים האלה, ברירת המחדל היא 2. Cloud de Confiance
‫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 תומך רק בציון היציאה של בדיקת התקינות של מאזן העומסים באמצעות מספר יציאה. אם לא מציינים את הפרמטר הזה, Cloud de Confiance ברירת המחדל היא 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

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

הגדרת IAP

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

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

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

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

אתם לא צריכים ליצור BackendConfig, כי BackendConfig הוא משאב הגדרות של Ingress.

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

שומרים את קובץ המניפסט GCPBackendPolicy הבא בשם 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: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: SERVICE_NAME

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

‫CLIENT_SECRET: הסוד של לקוח OAuth.
‫CLIENT_ID: מזהה הלקוח ב-OAuth.
‫SERVICE_NAME: השם של השירות שאליו רוצים לטרגט ב-GCPBackendPolicy.

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

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: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: SERVICEIMPORT_NAME

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

‫CLIENT_SECRET: הסוד של לקוח OAuth.
‫CLIENT_ID: מזהה הלקוח ב-OAuth.
‫SERVICEIMPORT_NAME: השם של ServiceImport שאליו רוצים לטרגט ב-GCPBackendPolicy.

החלת המניפסט 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 הבא מוגדר זמן קצוב לתפוגה של שירות backend של 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

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

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 InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

הגדרת בחירת הקצה העורפי באמצעות `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
        maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
        dryRun: false

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

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

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

‫GCPTrafficDistributionPolicy API ב-Google Kubernetes Engine ‏ (GKE) Gateway מספק יכולות מתקדמות לניהול תנועת גולשים, שמאפשרות שליטה מדויקת באופן שבו תנועת הגולשים מופצת ל-pods של האפליקציה. המשאב המאוחד הזה, שפועל באופן מקורי ב-GKE, מפשט את הניהול של אלגוריתמים לאיזון עומסים והגדרות של שיוך סשנים.

הכלי GCPTrafficDistributionPolicy מאפשר לכם להגדיר:

אלגוריתמים לאיזון עומסים: מציינים איך התנועה מתחלקת בין נקודות הקצה בשרת העורפי.
- ‫WEIGHTED_ROUND_ROBIN: כשבוחרים באלגוריתם הזה, מאזן העומסים משתמש במדדים מותאמים אישית כדי לחשב משקלים ולחלק את התנועה על סמך המדדים המדווחים האלה. המערך customMetrics[] בהגדרה GCPTrafficDistributionPolicy כולל את השדות הבאים:
  - ‫name: מציין את השם שהמשתמש הגדיר למדד המותאם אישית.
  - ‫dryRun: אם true, נתוני המדדים מדווחים ל-Cloud Monitoring אבל לא משפיעים על איזון העומסים.
  הערה: מדדים מותאמים אישית שמוגדרים בתוך GCPTrafficDistributionPolicy חלים רק על WEIGHTED_ROUND_ROBIN localityLbPolicy ולא עוברים בירושה מ-backends[].customMetrics[] ב-GCPBackendPolicy.
‫RING_HASH: האלגוריתם הזה מועיל לשירותים שרגישים לביצועי מטמון. הוא משתמש בגיבוב עקבי כדי לצמצם את המיפוי מחדש של הבקשות כשמוסיפים או מסירים תרמילים של קצה עורפי, וכך עוזר לשמור על יציבות במהלך אירועי שינוי גודל. הגדרת minimumHashRingSize מספקת פיזור עומסים מפורט יותר.
הצמדה לסשן: עוזרת להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו פוד של קצה עורפי. זה חשוב במיוחד לעומסי עבודה עם שמירת מצב, כמו עגלות קניות במסחר אלקטרוני או סשנים של משחקים. GKE Gateway תומך בכל סוגי ההצמדה לסשן שזמינים בCloud de Confiance מופעים של מאזן עומסים של אפליקציות, כולל HEADER_FIELD ו-HTTP_COOKIE.

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

דוגמה

בדוגמה הבאה מוצג מניפסט 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

הגדרת הגודל של טבעת הגיבוב

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

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-service

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

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

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

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

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

כשמסירים הגדרת שיוך סשן מ-GCPBackendPolicy, שער חוזר להגדרת ברירת המחדל של 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

הגדלת ההסתברות להצגת מודעות למשתמשים שהביעו עניין בעסק באמצעות `GCPTrafficDistributionPolicy`

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

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

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

בטבלה הבאה מפורטים סוגי הקרבה שנתמכים בשימוש ב-GCPTrafficDistributionPolicy:

סוג תחום העניין המשותף	תיאור
`HEADER_FIELD`	השיוך מבוסס על כותרת HTTP ספציפית. צריך להגדיר את `localityLbAlgorithm` לערך `MAGLEV` או `RING_HASH`.
`HTTP_COOKIE`	זיקה שמבוססת על קובץ HTTP cookie. כשמאזן העומסים מגיב לבקשה הראשונה, הוא יוצר קובץ Cookie ומספק אותו בכותרת התגובה `Set-Cookie`. בבקשות הבאות, הלקוח מחזיר את קובץ ה-Cookie שסופק על ידי מאזן העומסים, ומאזן העומסים משתמש בו כדי לנתב את הבקשות באופן עקבי לאותם פודים. חובה להגדיר את `cookie.name`, ואפשר להגדיר גם את `cookie.path` ואת `cookie.ttl`. צריך להגדיר את `localityLbAlgorithm` לערך `MAGLEV` או `RING_HASH`.
`GENERATED_COOKIE`	מאזן העומסים יוצר קובץ Cookie כדי לעקוב אחרי הסשן. שם קובץ ה-Cookie הוא `GCLB` למאזני עומסים גלובליים חיצוניים של אפליקציות, ו-`GCILB` למאזני עומסים פנימיים אזוריים של אפליקציות ולמאזני עומסים חיצוניים אזוריים של אפליקציות. נתיב קובץ ה-Cookie הוא `/`. אפשר להגדיר `cookie.ttl` עד שבועיים לכל היותר; `cookie.name` ו-`cookie.path` לא ניתנים להגדרה בסוג הזה. צריך להגדיר את `localityLbAlgorithm` לערך `MAGLEV` או `RING_HASH`.
`CLIENT_IP`	תחום עניין משותף על סמך כתובת ה-IP של הלקוח. צריך להגדיר את `localityLbAlgorithm` לערך `MAGLEV` או `RING_HASH`.

דוגמאות מורחבות של שיוך לסשן

ב-GCPTrafficDistributionPolicy יש תמיכה בכמה סוגים של שיוך סשנים, ולכל אחד מהם יש דרישות הגדרה ייחודיות.

הגדרת שיוך סשנים מבוסס-קובצי Cookie‏ HTTP

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

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

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: http-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HTTP_COOKIE
      cookie:
        name: "my-app-session-id"
        ttl: "1h"
        path: "/"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: my-stateful-service

מחילים את המדיניות על האשכול:
```
kubectl apply -f policy.yaml
```

התנהגות של אפס TTL עבור שיוך סשנים שמבוסס על קובצי Cookie:

לכל ההעדפות של סשנים שמבוססות על קובצי Cookie, כמו העדפה של GENERATED_COOKIE והעדפה של HTTP_COOKIE, יש מאפיין ttl.

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

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

הגדרת זיקה לסשן שמבוססת על כותרת

הפניית תנועה על סמך כותרת HTTP ספציפית בתרחישים כמו בדיקות A/B או הפניית לקוחות מיוחדת שבה קובץ Cookie לא מתאים. כדי להשתמש בסוגים אחרים של שיוך סשנים מלבד NONE, צריך להגדיר את localityLbAlgorithm ל-MAGLEV או ל-RING_HASH. בניגוד ל-ROUND_ROBIN שמוגדר כברירת מחדל, האלגוריתמים האלה תומכים בגיבוב עקבי שמבוסס על שדות בהתאמה אישית, כמו כותרות HTTP.

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

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: header-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HEADER_FIELD
      httpHeaderName: "X-User-Group-ID"
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: SERVICE_NAME

מחילים את המדיניות על האשכול:
```
kubectl apply -f policy.yaml
```

אימות המדיניות

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

כדי לבדוק את סטטוס המדיניות, מתארים אותה:
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
מחליפים את POLICY_NAME בשם המדיניות.
בפלט, מחפשים את הקטע Conditions. סטטוס True עם הסיבה Attached מציין שההגדרה תקפה והיא הוחלה.

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

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

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

במניפסט GCPBackendPolicy הבא מוגדר פסק זמן של 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

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

yaml
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

במשך הזמן הקצוב לתפוגה שצוין, מערכת 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

InferencePool

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
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

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
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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

‫enable: true: הפעלה מפורשת של רישום גישה ביומן. היומנים זמינים בקטע Logging (רישום ביומן).
‫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 ואילך.

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

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

פתרון בעיות

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

`GCPTrafficDistributionPolicy` לא נכנס לתוקף

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

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

פתרון עקיף:

בדיקת סטטוס המדיניות: בודקים אם המדיניות צורפה לשירות:
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
מחליפים את POLICY_NAME בשם המדיניות.

בפלט, מחפשים את הקטע Conditions. סטטוס True עם הסיבה Attached מציין שההגדרה תקינה והיא הוחלה. אם הסטטוס הוא False, בודקים את השדות Reason ו-Message אם יש שגיאות אימות (לדוגמה, אלגוריתם לא נתמך לסוג הזיקה שנבחר).
אימות הסנכרון של הגדרות השער: מוודאים שהשער שמנהל את התנועה סינכרן בהצלחה את ההגדרות האלה עם תשתית הענן.

בקטע Status, מוודאים שלתנאי Programmed יש Status של True. אם הערך הוא False, המשמעות היא שבקר השער נתקל בשגיאה, שיכול להיות שהיא קשורה ל-GCPTrafficDistributionPolicy.

כדי לראות את הפרטים המלאים, בודקים את השדות Reason ו-Message שליד התנאי Programmed. כדי לראות הודעות שגיאה מפורטות יותר או היסטוריה של כשלים בסנכרון, בודקים את Events בתחתית הפלט.

כמה קבצים `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.

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

פתרון עקיף:

מגדירים GCPBackendPolicy יחיד שכולל את כל ההגדרות בהתאמה אישית ומצרפים אותו למשאב היעד (Service,‏ ServiceImport,‏ InferencePool או GCPInferencePoolImport).

הזיקה לסשן לא נלקחת בחשבון במהלך פיצול התנועה

תסמין:

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

הסיבה:

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

פתרון עקיף:

לא מומלץ להשתמש בפיצול תנועה משוקלל באותו כלל HTTPRoute שבו נדרשת שמירה על סשן.

לא נמצאה מדיניות אבטחה של 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 שצוינה לא קיימת בפרויקט Cloud de Confiance שלך.

פתרון עקיף:

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

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

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

דרישות של GKE Gateway Controller

הגבלות

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

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

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

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

שירות

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

InferencePool

Multi-cluster InferencePool

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

שירות

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

InferencePool

Multi-cluster InferencePool

הגדרת IAP

שירות

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

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

שירות

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

InferencePool

Multi-cluster InferencePool

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

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

הגדרת הגודל של טבעת הגיבוב

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

שירות

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

שירות

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

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

דוגמאות מורחבות של שיוך לסשן

הגדרת שיוך סשנים מבוסס-קובצי Cookie‏ HTTP

הגדרת זיקה לסשן שמבוססת על כותרת

אימות המדיניות

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

שירות

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

InferencePool

Multi-cluster InferencePool

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

שירות

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

InferencePool

Multi-cluster InferencePool

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

פתרון בעיות

GCPTrafficDistributionPolicy לא נכנס לתוקף

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

הזיקה לסשן לא נלקחת בחשבון במהלך פיצול התנועה

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

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

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

הגדלת ההסתברות להצגת מודעות למשתמשים שהביעו עניין בעסק באמצעות `GCPTrafficDistributionPolicy`

`GCPTrafficDistributionPolicy` לא נכנס לתוקף

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