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

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

Autopilot Standard

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

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

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

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

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

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-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 כדי ליצור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם קצוות עורפיים של קבוצות NEG מסוג GCE_VM_IP. במדריך הזה צריך להשתמש בגרסה ‎1.33.1-gke.1779000 או בגרסה חדשה יותר של GKE, כי spec.loadBalancerClass דורש את גרסה ‎1.33.1-gke.1779000 או גרסה חדשה יותר של GKE.
כדי להשתמש ב-Zonal affinity, צריך את גרסה ‎1.33.3-gke.1392000‎ ואילך של GKE.
באשכול שלכם צריכה להיות מופעלת הגדרת המשנה של GKE:
- הגדרת קבוצת משנה ב-GKE מופעלת כברירת מחדל באשכולות שפועלים בגרסה 1.36 ואילך. בגרסאות האלה, הגדרת קבוצת המשנה פעילה בלי קשר לערך של דגל הגדרת קבוצת המשנה של האשכול.
- בגרסאות נתמכות של GKE לפני גרסה 1.36, צריך להפעיל את GKE subsetting באופן מפורש. אפשר להפעיל את GKE subsetting כשיוצרים אשכול חדש או כשמעדכנים אשכול קיים. אחרי שמפעילים את GKE subsetting, אי אפשר להשבית אותו. מידע נוסף מופיע במאמר אימות והפעלה של חלוקת משנה ב-GKE.
אם גרסת האשכול שלכם היא לפני 1.36, צריך להפעיל את התוסף HttpLoadBalancing באשכול. התוסף הזה מופעל כברירת מחדל.
כדי להפעיל את Cloud Logging לשירות LoadBalancer פנימי, אשכול GKE צריך להיות בגרסה 1.36.0-gke.2459000 ואילך.

אימות והפעלה של הגדרת קבוצות משנה ב-GKE

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

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

כדי להבין למה חשוב להשתמש בקבוצות משנה ב-GKE, קראו את המאמר שיקולים מיוחדים לשירותי LoadBalancer פנימיים.

כדי לבדוק אם האפשרות "הגדרת קבוצת משנה ב-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 subsetting באשכול שפועל בגרסה 1.18.19-gke.1400 ואילך של GKE, אבל לפני גרסה 1.36 של GKE, משתמשים ב-CLI של gcloud או במסוף Google Cloud .

המסוף

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

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

gcloud

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

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

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

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

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

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

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

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

למידע נוסף על ניהול כללים של חומת אש ב-VPC, קראו את המאמר ניהול יצירה אוטומטית של כללים של חומת אש. כדי להבין איך משביתים את היצירה האוטומטית של כללים של חומת אש, קראו את המאמר כללים של חומת אש בניהול המשתמשים לשירותי GKE LoadBalancer.
בדוגמה הבאה נוצר שירות LoadBalancer פנימי באמצעות יציאת TCP‏ 80. ‫GKE פורס מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שכלל ההעברה שלו משתמש ביציאה 80, אבל אז מעביר את התנועה לפודים של הקצה העורפי ביציאה 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 כדי לציין את הפודים שהשירות צריך לטרגט, לדוגמה app: hello.
  - פרטי היציאה:
    - המשתנה port מייצג את יציאת היעד שבה כלל ההעברה של מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי מקבל חבילות.
    - הערך של targetPort חייב להתאים לערך של containerPort שמוגדר בכל Pod שמציג מודעות.
    - הערכים של port ו-targetPort לא חייבים להיות זהים. הצמתים תמיד מבצעים NAT של היעד, ומשנים את כתובת ה-IP של כלל ההעברה של מאזן העומסים של היעד ואת port לכתובת IP של Pod של היעד ול-targetPort. פרטים נוספים זמינים במאמר תרגום כתובת רשת של יעד בצמתים, במסמכי העזרה בנושא מושגים של שירות LoadBalancer.
  המניפסט יכול להכיל את הפרטים הבאים:
  - ‫spec.ipFamilyPolicy ו-ipFamilies כדי להגדיר איך GKE מקצה כתובות IP לשירות. ‫GKE תומך בשירותי IP LoadBalancer עם סטאק יחיד (IPv4 בלבד או IPv6 בלבד) או עם סטאק כפול. שירות LoadBalancer עם סטאק כפול מוטמע באמצעות שני כללי העברה נפרדים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי: אחד לתנועת IPv4 ואחד לתנועת IPv6. שירות LoadBalancer עם מחסנית כפולה ב-GKE זמין בגרסה 1.29 ואילך. כדי ליצור שירות IPv6 במחסנית אחת באשכול עם מחסנית כפולה, מגדירים את הערך של השדה spec.ipFamilyPolicy ל-SingleStack ואת הערך של השדה spec.ipFamilies ל-IPv6. באשכול IPv6 עם מחסנית אחת, אלה ערכי ברירת המחדל ואפשר להשמיט אותם. מידע נוסף זמין במאמר שירותים עם מחסנית כפולה של IPv4/IPv6.
  - spec.trafficDistribution כדי להגדיר איך GKE מנתב את התנועה הנכנסת. כדי להפעיל את השיוך לאזור, מגדירים את הערך של השדה הזה ל-PreferSameZone. המשמעות של שיוך לאזור היא ש-GKE נותן עדיפות לניתוב תנועה שמגיעה מאזור מסוים לצמתים ול-Pods באותו אזור. אם אין Pods תקינים באותו אזור, התנועה מנותבת לאזור אחר. בגרסאות אשכול שקודמות ל-1.35.0-gke.1811000, צריך להשתמש בערך PreferClose. כדי להשתמש ב-Zonal affinity, צריך להפעיל את 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: 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.

יצירת שירות LoadBalancer פנימי באשכול IPv6 עם מחסנית אחת

כשפורסים שירות LoadBalancer פנימי עם מחסנית אחת של IPv6 באשכול עם מחסנית אחת של IPv6 או באשכול עם מחסנית כפולה, רשת המשנה שבה משתמש מאזן העומסים תלויה בסוג הגישה של IPv6 (INTERNAL או EXTERNAL) שבו משתמשת רשת המשנה של הצומת באשכול. באשכול עם מחסנית כפולה, צריך להגדיר את הערך של השדה spec.ipFamilyPolicy ל-SingleStack ואת הערך של השדה spec.ipFamilies ל-IPv6 (באשכול IPv6 עם מחסנית אחת, אלה ערכי ברירת המחדל ואפשר להשמיט אותם). כדי ליצור שירות עם מחסנית כפולה, מגדירים את הערך של השדה spec.ipFamilyPolicy ל-RequireDualStack ומציינים את שתי משפחות הכתובות בשדה spec.ipFamilies:

אשכולות עם צמתים פנימיים (סוג גישה INTERNAL ULA): אם צומתי האשכול פועלים ברשת משנה פנימית עם כתובות Unique Local Unicast ‏(ULA), מאזן העומסים הפנימי משתמש באופן אוטומטי ברשת המשנה הקיימת של הצומת. יוצרים את השירות בלי הערות של רשתות משנה בהתאמה אישית:
```
apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080
```
אשכולות עם צמתים חיצוניים (סוג גישה EXTERNAL GUA): אם צומתי האשכול פועלים ברשת משנה חיצונית עם כתובות Global Unicast ‏(GUA), מאזן עומסים פנימי לא יכול להשתמש ברשת המשנה הזו באופן ישיר. צריך להקצות רשת משנה ייעודית פנימית (INTERNAL) של IPv6 ולהפנות לרשת המשנה באמצעות ההערה networking.gke.io/load-balancer-subnet ב-Service:
1. יוצרים רשת משנה ייעודית פנימית של IPv6:
```
gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫SUBNET_NAME: השם של תת-הרשת שרוצים ליצור.
  - ‫NETWORK_NAME: השם של רשת ה-VPC שבה יוצרים את רשת המשנה הזו.
  - COMPUTE_REGION: האזור ב-Compute Engine של רשת המשנה.
2. יוצרים את השירות ומפנים לשם של רשת המשנה מהשלב הקודם בהערה networking.gke.io/load-balancer-subnet:
```
apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: SUBNET_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080
```

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

kubectl get svc ilb-ipv6-svc

הפלט מאשר שהעמודות CLUSTER-IP ו-EXTERNAL-IP (כתובת ULA פנימית) מאוכלסות:

NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP               PORT(S)        AGE
ilb-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c549   fd20:f5d:a91f:3:0:9:0:0   80:30234/TCP   3m

מידע נוסף מופיע במאמר שירותי LoadBalancer ב-IPv6.

שימוש בכתובות IPv6 משלכם (BYOIPv6)

כדי להגדיר שירות LoadBalancer פנימי של IPv6 עם כתובות IPv6 משלכם (BYOIPv6), צריך ליצור רשת משנה עם טווח כתובות BYOIPv6 פנימיות ולהפנות לרשת המשנה בשירות. טווח כתובות ה-IPv6 של רשת המשנה חייב להגיע מקידומת משנה אזורית של IPv6 של קידומת ציבורית שהוקצתה (PDP) במצב INTERNAL_IPV6_SUBNETWORK_CREATION.

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

באותו אזור ורשת VPC של האשכול, יוצרים רשת משנה עם טווח BYOIPv6 פנימי מהקידומת המשנית:
```
gcloud compute networks subnets create BYOIP_SUBNET_NAME \
    --network=NETWORK_NAME \
    --region=REGION \
    --stack-type=IPV6_ONLY \
    --ipv6-access-type=INTERNAL \
    --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BYOIP_SUBNET_NAME: השם של תת-הרשת החדשה.
- ‫NETWORK_NAME: השם של רשת ה-VPC של האשכול.
- ‫REGION: האזור של האשכול.
- ‫PROJECT_ID: מזהה הפרויקט שמכיל את הקידומת המשנית.
- ‫SUB_PREFIX_NAME: השם של הקידומת המשנית האזורית במצב INTERNAL_IPV6_SUBNETWORK_CREATION.
אופציונלי: שומרים טווח סטטי פנימי של כתובות IPv6 ב-/96 מתוך רשת המשנה של BYOIPv6. אם מדלגים על השלב הזה, GKE מקצה באופן אוטומטי טווח כתובות BYOIPv6 פנימיות זמניות מרשת המשנה שציינתם בהערה networking.gke.io/load-balancer-subnet:
```
gcloud compute addresses create STATIC_IPV6_NAME \
    --region=REGION \
    --subnet=BYOIP_SUBNET_NAME \
    --ip-version=IPV6
```
מחליפים את STATIC_IPV6_NAME בשם של משאב כתובת ה-IPv6 הסטטית.

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

apiVersion: v1
kind: Service
metadata:
  name: ilb-byoipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: BYOIP_SUBNET_NAME
    # Optional: To use a static address, uncomment the following line
    # networking.gke.io/load-balancer-ip-addresses: STATIC_IPV6_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: ilb-deployment
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

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

אופציונלי: אם שמרתם כתובת BYOIPv6 פנימית סטטית בשלב הקודם, בטלו את ההערה networking.gke.io/load-balancer-ip-addresses והחליפו את STATIC_IPV6_NAME בשם של משאב כתובת ה-IPv6 הסטטית.

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

מידע נוסף זמין במאמר שימוש בכתובות IPv6 משלכם (BYOIPv6).

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

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

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

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

‫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 שלה יותאמו בנפרד על סמך מדדים מקומיים.
שירות משותף אחד: חשיפת כל פריסות ה-Deployment האלה מאחורי שירות LoadBalancer פנימי אחד שמוגדר עם זיקה אזורית (באמצעות אותו בורר).

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

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

יוצרים פריסה נפרדת לכל אזור. הפריסות חולקות את אותה תווית 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
```

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

בקטע הזה מוסבר איך לאמת את הרכיבים העיקריים של מאזן עומסי הרשת הפנימי עם העברה (pass-through).

מוודאים שהשירות פועל:
```
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) של הקצה העורפי 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: אזור המחשוב של השירות לקצה העורפי שבו רוצים לבצע את הפעולה.
מוודאים ש-Cloud Logging הופעל בשירות:
```
kubectl get svc SERVICE_NAME --output yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: שם השירות.
בפלט, מוודאים שהשדה Status.Conditions מכיל את הערכים Type: LoggingConfigManaged ו-Reason: Reconciled.

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

אפשר לגשת למאזן עומסי רשת פנימי רק מתוך אותה רשת VPC (או רשת מחוברת). כברירת מחדל, הגישה הגלובלית מושבתת בכלל ההעברה של מאזן העומסים, כך שהמכונות הווירטואליות של הלקוח, מנהרות Cloud VPN או החיבורים ל-Cloud Interconnect (רשתות VLAN) צריכים להיות באותו אזור שבו נמצא מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. כדי לתמוך בלקוחות בכל האזורים, אפשר להפעיל גישה גלובלית בכלל ההעברה של מאזן העומסים, על ידי הוספת ההערה 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
בוחרים את הפריסה שרוצים למחוק ולוחצים על Delete.
כשמוצגת בקשה לאישור, מסמנים את התיבה Delete HorizontalPodAutoscaler associated with selected Deployment ולוחצים על Delete.

מחיקת השירות

כדי למחוק את השירות:

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

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

כתובת 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 משותפת נתמכת רק בכתובות IPv4 פנימיות. אי אפשר לשתף טווח סטטי פנימי של כתובות IPv6 בין כמה שירותי LoadBalancer פנימיים.

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

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

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

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

בעיות מוכרות

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

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

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, צריך להגדיר את מסלול הרשת של הפרויקט כ-Premium.

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

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

שגיאה בשימוש בהערה `networking.gke.io/ip-collection-v6` בשירות LoadBalancer פנימי

כשמוסיפים את ההערה networking.gke.io/ip-collection-v6 לשירות LoadBalancer פנימי, GKE מפיק אירוע אזהרה מסוג IPCollectionV6Error עם ההודעה הבאה:

networking.gke.io/ip-collection-v6 is not supported for Internal LoadBalancers. To use BYOIPv6 with ILB, specify a BYOIP subnet using the "networking.gke.io/load-balancer-subnet" annotation

ההערה networking.gke.io/ip-collection-v6 רלוונטית רק לשירותי LoadBalancer חיצוניים עם מחסנית אחת של IPv6. כדי להשתמש בכתובות BYOIPv6 עם שירות LoadBalancer פנימי, צריך ליצור תת-רשת עם טווח כתובות IPv6 פנימיות מקידומת ציבורית שהוקצתה במצב INTERNAL_IPV6_SUBNETWORK_CREATION. מציינים את רשת המשנה הזו באמצעות ההערה networking.gke.io/load-balancer-subnet. מידע נוסף זמין במאמר שימוש בכתובות IPv6 משלכם (BYOIPv6).

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

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

דרישות

אימות והפעלה של הגדרת קבוצות משנה ב-GKE

המסוף

gcloud

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

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

יצירת שירות LoadBalancer פנימי באשכול IPv6 עם מחסנית אחת

שימוש בכתובות IPv6 משלכם (BYOIPv6)

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

התאמה לעומס של עומסי עבודה עם שיוך לאזור

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

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

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

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

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

kubectl

מחיקת הפריסה

מחיקת השירות

המסוף

מחיקת הפריסה

מחיקת השירות

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

מגבלות

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

בעיות מוכרות

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

שגיאה בשימוש בהערה networking.gke.io/ip-collection-v6 בשירות LoadBalancer פנימי

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

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

שגיאה בשימוש בהערה `networking.gke.io/ip-collection-v6` בשירות LoadBalancer פנימי