יצירת מאזן עומסים פנימי

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

• מידע על שירותי איזון עומסים
• פרמטרים של שירות GKE LoadBalancer

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

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

דרישות

• במדריך הזה משתמשים ב-spec.loadBalancerClass כדי ליצור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם קצה עורפי של GCE_VM_IPNEG. כדי להשתמש במדריך הזה, צריך GKE בגרסה ‎1.33.1-gke.1779000 ואילך, כי spec.loadBalancerClass דורש GKE בגרסה ‎1.33.1-gke.1779000 ואילך.

• כדי להשתמש בתכונה 'זיקה אזורית' צריך GKE בגרסה ‎1.33.3-gke.1392000 ואילך.

• צריך להפעיל באשכול את האפשרות 'חלוקת משנה של GKE':

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

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

• אם האשכול שלכם הוא בגרסה קודמת ל-1.36, צריך להפעיל את התוסף HttpLoadBalancing באשכול. התוסף הזה מופעל כברירת מחדל.

• כדי להפעיל את Cloud Logging בשביל שירות LoadBalancer פנימי, אשכול GKE צריך להיות בגרסה 1.36.0-gke.2459000 ואילך.

אימות והפעלה של חלוקת משנה ב-GKE

מוודאים שהאפשרות GKE subsetting מופעלת:

• החל מגרסה 1.36 של GKE, תמיד מופעלת חלוקת משנה של GKE.

• אפשר להפעיל את התכונה 'חלוקת משנה של GKE' באופן ידני באשכולות חדשים וקיימים של Standard ו-Autopilot שמופעלת בהם גרסה ‎1.18.19-gke.1400 ואילך של GKE, אבל לפני גרסה 1.36 של GKE. אחרי שמפעילים את התכונה 'חלוקת משנה של GKE', אי אפשר להשבית אותה.

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

כדי לבדוק אם התכונה 'חלוקת משנה של GKE' מופעלת, מריצים את הפקודה הבאה:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

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

• ‫CLUSTER_NAME: שם האשכול.
• ‫LOCATION : האזור או האזור של האשכול.

הפלט של הפקודה מציג את גרסת מישור הבקרה של האשכול, ואחריה True או False עבור המאפיין networkConfig.enableL4ilbSubsetting. הפרשנות של הפלט היא כדלקמן:

• אם גרסת מישור הבקרה היא 1.36 ואילך, התכונה GKE subsetting מופעלת בלי קשר לערך של המאפיין networkConfig.enableL4ilbSubsetting, שהוא True או False.
• אם הגרסה של מישור הבקרה היא לפני 1.36:
  • ‫True מציין שהגדרת קבוצת משנה של GKE מופעלת.
  • הערך False מציין שהתכונה 'חלוקת GKE לקבוצות משנה' מושבתת.

כדי להפעיל חלוקת משנה של GKE באשכול שמריץ GKE גרסה ‎1.18.19-gke.1400 ואילך, אבל לפני GKE גרסה 1.36, משתמשים ב-CLI של gcloud או במסוף Cloud de Confiance .

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION
    --enable-l4-ilb-subsetting

הפעלת חלוקת משנה ב-GKE – באמצעות ה-CLI של gcloud, מסוףCloud de Confiance או שדרוג האשכול לגרסה 1.36 ואילך – לא משנה שירותים קיימים של איזון עומסים פנימיים. אם רוצים להעביר שירות LoadBalancer פנימי קיים לשימוש בקצה העורפי של GCE_VM_IP NEG, צריך לפרוס מניפסט של שירות חלופי.

פריסת עומס עבודה

קובץ המניפסט הבא מתאר Deployment (פריסה) שמריצה קובץ אימג' של קונטיינר של אפליקציית אינטרנט לדוגמה.

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ilb-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: ilb-deployment
     template:
       metadata:
         labels:
           app: ilb-deployment
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

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

   kubectl apply -f ilb-deployment.yaml
   

יצירת שירות LoadBalancer פנימי

1. (אופציונלי) השבתה של יצירה אוטומטית של כללי חומת אש של VPC:

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

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

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

2. בדוגמה הבאה נוצר שירות LoadBalancer פנימי באמצעות יציאת TCP‏ 80. ‫GKE פורס מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שכלל ההעברה שלו משתמש ביציאה 80, אבל אחר כך מעביר את תעבורת הנתונים אל ה-Pods של הקצה העורפי ביציאה 8080:

   1. שומרים את קובץ המניפסט בשם ilb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: ilb-svc
      spec:
        type: LoadBalancer
        # Request an internal load balancer.
        loadBalancerClass: networking.gke.io/l4-regional-internal
        # Evenly route external traffic to all endpoints.
        externalTrafficPolicy: Cluster
        # Prioritize routing traffic to endpoints that are in the same zone.
        trafficDistribution: PreferSameZone
        selector:
          app: ilb-deployment
        # Forward traffic from TCP port 80 to port 8080 in backend Pods.
        ports:
        - name: tcp-port
          protocol: TCP
          port: 80
          targetPort: 8080
      

      קובץ המניפסט צריך לכלול את הפרטים הבאים:

      • ‫name בשביל שירות LoadBalancer פנימי, במקרה הזה ilb-svc.
      • השדה spec.loadBalancerClass מוגדר לערך networking.gke.io/l4-regional-internal כדי לציין שירות LoadBalancer פנימי, כמו שמוצג במניפסט לדוגמה.
      • הtype: LoadBalancer.
      • שדה spec: selector שבו מציינים את ה-Pods שאליהם השירות צריך לכוון, לדוגמה, app: hello.
      • פרטי הניוד:
        • המשתנה port מייצג את יעד היציאה שבו כלל ההעברה של מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי מקבל חבילות.
        • הערך של targetPort חייב להיות זהה לערך של containerPort שהוגדר בכל Pod להצגת מודעות.
        • הערכים של port ושל targetPort לא צריכים להיות זהים. הצמתים תמיד מבצעים NAT של היעד, ומשנים את כתובת ה-IP של כלל ההעברה של מאזן העומסים של היעד ואת port לכתובת ה-IP של יעד ה-Pod ואת targetPort. פרטים נוספים זמינים במאמר תרגום כתובות רשת של יעד בצמתים במסמכי העזרה בנושא מושגים של שירות LoadBalancer.

      המניפסט יכול להכיל את הרכיבים הבאים:

      • ‫spec.ipFamilyPolicy ו-ipFamilies כדי להגדיר איך GKE מקצה כתובות IP לשירות. ‫GKE תומך בשירותים של איזון עומסים עם כתובות IP מסוג סטאק יחיד (IPv4 בלבד או IPv6 בלבד) או סטאק כפול. שירות LoadBalancer עם סטאק כפול מיושם באמצעות שני כללי העברה נפרדים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי: אחד לתעבורת IPv4 ואחד לתעבורת IPv6. השירות LoadBalancer של GKE עם תמיכה ב-dual-stack זמין בגרסה 1.29 ואילך. מידע נוסף זמין במאמר בנושא שירותים עם סטאק כפול של IPv4/IPv6.

      • ‫spec.trafficDistribution כדי להגדיר איך GKE מנתב תנועה נכנסת. כדי להפעיל את ההעדפה לאזור, צריך להגדיר את הערך של השדה הזה ל-PreferSameZone. זיקה אזורית פירושה ש-GKE נותן עדיפות לניתוב תנועה שמגיעה מאזור מסוים לצמתים ול-Pods באותו אזור. אם אין פודים תקינים זמינים באזור הזה, התעבורה מנותבת לאזור אחר. בגרסאות של אשכולות מוקדמות יותר מ-1.35.0-gke.1811000, צריך להשתמש ב-PreferClose כערך. כדי להשתמש בהעדפה אזורית צריך להפעיל את התכונה 'חלוקת משנה של GKE'.

      מידע נוסף מופיע במאמר פרמטרים של שירות LoadBalancer.

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

      kubectl apply -f ilb-svc.yaml
      

3. מידע מפורט על השירות:

   kubectl get service ilb-svc --output yaml
   

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

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       # Kubernetes automatically allocates a port on the node during the
       # process of implementing a Service of type LoadBalancer.
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     trafficDistribution: PreferSameZone
     type: LoadBalancer
   status:
     # IP address of the load balancer forwarding rule.
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   הפלט כולל את המאפיינים הבאים:

   • כתובת ה-IP של כלל ההעברה של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי כלולה ב-status.loadBalancer.ingress. כתובת ה-IP הזו שונה מהערך של clusterIP. בדוגמה הזו, כתובת ה-IP של כלל ההעברה של מאזן העומסים היא 10.128.15.245.
   • כל Pod עם התווית app: ilb-deployment הוא Pod להצגת מודעות בשירות הזה. אלה ה-Pods שמקבלים חבילות שמופנות על ידי מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי.
   • לקוחות מתקשרים לשירות באמצעות כתובת ה-IP הזו ויציאת היעד של TCP שמצוינת בשדה port של מניפסט השירות.loadBalancer לפרטים מלאים על אופן ניתוב המנות לאחר קבלתן בצומת, ראו עיבוד מנות.
   • מערכת GKE הקצתה nodePort לשירות. בדוגמה הזו, הוקצתה יציאה 30521. המאפיין nodePort לא רלוונטי למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.

4. בודקים את קבוצת נקודות הקצה ברשת של השירות:

   kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
   

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

   {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
   

   התשובה מציינת ש-GKE יצר קבוצת נקודות קצה ברשת בשם k8s2-knlc4c77-default-ilb-svc-ua5ugas0. ההערה הזו מופיעה בשירותים מסוג LoadBalancer שמשתמשים בחלוקת משנה של GKE, ולא מופיעה בשירותים שלא משתמשים בחלוקת משנה של GKE.

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

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

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

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

• ‫enabled: אם הערך מוגדר ל-true, מופעלת רישום ביומן של השירות הזה והיומנים זמינים ב-Cloud Logging. אחרת, הרישום מושבת בשירות הזה.
• ‫sampleRate: מציין ערך מ-0 עד 1,000,000 (ברירת מחדל), כאשר 0 אומר שלא מתבצעת רישום ביומן של מנות ו-1,000,000 אומר שמתבצעת רישום ביומן של 100% מהמנות. השדה sampleRate הוא אופציונלי, והוא רלוונטי רק אם הערך של השדה enable מוגדר כ-true.
• ‫optionalMode: קובע אילו שדות אופציונליים של מטא-נתונים נכללים ביומנים שנוצרו עבור מאזן העומסים. השדה מקבל אחד מהערכים הבאים:
  • ‫EXCLUDE_ALL_OPTIONAL: הגדרת ברירת המחדל אם לא מצוין optionalMode. אם מגדירים את האפשרות הזו, אף שדה אופציונלי לא נכלל ביומנים, ומתקבל פורמט היומן הכי תמציתי.
  • ‫INCLUDE_ALL_OPTIONAL: מאפשר רישום ביומן של כל השדות האופציונליים הזמינים, ומספק את רשומות היומן הכי מפורטות.
  • ‫CUSTOM: מציין רשימה מותאמת אישית של שדות אופציונליים שנכללים ביומנים. במצב CUSTOM, צריך להשתמש גם בפרמטר optionalFields כדי לספק רשימה של השדות שרוצים לקבל, כשהשדות מופרדים בפסיקים.
• ‫optionalFields: מחרוזת מופרדת בפסיקים של שמות שדות. הגדרה של שדות המטא-נתונים האופציונליים שרוצים לכלול ביומנים שנוצרו. השדה הזה משמש רק כשהערך של optionalMode הוא CUSTOM. אחרת, המערכת מתעלמת מכל הערכים.

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

1. שומרים את קובץ המניפסט הבא בשם svc-l4lb-config.yaml:

   apiVersion: networking.gke.io/v1
   kind: L4LBConfig
   metadata:
     name: svc-l4lb-config
     namespace: default
   spec:
     logging:
       enabled: true # must be included
       sampleRate: 500000
       optionalMode: "INCLUDE_ALL_OPTIONAL"
   

2. מחילים את קובץ המניפסט L4LBConfig על האשכול:

   kubectl apply -f svc-l4lb-config.yaml
   

3. מוסיפים את ההערה networking.gke.io/l4lb-config למניפסט של השירות ilb-svc.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-svc
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
       networking.gke.io/l4lb-config: "svc-l4lb-config"
   spec:
     type: LoadBalancer
     selector:
       app: store
     ports:
       - name: tcp-port
         protocol: TCP
         port: 8080
         targetPort: 8080
   

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

   kubectl apply -f ilb-svc.yaml
   

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

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

• בודקים שהשירות פועל:

  kubectl get service SERVICE_NAME --output yaml
  

  מחליפים את SERVICE_NAME בשם של מניפסט השירות.

  אם הפעלתם את ההעדפה לאזור מסוים, הפלט כולל את הפרמטר spec.trafficDistribution. הערך של השדה הזה מוגדר ל-PreferSameZone, או ל-PreferClose אם גרסת האשכול קודמת ל-1.35.0-gke.1811000.

• מאמתים את כתובת ה-IP של כלל ההעברה של מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי. כתובת ה-IP של כלל ההעברה של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי היא 10.128.15.245 בדוגמה שמופיעה בקטע יצירת שירות LoadBalancer פנימי. כדי לוודא שכלל ההעברה הזה נכלל ברשימת כללי ההעברה בפרויקט של האשכול, משתמשים ב-Google Cloud CLI:

  gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
  

  הפלט כולל את כלל ההעברה הרלוונטי של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, את כתובת ה-IP שלו ואת שירות הקצה העורפי שאליו מתייחס כלל ההעברה (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r בדוגמה הזו).

  NAME                          ... IP_ADDRESS  ... TARGET
  ...
  k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  

• מתארים את שירות הקצה העורפי של מאזן העומסים באמצעות Google Cloud CLI:

  gcloud compute backend-services describe k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
  

  מחליפים את COMPUTE_REGION באזור החישוב של שירות הקצה העורפי.

  אם הפעלתם את ההעדפה לאזור מסוים:

  • הערך בשדה networkPassThroughLbTrafficPolicy.zonalAffinity.spillover צריך להיות ZONAL_AFFINITY_SPILL_CROSS_ZONE.
  • השדה networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio צריך להיות מוגדר ל-0 או לא להיכלל.

  הפלט כולל את ה-NEG או ה-NEGs של הקצה העורפי של השירות GCE_VM_IP (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r בדוגמה הזו).

  backends:
  - balancingMode: CONNECTION
    group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  ...
  kind: compute#backendService
  loadBalancingScheme: INTERNAL
  name: aae3e263abe0911e9b32a42010a80008
  networkPassThroughLbTrafficPolicy:
    zonalAffinity:
      spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
  protocol: TCP
  ...
  

  אם השבתתם את ההעדפה האזורית, צריך להגדיר את השדה networkPassThroughLbTrafficPolicy.zonalAffinity.spillover לערך ZONAL_AFFINITY_DISABLED או לא לכלול אותו. שימו לב: אם האשכול שלכם הוא בגרסה מוקדמת יותר מ-1.33.3-gke.1392000, האפשרות 'שיוך לאזור' מושבתת אוטומטית.

• כדי לקבוע את רשימת הצמתים בתת-קבוצה של שירות:

  gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
      --zone=COMPUTE_ZONE
  

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

  • ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת שנוצרה על ידי בקר GKE.
  • ‫COMPUTE_ZONE: אזור המחשוב של קבוצת נקודות הקצה ברשת שעליה רוצים לבצע את הפעולה.

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

  gcloud compute backend-services get-health SERVICE_NAME \
      --region=COMPUTE_REGION
  

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

  • ‫SERVICE_NAME: השם של השירות לקצה העורפי. הערך הזה זהה לשם של קבוצת נקודות הקצה ברשת שנוצרה על ידי בקר GKE.
  • ‫COMPUTE_REGION: אזור Compute של שירות ה-Backend שעליו רוצים להפעיל את הפקודה.

• מוודאים ש-Cloud Logging הופעל בשירות:

  kubectl get svc SERVICE_NAME --output yaml
  

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

  • ‫SERVICE_NAME: השם של השירות.

  בפלט, מוודאים שהשדה Status.Conditions מכיל את הערכים Type: LoggingConfigManaged ו-Reason: Reconciled.

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

אפשר לגשת למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי רק מתוך אותה רשת VPC (או רשת מקושרת). כברירת מחדל, הגישה הגלובלית לכלל ההעברה של מאזן העומסים מושבתת, ולכן מכונות וירטואליות של לקוחות, מנהרות Cloud VPN או קבצים מצורפים של Cloud Interconnect (רשתות VLAN) צריכים להיות באותו אזור כמו מאזן העומסים הפנימי מסוג Network Load Balancer. כדי לתמוך בלקוחות בכל האזורים, אפשר להפעיל גישה גלובלית בכלל ההעברה של איזון העומסים על ידי הוספת ההערה global access למניפסט של השירות.

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

curl LOAD_BALANCER_IP:80

מחליפים את LOAD_BALANCER_IP בכתובת ה-IP של כלל ההעברה של מאזן העומסים.

התגובה מציגה את הפלט של ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

מחיקת שירות LoadBalancer פנימי ומשאבי מאזן העומסים

אפשר למחוק את הפריסה והשירות באמצעות kubectl delete או מסוףCloud de Confiance .

kubectl delete deployment ilb-deployment

kubectl delete service ilb-svc

כתובת IP משותפת

מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מאפשר שיתוף של כתובת IP וירטואלית בין כמה כללי העברה. האפשרות הזו שימושית להגדלת מספר היציאות בו-זמנית באותה כתובת IP או לקבלת תנועת UDP ו-TCP באותה כתובת IP. אפשר להשתמש בו כדי לחשוף עד 50 יציאות לכל כתובת IP. כתובות IP משותפות נתמכות באופן טבעי באשכולות GKE עם שירותי איזון עומסים פנימיים. במהלך הפריסה, השדה loadBalancerIP של השירות משמש לציון כתובת ה-IP שצריכה להיות משותפת בין השירותים.

מגבלות

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

• כל כלל העברה יכול לכלול עד חמש יציאות (סמוכות או לא סמוכות), או שאפשר להגדיר אותו כך שיתאים לתנועה בכל היציאות ויעביר אותה. אם שירות Internal LoadBalancer מגדיר יותר מחמש יציאות, כלל ההעברה יוגדר אוטומטית כך שיתאים לכל היציאות.
• עד עשרה שירותים (כללי העברה) יכולים לחלוק כתובת IP. התוצאה היא עד 50 יציאות לכל כתובת IP משותפת.
• כל כלל העברה שמשתמש באותה כתובת IP צריך להשתמש בשילוב ייחודי של פרוטוקולים ויציאות. לכן, כל שירות LoadBalancer פנימי חייב להשתמש בקבוצה ייחודית של פרוטוקולים ופורטים.
• אפשר להשתמש בשילוב של שירותים שפועלים רק בפרוטוקול TCP ושירותים שפועלים רק בפרוטוקול UDP באותו IP משותף, אבל אי אפשר לחשוף גם יציאות TCP וגם יציאות UDP באותו שירות.

הפעלה של כתובת IP משותפת

כדי לאפשר לשירותים פנימיים של LoadBalancer לשתף כתובת IP משותפת, פועלים לפי השלבים הבאים:

1. יוצרים כתובת IP פנימית סטטית באמצעות --purpose SHARED_LOADBALANCER_VIP. כדי שיהיה אפשר לשתף כתובת IP, צריך ליצור אותה למטרה הזו. אם יוצרים כתובת IP פנימית סטטית ב-VPC משותף, צריך ליצור את כתובת ה-IP באותו פרויקט שירות שבו נמצאת המכונה שתשתמש בכתובת ה-IP, למרות שהערך של כתובת ה-IP יגיע מטווח כתובות ה-IP הזמינות בתת-רשת משותפת שנבחרה ברשת ה-VPC המשותפת. מידע נוסף זמין במאמר הקצאת כתובת IP פנימית סטטית בדף הקצאת VPC משותף.

2. אפשר לפרוס עד עשרה שירותים פנימיים של LoadBalancer באמצעות כתובת ה-IP הסטטית הזו בשדה loadBalancerIP. מאזני עומסי הרשת הפנימיים להעברת סיגנל ללא שינוי מסונכרנים על ידי בקר השירות של GKE ונפרסים באמצעות אותה כתובת IP של קצה קדמי.

בדוגמה הבאה אפשר לראות איך עושים את זה כדי לתמוך בכמה יציאות TCP ו-UDP מול אותה כתובת IP של מאזן עומסים פנימי.

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

   אם האשכול ורשת ה-VPC נמצאים באותו פרויקט:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=PROJECT_ID \
       --subnet=SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   אם האשכול נמצא בפרויקט שירות של VPC משותף, אבל משתמש ברשת VPC משותפת בפרויקט מארח:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=SERVICE_PROJECT_ID \
       --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

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

   • ‫IP_ADDR_NAME: שם לאובייקט של כתובת ה-IP.
   • ‫SERVICE_PROJECT_ID: המזהה של פרויקט השירות.
   • ‫PROJECT_ID: מזהה הפרויקט (פרויקט יחיד).
   • ‫HOST_PROJECT_ID: מזהה הפרויקט המארח של ה-VPC המשותף.
   • ‫COMPUTE_REGION: אזור Compute שמכיל את תת-הרשת המשותפת.
   • ‫IP_ADDRESS: כתובת IP פנימית שלא נמצאת בשימוש מטווח כתובות ה-IP הראשי של רשת המשנה שנבחרה. אם לא מציינים כתובת IP,‏ Cloud de Confiance בוחר כתובת IP פנימית שלא נמצאת בשימוש מתוך טווח כתובות ה-IP הראשי של רשת המשנה שנבחרה. כדי לקבוע כתובת שנבחרה באופן אוטומטי, צריך להריץ את הפקודה gcloud compute addresses describe.
   • ‫SUBNET: השם של תת-הרשת המשותפת.

2. שומרים את הגדרות השירות הבאות של TCP בקובץ בשם tcp-service.yaml ואז פורסים אותו באשכול. מחליפים את IP_ADDRESS בכתובת ה-IP שבחרתם בשלב הקודם.

   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use an IP address that you create.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: myapp
     ports:
     - name: 8001-to-8001
       protocol: TCP
       port: 8001
       targetPort: 8001
     - name: 8002-to-8002
       protocol: TCP
       port: 8002
       targetPort: 8002
     - name: 8003-to-8003
       protocol: TCP
       port: 8003
       targetPort: 8003
     - name: 8004-to-8004
       protocol: TCP
       port: 8004
       targetPort: 8004
     - name: 8005-to-8005
       protocol: TCP
       port: 8005
       targetPort: 8005
   

3. מחילים את הגדרת השירות הזו על האשכול:

   kubectl apply -f tcp-service.yaml
   

4. שומרים את הגדרות שירות ה-UDP הבאות בקובץ בשם udp-service.yaml ואז פורסים אותו. היא גם משתמשת ב-IP_ADDRESS שציינתם בשלב הקודם.

   apiVersion: v1
   kind: Service
   metadata:
     name: udp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use the same IP address that you used for the TCP Service.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: my-udp-app
     ports:
     - name: 9001-to-9001
       protocol: UDP
       port: 9001
       targetPort: 9001
     - name: 9002-to-9002
       protocol: UDP
       port: 9002
       targetPort: 9002
   

5. מחילים את הקובץ על האשכול:

   kubectl apply -f udp-service.yaml
   

6. כדי לוודא שכתובת ה-IP הווירטואלית משותפת בין כללי ההעברה של מאזן העומסים, מציגים את הכללים ומסננים לפי כתובת ה-IP הסטטית. התוצאה הזו מראה שיש כלל להעברת UDP וכלל להעברת TCP, שניהם מאזינים ל-7 יציאות שונות ב-IP_ADDRESS המשותף, שבמקרה הזה הוא 10.128.2.98.

   gcloud compute forwarding-rules list | grep 10.128.2.98
   ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
   acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
   

בעיות מוכרות

שגיאה ביצירת מאזן עומסים במסלול הרגיל

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

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

כדי לפתור את הבעיה הזו בגרסאות GKE מוקדמות יותר מ-1.23.3-gke.900, צריך להגדיר את מסלול הרשת שמוגדר כברירת מחדל בפרויקט ל'פרימיום'.

הבעיה הזו נפתרה בגרסאות GKE‏ 1.23.3-gke.900 ואילך, כשמופעלת חלוקת משנה של GKE.

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

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

• סקירה כללית על רשת GKE
• מידע נוסף על מאזני עומסים ב-Compute Engine
• איך יוצרים אשכול המותאם ל-VPC
• פתרון בעיות באיזון עומסים ב-GKE
• מידע נוסף על סוכן להסוואת כתובות IP
• מידע על הגדרת רשתות מורשות