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

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

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

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים הבאים:

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

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

שימוש ב-GKE subsetting

חלוקת משנה ב-GKE משפרת את יכולת ההתאמה של שירותי איזון עומסים פנימיים, כי היא משתמשת בGCE_VM_IP קבוצות של נקודות קצה ברשת (NEGs) כבקאנד במקום בקבוצות של מכונות וירטואליות. כשמפעילים את התכונה 'חלוקת משנה ב-GKE', מערכת GKE יוצרת NEG אחד לכל אזור חישוב לכל שירות מאזן עומסים פנימי.

ה-externalTrafficPolicy של Service controls קובע את החברות בצומת ב-GCE_VM_IPNEG backends. מידע נוסף זמין במאמר בנושא חברוּת של צמתים ב-GCE_VM_IP NEG backends.

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

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

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

דרישות ומגבלות

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

דרישות

אלו הדרישות והמגבלות שחלות על חלוקת משנה של GKE:

אפשר להפעיל חלוקה לקבוצות משנה ב-GKE באשכולות חדשים וקיימים מסוג Standard בגרסאות GKE‏ ‎1.18.19-gke.1400 ואילך. אחרי שמפעילים את התכונה 'חלוקת משנה ב-GKE', אי אפשר להשבית אותה.
האפשרות 'חלוקת משנה של GKE' מושבתת כברירת מחדל באשכולות Autopilot. עם זאת, אפשר להפעיל אותו אחרי שיוצרים את האשכול.
כדי להשתמש ב-GKE subsetting צריך להפעיל את התוסף HttpLoadBalancing. התוסף הזה מופעל כברירת מחדל. ב-Autopilot clusters, אי אפשר להשבית את התוסף הנדרש הזה.
ההקצאות של קבוצות נקודות קצה ברשת חלות. Google Cloud יוצרת קבוצת נקודות קצה ברשת אחת לכל שירות LoadBalancer פנימי לכל אזור.GCE_VM_IP
חלות מכסות על כללי העברה, שירותים לקצה העורפי ובדיקות תקינות. מידע נוסף מופיע במאמר בנושא מכסות ומגבלות.
אי אפשר להשתמש בהערה alpha.cloud.google.com/load-balancer-backend-share כדי לשתף שירות קצה עורפי בין כמה מאזני עומסים.
צריך להשתמש ב-Google Cloud CLI בגרסה 345.0.0 ואילך.

יש דרישות מסוימות לשימוש בתכונה 'זיקה לאזור':

אפשר להפעיל את התכונה 'זיקה אזורית' באשכולות חדשים וקיימים ב-GKE בגרסה 1.33.3-gke.1392000 ואילך.
צריך להפעיל את התכונה 'חלוקת משנה ב-GKE'.
צריך לוודא שהתוסף HttpLoadBalancing מופעל באשכול. התוסף הזה מופעל כברירת מחדל ומאפשר לאשכול לנהל מאזני עומסים שמשתמשים בשירותי קצה עורפי.
חובה לכלול את spec.trafficDistribution: PreferClose במניפסט של LoadBalancer Service.

במניפסט של שירות LoadBalancer אפשר להשתמש ב-externalTrafficPolicy: Local או ב-externalTrafficPolicy: Cluster.

מגבלות

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

באשכולות שמופעלת בהם גרסה 1.7.4 של Kubernetes ואילך, אפשר להשתמש במאזני עומסים פנימיים עם תת-רשתות במצב מותאם אישית בנוסף לתת-רשתות במצב אוטומטי.
אשכולות שמריצים את Kubernetes בגרסה 1.7.X ואילך תומכים בשימוש בכתובת IP שמורה עבור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, אם יוצרים את כתובת ה-IP השמורה עם ההגדרה --purpose של הדגל SHARED_LOADBALANCER_VIP. הוראות מפורטות זמינות במאמר בנושא הפעלת כתובת IP משותפת. ‫GKE שומר רק את כתובת ה-IP של מאזן עומסי רשת פנימי מסוג passthrough Network Load Balancer אם ה-Service מפנה לכתובת IP פנימית למטרה הזו. אחרת, יכול להיות ש-GKE ישנה את כתובת ה-IP של איזון העומסים (spec.loadBalancerIP) אם השירות יעודכן (למשל, אם יחול שינוי ביציאות).
גם אם כתובת ה-IP של מאזן העומסים משתנה (ראו את הנקודה הקודמת), הערך של spec.clusterIP נשאר קבוע.
מאזני עומסים פנימיים מסוג UDP לא תומכים בשימוש ב-sessionAffinity: ClientIP.

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

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

מפעילים את ממשק 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.

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

אפשר להפעיל את התכונה 'חלוקת משנה של GKE' באשכול קיים באמצעות ה-CLI של gcloud או מסוף Google Cloud . אי אפשר להשבית את חלוקת המשנה של GKE אחרי שמפעילים אותה.

המסוף

במסוף 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 \
    --enable-l4-ilb-subsetting

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

‫CLUSTER_NAME: שם האשכול.

הפעלת חלוקת המשנה של GKE לא משבשת את השירותים הקיימים של מאזן העומסים הפנימי. אם רוצים להעביר שירותים קיימים של LoadBalancer פנימיים לשימוש בשירותי קצה עורפי עם קבוצות NEGs של GCE_VM_IP כקצה עורפי, צריך לפרוס מניפסט שירות חלופי. פרטים נוספים זמינים במאמר Node grouping (קיבוץ צמתים) במסמכי העזרה בנושא מושגים של שירות LoadBalancer.

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

קובץ המניפסט הבא מתאר 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  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
```
  קובץ המניפסט צריך לכלול את הפרטים הבאים:
  - כתובת IP name לשירות LoadBalancer הפנימי, במקרה הזה ilb-svc.
  - הערה שמציינת שנדרש שירות LoadBalancer פנימי. בגרסאות GKE 1.17 ואילך, משתמשים בהערה networking.gke.io/load-balancer-type: "Internal" כמו שמוצג במניפסט לדוגמה. בגרסאות קודמות, צריך להשתמש ב-cloud.google.com/load-balancer-type: "Internal" במקום זאת.
  - הtype: LoadBalancer.
  - שדה spec: selector לציון ה-Pods שאליהם השירות צריך לטרגט, לדוגמה, app: hello.
  - פרטי הניוד:
    - הערך port מייצג את יציאת היעד שבה כלל ההעברה של מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי מקבל חבילות.
    - הערך של targetPort חייב להיות זהה לערך של containerPort שמוגדר בכל Pod של שרת.
    - הערכים של port ושל targetPort לא צריכים להיות זהים. הצמתים תמיד מבצעים NAT של היעד, ומשנים את כתובת ה-IP של כלל ההעברה של מאזן העומסים של היעד ואת port לכתובת ה-IP של יעד הפוד ואת targetPort. פרטים נוספים זמינים במאמר תרגום כתובות רשת של יעד בצמתים במסמכי העזרה בנושא מושגים של שירות LoadBalancer.
  המניפסט יכול להכיל את הרכיבים הבאים:
  - ‫spec.ipFamilyPolicy ו-ipFamilies כדי להגדיר איך GKE מקצה כתובות IP לשירות. ‫GKE תומך בשירותים של איזון עומסים עם כתובות IP מסוג single-stack (IPv4 בלבד או IPv6 בלבד) או dual-stack. שירות LoadBalancer עם תמיכה כפולה בפרוטוקולים מיושם באמצעות שני כללי העברה נפרדים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי: אחד לתעבורת IPv4 ואחד לתעבורת IPv6. השירות GKE dual-stack LoadBalancer זמין בגרסה 1.29 ואילך. למידע נוסף, ראו שירותים עם מחסנית כפולה של IPv4/IPv6.
  - ‫spec.trafficDistribution כדי להגדיר איך GKE מנתב תנועה נכנסת (גרסת Preview). אם מגדירים את השדה הזה לערך PreferClose, תנועה שמגיעה מאזור מסוים מנותבת ב-GKE לצמתים ול-Pods באותו אזור. אם אין פודים תקינים באזור, GKE מעביר את התנועה לאזור אחר. אם כוללים את השדה הזה, צריך להפעיל את התכונה GKE subsetting.
    
    הערה: אפשר גם להפעיל או להשבית את ההעדפה האזורית בשירות 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: PreferClose
  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.
כל פוד עם התווית app: ilb-deployment הוא פוד להצגת מודעות בשירות הזה. אלה ה-Pods שמקבלים חבילות שמועברות על ידי מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי.
לקוחות מתקשרים לשירות באמצעות כתובת ה-IP הזו ויציאת היעד של TCP שמצוינת בשדה port של מניפסט השירות.loadBalancer לפרטים מלאים על אופן ניתוב המנות לאחר קבלתן בצומת, ראו עיבוד מנות.
מערכת 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.

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

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

מוודאים שהשירות פועל:
```
kubectl get service SERVICE_NAME --output yaml
```
מחליפים את SERVICE_NAME בשם של מניפסט השירות.

אם הפעלתם את ההגדרה 'שיוך לאזור', הפלט כולל את הפרמטר spec.trafficDistribution כשהשדה מוגדר לערך PreferClose.
מאמתים את כתובת ה-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-tcp-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 שבו פועל שירות קצה עורפי.

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

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

curl LOAD_BALANCER_IP:80

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

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

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

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

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

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

kubectl

מחיקת הפריסה

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

kubectl delete deployment ilb-deployment

מחיקת השירות

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

kubectl delete service ilb-svc

המסוף

מחיקת הפריסה

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

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

כניסה לדף Workloads
בוחרים את הפריסה שרוצים למחוק ולוחצים על מחיקה.
כשמוצגת בקשה לאישור, מסמנים את התיבה Delete Horizontal Pod Autoscaler associated with selected Deployment (מחיקת Horizontal Pod Autoscaler שמשויך לפריסה שנבחרה) ואז לוחצים על Delete (מחיקה).

מחיקת השירות

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

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

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

כתובת 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 משותפת, פועלים לפי השלבים הבאים:

יוצרים כתובת 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # 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
```

בעיות מוכרות

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

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

‫1.18.19-gke.1700 ואילך
‫1.19.10-gke.1000 ואילך
‫1.20.6-gke.1000 ואילך

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

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

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 subsetting

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

דרישות ומגבלות

דרישות

מגבלות

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

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

המסוף

gcloud

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

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

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

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

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

kubectl

מחיקת הפריסה

מחיקת השירות

המסוף

מחיקת הפריסה

מחיקת השירות

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

מגבלות

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

בעיות מוכרות

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

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

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

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