‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

טייס אוטומטי רגילה

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

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

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

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

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

הפעלת 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.

דרישות

במדריך הזה משתמשים ב-spec.loadBalancerClass כדי ליצור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם קצה עורפי של GCE_VM_IPNEG. כדי להשתמש במדריך הזה, צריך GKE בגרסה ‎1.33.1-gke.1779000 ואילך, כי spec.loadBalancerClass דורש GKE בגרסה ‎1.33.1-gke.1779000 ואילך.
כדי להשתמש בתכונה 'זיקה אזורית', צריך להשתמש בגרסה ‎1.33.3-gke.1392000 ואילך של GKE.
צריך להפעיל באשכול את האפשרות 'חלוקת משנה של GKE':
- החל מגרסה 1.36 ואילך, התכונה 'חלוקת משנה של GKE' מופעלת כברירת מחדל באשכולות. בגרסאות האלה, יצירת קבוצת משנה פעילה ללא קשר לערך של דגל יצירת קבוצת המשנה של האשכול.
- בגרסאות נתמכות של 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 לקבוצות משנה' מופעלת בלי קשר לערך המאפיין networkConfig.enableL4ilbSubsetting – True או False.
אם הגרסה של מישור הבקרה היא לפני 1.36:
- ‫True מציין שהגדרת תת-קבוצה של GKE מופעלת.
- ‫False מציין שהתכונה 'חלוקת משנה של GKE' מושבתת.

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

המסוף

במסוף Google Cloud , נכנסים לדף Google Kubernetes Engine.

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע Networking (רשת), ליד השדה Subsetting for L4 Internal Load Balancers (חלוקת משנה למאזני עומסים פנימיים ברמה 4), לוחצים על Enable subsetting for L4 internal load balancers (הפעלת חלוקת משנה למאזני עומסים פנימיים ברמה 4).
מסמנים את תיבת הסימון הפעלת חלוקה לקבוצות משנה עבור מאזני עומסים פנימיים ברמה 4.
לוחצים על שמירת השינויים.

gcloud

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

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

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

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

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

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

שומרים את קובץ המניפסט בשם 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

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

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

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

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

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

מידע נוסף על ניהול כללים של חומת אש ב-VPC זמין במאמר בנושא ניהול יצירה אוטומטית של כללים של חומת אש. מידע על השבתה של יצירה אוטומטית של כללים של חומת אש זמין במאמר בנושא כללים של חומת אש בניהול המשתמש עבור שירותי איזון עומסים של GKE.
בדוגמה הבאה נוצר שירות 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 פנימי קיים באמצעות הפקודה kubectl edit svc service-name. הפקודה kubectl edit פותחת את מניפסט השירות של מאזן העומסים הקיים בעורך הטקסט שהגדרתם, שבו תוכלו להוסיף או להסיר את הפרמטר spec.trafficDistribution ולשמור את השינויים. יכול להיות שתהיה הפרעה קצרה בתנועה כשמשנים את הפרמטר הזה.
    
    לשיקולים חשובים ולפתרון עקיף להרחבת עומסי עבודה עם זיקה לאזור, אפשר לעיין במאמר הרחבת עומסי עבודה עם זיקה לאזור.
  מידע נוסף מופיע במאמר פרמטרים של שירות LoadBalancer.
2. מחילים את המניפסט על האשכול:
```
kubectl apply -f ilb-svc.yaml
```

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

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

בודקים את קבוצת נקודות הקצה ברשת של השירות:
```
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% מהבקשות לשירות מאזן עומסים נתון.

שומרים את קובץ המניפסט הבא בשם 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"

מחילים את המניפסט L4LBConfig על האשכול:
```
kubectl apply -f svc-l4lb-config.yaml
```

מוסיפים את ההערה 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

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

התאמה לעומס של עומסי העבודה באמצעות זיקה אזורית

‫HorizontalPodAutoscaler‏ (HPA) משנה את קנה המידה של ה-Pods על סמך מדדים מצטברים של האשכול ולא על סמך העומס בכל אזור, לכן מומלץ להפריד בין עומסי העבודה לפי אזור כדי למנוע עומס יתר אזורי. במקום פריסה אחת ו-HPA אחד בכל האשכול, יוצרים פריסה נפרדת ו-HPA נפרד לכל אזור שבו האשכול פועל. שירות LoadBalancer פנימי יחיד יכול לנתב תנועה לכל עומסי העבודה האזוריים העצמאיים האלה בו-זמנית.

סקירה כללית של הארכיטקטורה

עומס עבודה אחד לכל אזור: יוצרים פריסות נפרדות לכל אזור (לדוגמה, zone-a, zone-b).
סלקטורים של צמתים: כל פריסה קשורה לאזור הספציפי שלה באמצעות הסלקטור topology.kubernetes.io/zone של הצומת.
מנגנון HPA אחד לכל אזור: צריך לצרף מנגנון HPA לכל פריסה ספציפית כדי שה-Pods שלה יתרחבו באופן עצמאי על סמך מדדים מקומיים.
שירות משותף אחד: חשיפת כל הפריסות האלה מאחורי שירות איזון עומסים פנימי יחיד שהוגדר עם זיקה אזורית (באמצעות אותו סלקטור).

הגדרת עומסי עבודה עצמאיים באזורים

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

יוצרים פריסה נפרדת לכל אזור. לפריסות יש אותה תווית app, אבל יש להן תווית nodeSelector שמקשרת אותן לאזור ספציפי.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-a
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-a
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_A"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-b
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-b
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_B"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"

מחליפים את COMPUTE_ZONE_A ואת COMPUTE_ZONE_B באזורים בפועל (לדוגמה, us-central1-a ו-us-central1-b).

החלת המניפסט:

kubectl apply -f zonal-deployments.yaml

יוצרים HPA עצמאי לכל פריסה אזורית.

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

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-a
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-b
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-b
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

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

מוודאים שהשירות מכוון לתווית המשותפת (app: my-app) ושהתכונה 'זיקה אזורית' מופעלת.

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

apiVersion: v1
kind: Service
metadata:
  name: my-app-service-internal
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  trafficDistribution: PreferSameZone
  selector:
    app: my-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

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

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

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

מוודאים שהשירות פועל:
```
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 שבו פועל שירות קצה עורפי.
מוודאים ש-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 או מסוףGoogle Cloud .

kubectl

מחיקת הפריסה

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

kubectl delete deployment ilb-deployment

מחיקת השירות

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

kubectl delete service ilb-svc

המסוף

מחיקת הפריסה

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

נכנסים לדף Workloads במסוף Google Cloud .

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

מחיקת השירות

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

נכנסים לדף Services & Ingress במסוף Google Cloud .

כניסה אל Services & Ingress
בוחרים את השירות שרוצים למחוק ולוחצים על מחיקה.
כשמופיעה בקשה לאישור, לוחצים על מחיקה.

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

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

מגבלות

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

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

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

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

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

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

יוצרים כתובת 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,‏ Google Cloud בוחר כתובת IP פנימית שלא נמצאת בשימוש מתוך טווח כתובות ה-IP הראשי של רשת המשנה שנבחרה. כדי לקבוע כתובת שנבחרה באופן אוטומטי, צריך להריץ את הפקודה gcloud compute addresses describe.
- ‫SUBNET: השם של תת-הרשת המשותפת.

שומרים את הגדרות השירות הבאות של 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

מחילים את הגדרת השירות הזו על האשכול:
```
kubectl apply -f tcp-service.yaml
```

שומרים את הגדרות שירות ה-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

מחילים את הקובץ על האשכול:
```
kubectl apply -f udp-service.yaml
```
כדי לוודא שכתובת ה-IP הווירטואלית משותפת בין כללי ההעברה של מאזן העומסים, מפרטים את הכללים ומסננים לפי כתובת ה-IP הסטטית. התוצאה מראה שיש כלל להעברת UDP וכלל להעברת TCP, ושניהם מאזינים בשבע יציאות שונות ב-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

המסוף

gcloud

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

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

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

התאמה לעומס של עומסי העבודה באמצעות זיקה אזורית

סקירה כללית של הארכיטקטורה

הגדרת עומסי עבודה עצמאיים באזורים

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

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

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

kubectl

מחיקת הפריסה

מחיקת השירות

המסוף

מחיקת הפריסה

מחיקת השירות

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

מגבלות

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

בעיות מוכרות

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

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

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