Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

איזון עומסים שמקורם בקונטיינר באמצעות קבוצות עצמאיות של נקודות קצה ברשת (NEGs) אזוריות

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

בדף הזה מוסבר איך ליצור שירות Kubernetes שמגובה על ידי קבוצת נקודות קצה ברשת GCE_VM_IP_PORT אזורית (NEG) באשכול מקורי של VPC ב-Google Kubernetes Engine ‏ (GKE).

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

סקירה כללית

NEG מייצג קבוצה של נקודות קצה. ‫GKE תומך ב-NEGs עצמאיים מסוג GCE_VM_IP_PORT. GCE_VM_IP_PORT קבוצות NEG תומכות בנקודות קצה שמשתמשות בכתובת ה-IP הפנימית הראשית של מכונת ה-VM או בכתובת IP מאחד מטווח כתובות ה-IP של הכינוי שלה.

בהקשר של אשכול GKE מסוג VPC-native שמשתמש ב-NEGs עצמאיים, כל נקודת קצה היא כתובת IP של Pod ויציאת יעד. כתובות ה-IP של ה-Pod מגיעות מטווח כתובות ה-IP של הכינוי של הצומת עבור Pods, שמגיע מטווח כתובות ה-IP המשני של תת-הרשת של האשכול עבור Pods.

‫GKE מספק בקר NEG לניהול החברות ב-NEG מסוג GCE_VM_IP_PORT. אפשר להוסיף את ה-NEGs שנוצרים כקצה עורפי לשירותי הקצה העורפי של מאזני עומסים שמוגדרים מחוץ ל-GKE API.

בתרשים הבא מתואר הקשר בין אובייקטים של Kubernetes API לבין אובייקטים של Compute Engine.

שירותי Kubernetes תואמים לקבוצות של נקודות קצה ברשת ב-Compute Engine, ותאי Kubernetes תואמים לנקודות קצה ברשת ב-Compute Engine. רכיב בקר ה-NEG של מישור הבקרה מנהל את זה.

תעבורת נתונים נכנסת (ingress) עם קבוצות של נקודות קצה לרשת (NEGs)

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

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

קבוצות עצמאיות של נקודות קצה ברשת (NEGs)

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

קבוצות NEGs עצמאיות לא מתנגשות עם איזון עומסים ברמת הקונטיינר בתעבורת נתונים נכנסת (Ingress).

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

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

מניעת הדלפות של קבוצות NEG

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

כאשר שירות GKE נמחק, ה-NEG המשויך לא יאסוף כזבל אם ה-NEG עדיין מופנה על ידי שירות backend. כדי לאפשר מחיקה של ה-NEG, צריך לבטל את ההפניה ל-NEG משירות הקצה העורפי.
כשמ删除 אשכול, קבוצות עצמאיות של נקודות קצה ברשת לא יימחקו בתרחישים הבאים:
- ה-NEG עדיין מפנה לשירות קצה עורפי.
- תהליך המחיקה של האשכול משבית את בקר ה-NEG לפני שהבקר יכול למחוק את ה-NEG.
כדי למנוע דליפה של קבוצות NEG, צריך לבטל את ההפניה של קבוצת ה-NEG משירות ה-backend ולמחוק את כל קבוצות ה-NEG לפני שמוחקים את האשכול.

אם אחרי מחיקת האשכול או השירות נשארו NEGs שלא נמחקו, אפשר למחוק את ה-NEGs באמצעות Google Cloud CLI.

תרחישים לדוגמה לשימוש ב-NEGs עצמאיים

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

תרחישי שימוש ב-NEGs עצמאיים:

שירותים הטרוגניים של קונטיינרים ומכונות וירטואליות

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

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

בקרי Ingress בהתאמה אישית

אפשר להשתמש בבקר Ingress מותאם אישית (או ללא בקר Ingress) כדי להגדיר מאזני עומסים שמטרגטים קבוצות עצמאיות של נקודות קצה ברשת (NEGs).

שימוש ב-Cloud Service Mesh עם GKE

אפשר להשתמש ב-Cloud Service Mesh עם GKE. ‫Cloud Service Mesh משתמש ב-NEGs עצמאיים כדי לספק איזון עומסים מובנה בקונטיינרים עבור רשת השירותים המנוהלת.

שימוש במאזני עומסים חיצוניים של רשת בשרת proxy עם GKE

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

מוכנות של Pod

שערי מוכנות הם תכונת הרחבה של Kubernetes שמאפשרת להוסיף משוב או אותות נוספים ל-PodStatus כדי לאפשר ל-Pod לעבור למצב Ready. בקר ה-NEG מנהל שער מוכנות מותאם אישית כדי לוודא שנתיב הרשת המלא ממאזן העומסים של Compute Engine אל ה-Pod פועל. הסבר על שערי מוכנות של Pod ב-GKE מופיע במאמר בנושא איזון עומסים שמקורם בקונטיינר.

ב-Ingress עם NEGs, בדיקות התקינות של Compute Engine נפרסות ומנוהלות בשם מאזן העומסים. עם זאת, קבוצות NEGs עצמאיות לא מניחות הנחות לגבי בדיקות התקינות של Compute Engine, כי הן אמורות להיות מוטמעות ומנוהלות בנפרד. תמיד צריך להגדיר בדיקות תקינות ב-Compute Engine יחד עם איזון העומסים, כדי למנוע שליחת תעבורה לקצוות עורפיים שלא מוכנים לקבל אותה. אם אין סטטוס של בדיקת תקינות שמשויך ל-NEG (בדרך כלל כי לא מוגדרת בדיקת תקינות), אז בקר ה-NEG יסמן את ערך שער המוכנות של ה-Pod כ-True כשהנקודה המתאימה שלו מתוכנתת ב-NEG.

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

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

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

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, עליכם להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים של VPC-native. צריך להפעיל את התוסף HttpLoadBalancing באשכול. במערכות GKE חדשות, התוסף HttpLoadBalancing מופעל כברירת מחדל.

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

שימוש בקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

בהוראות הבאות מוסבר איך להשתמש ב-NEGs עצמאיים עם מאזן עומסים חיצוני של HTTP ב-GKE.

צריך ליצור את האובייקטים הבאים:

פריסה שיוצרת ומנהלת פודים.
שירות שיוצר NEG.
מאזן עומסים שנוצר באמצעות Compute Engine API. זה שונה משימוש ב-NEGs עם Ingress, שבו Ingress יוצר ומגדיר מאזן עומסים בשבילכם. כשמשתמשים ב-NEGs עצמאיים, האחריות לקישור בין ה-NEG לבין שירות ה-Backend כדי לחבר את ה-Pods למאזן העומסים מוטלת על המשתמש. מאזן העומסים מורכב מכמה רכיבים, שמוצגים בתרשים הבא:

הרכיבים של מאזן עומסים הם כלל העברה, שרת proxy HTTP ביעד, מיפוי של כתובות URL, בדיקת תקינות ושירות לקצה העורפי. התנועה מופנית ל-NEG שמכיל כתובות IP של רצפי מודעות.

יצירת פריסה

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

מומלץ להשתמש בעומסי עבודה שמשתמשים במשוב על מוכנות של Pod.

שימוש במשוב על מוכנות ה-Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/e2e-test-images/agnhost:2.40 # Application to run in Deployment's Pods
        name: hostname
        args:
        - serve-hostname
        - --port=9376

שימוש בעיכוב שמוגדר בקוד

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/e2e-test-images/agnhost:2.40 # Application to run in Deployment's Pods
        name: hostname
        args:
        - serve-hostname
        - --port=9376

שומרים את קובץ המניפסט הזה בשם neg-demo-app.yaml, ואז יוצרים את הפריסה באמצעות הפקודה הבאה:

kubectl apply -f neg-demo-app.yaml

יצירת שירות

המניפסט הבא מציין שירות שבו:

כל Pod עם התווית run: neg-demo-app הוא חבר בשירות הזה.
לשירות יש שדה ServicePort עם יציאה 80.
ההערה cloud.google.com/neg מציינת שהיציאה 80 תשויך ל-NEG. השדה האופציונלי name מציין שה-NEG ייקרא NEG_NAME. אם לא מציינים את השדה name, המערכת תיצור שם ייחודי באופן אוטומטי. פרטים נוספים זמינים במאמר בנושא מתן שמות ל-NEGs.
לכל Pod של חבר צריך להיות מאגר שמקשיב ליציאת TCP‏ 9376.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

מחליפים את NEG_NAME בשם של ה-NEG. השם של ה-NEG חייב להיות ייחודי באזור שלו.

שומרים את המניפסט הזה בשם neg-demo-svc.yaml, ואז יוצרים את השירות על ידי הרצת הפקודה הבאה:

kubectl apply -f neg-demo-svc.yaml

רשת NEG נוצרת תוך כמה דקות מיצירת השירות.

סוגי השירותים

בדוגמה הזו נעשה שימוש בשירות ClusterIP, אבל כל חמשת סוגי השירותים תומכים ב-NEGs עצמאיים. מומלץ להשתמש בסוג ברירת המחדל, ClusterIP.

מתן שמות ל-NEGs

בגרסאות GKE‏ ‎1.18.18-gke.1200 ואילך, אפשר לציין שם בהתאמה אישית ל-NEGs, או ש-GKE יכול ליצור שם באופן אוטומטי. גרסאות קודמות של GKE תומכות רק בשמות של NEG שנוצרו באופן אוטומטי.

‫GKE יוצר NEG אחד בכל אזור שבו נעשה שימוש באשכול. לכל קבוצות ה-NEG יש את אותו שם.

ציון שם

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

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

משתמשים בשדה name בהערה cloud.google.com/neg של השירות כדי לציין שם של NEG:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

מחליפים את NEG_NAME בשם של ה-NEG. השם של ה-NEG חייב להיות ייחודי באזור שלו.

שימוש בשם שנוצר באופן אוטומטי

השמות של קבוצות ה-NEG שנוצרים באופן אוטומטי הם ייחודיים. כדי להשתמש בשם שנוצר אוטומטית, משמיטים את השדה name:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

השם שנוצר אוטומטית הוא בפורמט הבא:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

מיפוי יציאות לכמה קבוצות של נקודות קצה ברשת (NEGs)

שירות יכול להאזין ליותר מיציאה אחת. בהגדרה, ל-NEGs יש רק כתובת IP אחת ויציאה אחת. כלומר, אם תציינו שירות עם כמה יציאות, תיווצר קבוצת נקודות קצה ברשת (NEG) לכל יציאה.

הפורמט של ההערה cloud.google.com/neg הוא:

cloud.google.com/neg: '{
   "exposed_ports":{
      "SERVICE_PORT_1":{},
      "SERVICE_PORT_2":{},
      "SERVICE_PORT_3":{},
      ...
   }
 }'

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

אחזור סטטוסים של קבוצות של נקודות קצה (NEG)

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

kubectl get service neg-demo-svc -o yaml

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

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

בפלט הזה, כל רכיב במיפוי network-endpoint-groups הוא יציאת שירות (למשל SERVICE_PORT_1) והשם של קבוצת ה-NEG המנוהלת התואמת (למשל NEG_NAME_1). הרשימה zones מכילה כל אזור (למשל ZONE_1) שיש בו קבוצת NEG.

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

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

בדוגמה הזו, ההערה מציינת שיציאת השירות 80 חשופה ל-NEGs בשם k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

אימות יצירת ה-NEG

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

יש שתי דרכים לוודא שקבוצת ה-NEG נוצרה ושהיא מוגדרת בצורה נכונה. ב-GKE 1.18.6-gke.6400 ואילך, משאב בהתאמה אישית ServiceNetworkEndpointGroup מאחסן מידע על הסטטוס של NEGs שנוצרו על ידי בקר השירות. בגרסאות קודמות, צריך לבדוק את קבוצות ה-NEG ישירות.

המשאב `ServiceNetworkEndpointGroup`

כדי להציג את רשימת ה-NEG באשכול, צריך לאחזר את כל משאבי ServiceNetworkEndpointGroup:

kubectl get svcneg

כדי לראות את הסטטוס של קבוצת נקודות קצה ברשת (NEG), בודקים את הסטטוס של משאב ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

מחליפים את NEG_NAME בשם של קבוצת ה-NEG הספציפית שרוצים לבדוק.

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

kubectl describe service SERVICE_NAME

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

כדי לוודא שבקר ה-NEG מסנכרן את ה-NEG בהצלחה, בודקים את שדה הסטטוס של משאב ServiceNetworkEndpointGroup אם יש תנאי עם type:Synced. השעה של הסנכרון האחרון מופיעה בשדה status.lastSyncTime.

משאבי ServiceNetworkEndpointGroup קיימים רק ב-GKE מגרסה 1.18 ואילך.

בדיקה ישירה של NEGs

כדי לוודא שקבוצת ה-NEG קיימת, מציגים את רשימת קבוצות ה-NEG בפרויקט Google Cloud ובודקים אם יש קבוצת NEG שתואמת לשירות שיצרתם. השם של ה-NEG הוא בפורמט הבא:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

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

gcloud compute network-endpoint-groups list

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

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

הפלט הזה מראה שערך ה-SIZE של ה-NEG הוא 3, כלומר יש לו שלוש נקודות קצה שמתאימות לשלושת ה-Pods בפריסה.

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

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

מחליפים את NEG_NAME בשם של ה-NEG שרוצים להציג את נקודות הקצה שלו.

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

INSTANCE                                           IP_ADDRESS  PORT
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

צירוף מאזן עומסים חיצוני של אפליקציות (ALB) לקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

אתם יכולים להשתמש ב-NEGs כבק-אנד למאזן עומסים חיצוני של אפליקציות באמצעות Compute Engine API.

יוצרים כלל לחומת האש. מאזני עומסים צריכים לגשת לנקודות הקצה של האשכול כדי לבצע בדיקות תקינות. הפקודה הזו יוצרת כלל לחומת האש כדי לאפשר גישה:
```
gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
   --network=NETWORK_NAME \
   --action=allow \
   --direction=ingress \
   --target-tags=GKE_NODE_NETWORK_TAGS \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 \
   --rules=tcp:9376
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NETWORK_NAME: הרשת שבה האשכול פועל.
- ‫GKE_NODE_NETWORK_TAGS: תגי הרישות בצומתי GKE.
אם לא יצרתם תגי רשת מותאמים אישית לצמתים, GKE יוצר בשבילכם תגים באופן אוטומטי. כדי לחפש את התגים שנוצרו, מריצים את הפקודה הבאה:
```
gcloud compute instances describe INSTANCE_NAME
```
מחליפים את INSTANCE_NAME בשם של המכונה הווירטואלית המארחת של Compute Engine שבה פועל צומת GKE. לדוגמה, בפלט בקטע הקודם מוצגים שמות המופעים בעמודה INSTANCE עבור צמתי GKE.

במקרים של אשכולות רגילים, אפשר גם להריץ את הפקודה gcloud compute instances list כדי להציג רשימה של כל המופעים בפרויקט.

יוצרים כתובת IP וירטואלית גלובלית למאזן העומסים:

gcloud compute addresses create hostname-server-vip \
    --ip-version=IPV4 \
    --global

יצירת בדיקת תקינות. מאזן העומסים משתמש בבדיקה הזו כדי לזהות את מצב הפעילות של נקודות קצה ספציפיות ב-NEG.
```
gcloud compute health-checks create http http-basic-check \
    --use-serving-port
```

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

gcloud compute backend-services create my-bes \
    --protocol HTTP \
    --health-checks http-basic-check \
    --global

יוצרים מיפוי כתובות URL ושרת proxy ליעד למאזן העומסים. הדוגמה הזו פשוטה מאוד כי לאפליקציה serve_hostname שמשמשת במדריך הזה יש נקודת קצה אחת והיא לא כוללת כתובות URL.
```
gcloud compute url-maps create web-map \
    --default-service my-bes
```
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map web-map
```
יוצרים כלל העברה. כך נוצר מאזן העומסים.
```
gcloud compute forwarding-rules create http-forwarding-rule \
    --address=HOSTNAME_SERVER_VIP \
    --global \
    --target-http-proxy=http-lb-proxy \
    --ports=80
```
מחליפים את HOSTNAME_SERVER_VIP בכתובת ה-IP שבה רוצים להשתמש עבור מאזן העומסים. אם לא מציינים את הדגל --address, ‏ GKE מקצה באופן אוטומטי כתובת IP זמנית.

אפשר גם לשמור כתובת IP חיצונית סטטית חדשה.

נקודת ביקורת

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

כתובת IP וירטואלית חיצונית
כללי ההעברה
כללי חומת האש
שרת ה-Proxy ל-HTTP ביעד
מיפוי כתובות ה-URL של בדיקת התקינות של Compute Engine
השירות לקצה העורפי
בדיקת התקינות של Compute Engine

הקשר בין המשאבים האלה מוצג בתרשים הבא:

הקשר בין המשאבים שיצרתם.

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

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

הוספת קצה עורפי למאזן העומסים

משתמשים ב-gcloud compute backend-services add-backend כדי לחבר את ה-NEG למאזן העומסים על ידי הוספתו כקצה עורפי של שירות הקצה העורפי my-bes:

gcloud compute backend-services add-backend my-bes \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 5

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

‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת. השם הוא השם שציינתם כשיוצרים את ה-NEG או שם שנוצר אוטומטית. אם לא ציינתם שם ל-NEG, בהמשך מוסבר איך למצוא את השם שנוצר אוטומטית.
‫NEG_ZONE: האזור שבו נמצאת קבוצת נקודות הקצה ברשת. בהמשך מפורטות הוראות למציאת הערך הזה.

משתמשים בפקודה הזו כדי לקבל את השם והמיקום של ה-NEG:

gcloud compute network-endpoint-groups list

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

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

בדוגמה הזו, השם של קבוצת ה-NEG הוא k8s1-70aa83a6-default-my-service-80-c9710a6f.

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

בדיקה שהמאזן עומסים פועל

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

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

אימות של בדיקות תקינות

בודקים ששירות הקצה העורפי משויך לבדיקת תקינות ולקבוצות של נקודות קצה ברשת, ושהנקודות האישיות תקינות.

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

gcloud compute backend-services describe my-bes --global

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

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

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

gcloud compute backend-services get-health my-bes --global

הפלט של הקטע status: אמור להיראות כך:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

גישה לאפליקציה

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

קודם כל, מקבלים את כתובת ה-IP הווירטואלית של מאזן העומסים:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

הפלט יכלול כתובת IP. לאחר מכן, שולחים בקשה לכתובת ה-IP הזו (34.98.102.37 בדוגמה הזו):

curl 34.98.102.37

התשובה מאפליקציית serve_hostname צריכה להיות neg-demo-app.

צירוף מאזן עומסים פנימי של אפליקציות (ALB) לקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

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

הגדרת רשת המשנה ל-Proxy בלבד

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

המסוף

אם אתם משתמשים במסוף Google Cloud , אתם יכולים להמתין וליצור את רשת המשנה של ה-proxy בלבד מאוחר יותר.

gcloud

יוצרים את רשת המשנה מסוג proxy בלבד באמצעות הפקודה gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

מחליפים את COMPUTE_REGION בCompute Engine עבור רשת המשנה.

API

יוצרים את רשת המשנה של ה-proxy בלבד באמצעות השיטה subnetworks.insert.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

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

PROJECT_ID: מזהה הפרויקט.
‫COMPUTE_REGION: ‏Compute Engine עבור רשת המשנה.

הגדרת כללים לחומת אש

בדוגמה הזו נעשה שימוש בכללים הבאים של חומת האש:

‫fw-allow-ssh: כלל תעבורה נכנסת שחל על המופעים שמתבצע בהם איזון עומסים, ומאפשר קישוריות SSH נכנסת ביציאת TCP מספר 22 מכל כתובת. אפשר לבחור טווח כתובות IP של מקור שהוא מגביל יותר עבור הכלל הזה. לדוגמה, אפשר לציין רק את טווחי כתובות ה-IP של המערכת שממנה מתחילים סשנים של SSH. בדוגמה הזו, תג היעד allow-ssh משמש לזיהוי המכונות הווירטואליות שהכלל של חומת האש חל עליהן.
‫fw-allow-health-check: כלל כניסה (ingress) שחל על המופעים שמתבצע איזון עומסים ביניהם, ומאפשר את כל תעבורת ה-TCP ממערכות בדיקת התקינות (ב-130.211.0.0/22 וב-35.191.0.0/16). בדוגמה הזו נעשה שימוש בתג היעד load-balanced-backend כדי לזהות את המופעים שאליהם הכלל צריך לחול. Google Cloud
‫fw-allow-proxies: כלל תעבורת נתונים נכנסת (ingress) שחל על המופעים שעוברים איזון עומסים, שמאפשר תעבורת TCP ביציאה 9376 משרתי ה-proxy המנוהלים של מאזן העומסים הפנימי מסוג HTTP(S). בדוגמה הזו נעשה שימוש בתג היעד load-balanced-backend כדי לזהות את המופעים שבהם צריך להחיל את התג.

בלי כללי חומת האש האלה, הכלל default deny ingress חוסם תנועה נכנסת למופעי ה-backend.

המסוף

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

עוברים אל Firewall policies (מדיניות חומת האש).
לוחצים על יצירת כלל לחומת האש כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים:
- Name (שם): fw-allow-ssh
- רשת: lb-network
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: תגי יעד שצוינו
- תגי טירגוט: allow-ssh
- מסנן מקור: IPv4 ranges
- טווחי IPv4 של המקור: 0.0.0.0/0
- פרוטוקולים ויציאות:
  - בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
  - מסמנים את תיבת הסימון tcp ומציינים את היציאה 22.
לוחצים על יצירה.
לוחצים שוב על יצירת כלל לחומת האש כדי ליצור את הכלל שיאפשר Google Cloud בדיקות תקינות:
- Name (שם): fw-allow-health-check
- רשת: lb-network
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: תגי יעד שצוינו
- תגי טירגוט: load-balanced-backend
- מסנן מקור: IPv4 ranges
- טווחי IPv4 של המקור: 130.211.0.0/22 ו-35.191.0.0/16
- פרוטוקולים ויציאות:
  - בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
  - מסמנים את תיבת הסימון tcp ומציינים את היציאה 80. מומלץ להגביל את הכלל הזה רק לפרוטוקולים ולפורטים שתואמים לאלה שמשמשים את בדיקת התקינות. אם משתמשים ב-tcp:80 עבור הפרוטוקול והיציאה, Google Cloud יכול ליצור קשר עם המכונות הווירטואליות באמצעות HTTP ביציאה 80, אבל לא יכול ליצור איתן קשר באמצעות HTTPS ביציאה 443.
לוחצים על יצירה.
לוחצים שוב על Create firewall rule (יצירת כלל של חומת האש) כדי ליצור את הכלל שיאפשר לשרתי ה-Proxy של מאזן העומסים להתחבר לשרתים העורפיים:
- Name (שם): fw-allow-proxies
- רשת: lb-network
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: תגי יעד שצוינו
- תגי טירגוט: load-balanced-backend
- מסנן מקור: IPv4 ranges
- טווחי IPv4 של המקור: 10.129.0.0/23
- פרוטוקולים ויציאות:
  - בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
  - מסמנים את תיבת הסימון tcp ומציינים את היציאה 9376.
לוחצים על יצירה.

gcloud

יוצרים את כלל חומת האש fw-allow-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את source-ranges, Google Cloud מפרש את הכלל כאילו הוא מתייחס לכל מקור.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
יוצרים את הכלל fw-allow-health-check כדי לאפשר Google Cloudבדיקות תקינות. בדוגמה הזו, כל תנועת ה-TCP מבודקי בדיקת תקינות מותרת, אבל אתם יכולים להגדיר קבוצה מצומצמת יותר של יציאות בהתאם לצרכים שלכם.
```
gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```

יוצרים את כלל fw-allow-proxies כדי לאפשר לשרתי ה-proxy של מאזן העומסים הפנימי מסוג HTTP(S) להתחבר לקצה העורפי.

gcloud compute firewall-rules create fw-allow-proxies \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.129.0.0/23 \
    --target-tags=load-balanced-backend \
    --rules=tcp:9376

API

כדי ליצור את הכלל לחומת האש fw-allow-ssh, שולחים בקשת POST אל ה-method‏ firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

מחליפים את PROJECT_ID במזהה הפרויקט.

כדי ליצור את הכלל לחומת האש fw-allow-health-check, שולחים בקשת POST אל ה-method‏ firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

יוצרים את כלל חומת האש fw-allow-proxies כדי לאפשר תעבורת TCP בתת-רשת של ה-proxy בשיטה firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

מחליפים את PROJECT_ID במזהה הפרויקט.

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

לכתובת ה-IP של כלל ההעברה, משתמשים ברשת משנה של בק-אנד. אם מנסים להשתמש ברשת משנה של פרוקסי בלבד, יצירת כלל ההעברה נכשלת.

המסוף

בחירת סוג איזון העומסים

נכנסים לדף Create a load balancer במסוף Google Cloud . כניסה אל יצירת מאזן עומסים
בקטע HTTP(S) Load Balancing, לוחצים על Start configuration.
בוחרים באפשרות Only between my VMs. ההגדרה הזו מציינת שמאזן העומסים הוא פנימי.
לוחצים על Continue.

הכנת מאזן העומסים

בשדה Name של מאזן העומסים, מזינים l7-ilb-gke-map.
בשדה Region, בוחרים את האזור שבו יצרתם את רשת המשנה.
בקטע רשת, בוחרים באפשרות lb-network.

הזמנת רשת משנה לשרת proxy בלבד

שמירת תת-רשת של שרת proxy בלבד:

לוחצים על Reserve a Subnet (הזמנת רשת משנה).
בשדה Name (שם), מזינים proxy-only-subnet.
בשדה IP address range (טווח כתובות IP), מזינים 10.129.0.0/23.
לוחצים על הוספה.

הגדרת שירות הקצה העורפי

לוחצים על Backend configuration.
בתפריט Create or select backend services (יצירה או בחירה של שירותי קצה עורפי), בוחרים באפשרות Create a backend service (יצירת שירות קצה עורפי).
מגדירים את Name של שירות הקצה העורפי לערך l7-ilb-gke-backend-service.
בקטע Backend type (סוג קצה עורפי), בוחרים באפשרות Network endpoint groups (קבוצות של נקודות קצה ברשת).
בכרטיס New backend (בק אנד חדש) בקטע Backends (בק אנד):
1. מגדירים את קבוצת נקודות הקצה ברשת ל-NEG שנוצרה על ידי GKE. כדי לקבל את שם ה-NEG, אפשר לעיין במאמר בנושא אימות של יצירת NEG.
2. בקטע Maximum RPS, מציינים קצב מקסימלי של 5 בקשות לשנייה לכל נקודת קצה. Google Cloud יחרוג מהמקסימום הזה אם יהיה צורך בכך.
3. לוחצים על סיום.
בתפריט הנפתח בדיקת תקינות, בוחרים באפשרות יצירת בדיקת תקינות ומציינים את הפרמטרים הבאים:
1. Name (שם): l7-ilb-gke-basic-check
2. Protocol:‏ HTTP
3. מפרט היציאה: יציאת שרת
4. לוחצים על שמירה והמשך.
לוחצים על יצירה.

הגדרת מיפוי כתובות URL

לוחצים על כללי ניתוב. מוודאים ש-l7-ilb-gke-backend-service הוא שירות הקצה העורפי היחיד לכל מארח שלא תואם ולכל נתיב שלא תואם.

הגדרת הקצה הקדמי

לוחצים על Frontend configuration ומבצעים את השלבים הבאים:

ל-HTTP:

לוחצים על Frontend configuration.
לוחצים על Add frontend IP and port.
מגדירים את Name (שם) לערך l7-ilb-gke-forwarding-rule.
מגדירים את Protocol ל-HTTP.
מגדירים את Subnetwork (רשת משנה) לשם של רשת המשנה של האשכול.
בקטע Internal IP, בוחרים באפשרות Reserve a static internal IP address.
בחלונית שמופיעה, מציינים את הפרטים הבאים:
1. Name (שם): l7-ilb-gke-ip
2. בקטע Static IP address, בוחרים באפשרות Let me choose.
3. בקטע כתובת IP מותאמת אישית, מזינים 10.1.2.199.
4. לוחצים על Reserve.
מגדירים את Port ל-80.
לוחצים על סיום.

ל-HTTPS:

אם אתם משתמשים ב-HTTPS בין הלקוח לבין מאזן העומסים, אתם צריכים משאב אחד או יותר של אישור SSL כדי להגדיר את ה-proxy. מידע על יצירת משאבי אישורי SSL זמין במאמר בנושא אישורי SSL. מאזני עומסים פנימיים מסוג HTTP(S) לא תומכים באישורים שמנוהלים על ידי Google.

לוחצים על Frontend configuration.
לוחצים על Add frontend IP and port.
בשדה שם מזינים l7-ilb-gke-forwarding-rule.
בשדה Protocol, בוחרים באפשרות HTTPS (includes HTTP/2).
מגדירים את Subnet (רשת משנה) – השם של רשת המשנה של האשכול.
בקטע Internal IP, בוחרים באפשרות Reserve a static internal IP address.
בחלונית שמופיעה, מציינים את הפרטים הבאים:
1. Name (שם): l7-ilb-gke-ip
2. בקטע Static IP address, בוחרים באפשרות Let me choose.
3. בקטע כתובת IP מותאמת אישית, מזינים 10.1.2.199.
4. לוחצים על Reserve.
מוודאים שהיציאה מוגדרת ל-443 כדי לאפשר תנועה ב-HTTPS.
לוחצים על התפריט הנפתח אישור.
1. אם כבר יש לכם משאב של אישור SSL בניהול עצמי שאתם רוצים להשתמש בו כאישור ה-SSL הראשי, בוחרים אותו מהתפריט הנפתח.
2. אחרת, בוחרים באפשרות Create a new certificate (יצירת אישור חדש).
  1. מזינים שם של l7-ilb-cert.
  2. בשדות המתאימים, מעלים את הקבצים בפורמט PEM:
    - אישור של מפתח ציבורי
    - שרשרת אישורים
    - מפתח פרטי
  3. לוחצים על יצירה.
כדי להוסיף משאבי אישורים בנוסף למשאב אישור ה-SSL הראשי:
1. לוחצים על הוספת אישור.
2. בוחרים אישור מהרשימה Certificates (אישורים) או לוחצים על Create a new certificate (יצירת אישור חדש) ופועלים לפי ההוראות.
לוחצים על סיום.

השלמת ההגדרה

לוחצים על יצירה.

gcloud

מגדירים את בדיקת תקינות ה-HTTP באמצעות הפקודה gcloud compute health-checks create http.

gcloud compute health-checks create http l7-ilb-gke-basic-check \
    --region=COMPUTE_REGION \
    --use-serving-port

מגדירים את שירות הקצה העורפי באמצעות הפקודה gcloud compute backend-services create.

gcloud compute backend-services create l7-ilb-gke-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-gke-basic-check \
    --health-checks-region=COMPUTE_REGION \
    --region=COMPUTE_REGION

מגדירים את המשתנה DEPLOYMENT_NAME:
```
export DEPLOYMENT_NAME=NEG_NAME
```
מחליפים את NEG_NAME בשם של קבוצת ה-NEG.

מוסיפים קצוות עורפיים של NEG לשירות הקצה העורפי באמצעות הפקודה gcloud compute backend-services add-backend.

gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
    --network-endpoint-group=$DEPLOYMENT_NAME \
    --network-endpoint-group-zone=COMPUTE_ZONE-b \
    --region=COMPUTE_REGION \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=5

יוצרים את מיפוי כתובות ה-URL באמצעות הפקודה gcloud compute url-maps create.

gcloud compute url-maps create l7-ilb-gke-map \
    --default-service=l7-ilb-gke-backend-service \
    --region=COMPUTE_REGION

יוצרים את שרת ה-proxy של היעד.

ל-HTTP:

משתמשים בפקודה gcloud compute target-http-proxies create.
```
gcloud compute target-http-proxies create l7-ilb-gke-proxy \
    --url-map=l7-ilb-gke-map \
    --url-map-region=COMPUTE_REGION \
    --region=COMPUTE_REGION
```
ל-HTTPS:

מידע על יצירת משאבי אישורי SSL זמין במאמר בנושא אישורי SSL. אי אפשר להשתמש באישורים שמנוהלים על ידי Google עם מאזני עומסים פנימיים מסוג HTTP(S).

מקצים את נתיבי הקבצים לשמות של משתנים.
```
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
```
```
export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
```
יוצרים אישור SSL אזורי באמצעות הפקודה gcloud compute ssl-certificates create.

gcloud compute ssl-certificates create
```
gcloud compute ssl-certificates create l7-ilb-cert \
    --certificate=$LB_CERT \
    --private-key=$LB_PRIVATE_KEY \
    --region=COMPUTE_REGION
```
משתמשים באישור SSL אזורי כדי ליצור שרת proxy ליעד באמצעות הפקודה gcloud compute target-https-proxies create.
```
gcloud compute target-https-proxies create l7-ilb-gke-proxy \
    --url-map=l7-ilb-gke-map \
    --region=COMPUTE_REGION \
    --ssl-certificates=l7-ilb-cert
```

יוצרים את כלל ההעברה.

ברשתות מותאמות אישית, צריך להפנות לרשת המשנה בכלל ההעברה. חשוב לדעת: מדובר ברשת המשנה של המכונה הווירטואלית, ולא ברשת המשנה של ה-proxy.

ל-HTTP:

משתמשים בפקודה gcloud compute forwarding-rules create עם הדגלים המתאימים.

gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=SUBNET_NAME \
    --address=10.1.2.199 \
    --ports=80 \
    --region=COMPUTE_REGION \
    --target-http-proxy=l7-ilb-gke-proxy \
    --target-http-proxy-region=COMPUTE_REGION

ל-HTTPS:

משתמשים בפקודה gcloud compute forwarding-rules create עם הדגלים המתאימים.

gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=SUBNET_NAME  \
    --address=10.1.2.199 \
    --ports=443 \
    --region=COMPUTE_REGION \
    --target-https-proxy=l7-ilb-gke-proxy \
    --target-https-proxy-region=COMPUTE_REGION

מחליפים את SUBNET_NAME בשם של רשת המשנה של האשכול.

API

כדי ליצור בדיקת תקינות, שולחים בקשת POST אל ה-method‏ regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

מחליפים את PROJECT_ID במזהה הפרויקט.

כדי ליצור את השירות לקצה עורפי אזורי, שולחים בקשת POST אל ה-method‏ regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

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

‫PROJECT_ID: מזהה הפרויקט.
‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת (NEG).

כדי ליצור את מיפוי כתובות ה-URL, שולחים בקשת POST אל ה-method‏ regionUrlMaps.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

מחליפים את PROJECT_ID במזהה הפרויקט.

יוצרים את ה-HTTP proxy היעד על ידי שליחת בקשת POST ל-method‏ regionTargetHttpProxies.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

מחליפים את PROJECT_ID במזהה הפרויקט.

כדי ליצור את כלל ההעברה, שולחים בקשת POST אל ה-method‏ forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

מחליפים את PROJECT_ID במזהה הפרויקט.

בדיקה

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

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=SUBNET_NAME \
    --tags=l7-ilb-client,allow-ssh

מתחברים למופע הלקוח כדי לוודא שאפשר להגיע לשירותי HTTP(S) בבק-אנד באמצעות כתובת ה-IP של כלל ההעברה של מאזן העומסים הפנימי של האפליקציות, ושהתנועה מאוזנת בין נקודות הקצה ב-NEG.

מתחברים לכל מופע של לקוח באמצעות SSH:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

מוודאים שכתובת ה-IP משרתת את שם המארח שלה:

curl 10.1.2.199

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

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

הדגל -k גורם ל-curl לדלג על אימות האישור.

מריצים 100 בקשות ומוודאים שהן מאוזנות עומסים.

ל-HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

ל-HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

צירוף מאזן עומסי רשת חיצוני לשרת proxy ל-NEGs עצמאיים

אתם יכולים להשתמש ב-NEGs עצמאיים כדי לבצע איזון עומסים ישירות לקונטיינרים באמצעות מאזן עומסי רשת חיצוני לשרת proxy, שלא נתמך באופן מובנה על ידי Kubernetes או GKE. מאזני עומסים של שרת proxy מיועדים לתנועת TCP בלבד, עם או בלי SSL. לתנועה מסוג HTTP(S), מומלץ להשתמש במאזן עומסים של אפליקציות במקום זאת.

יוצרים כלל של חומת אש שמאפשר בדיקות תקינות.

מאזני עומסים צריכים לגשת לנקודות קצה של אשכולות כדי לבצע בדיקות תקינות. הפקודה הבאה יוצרת כלל בחומת האש שמאפשר גישה:
```
gcloud compute firewall-rules create allow-tcp-lb-and-health \
   --network=NETWORK_NAME \
   --target-tags=GKE_NODE_NETWORK_TAGS \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 \
   --allow tcp:9376
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NETWORK_NAME: הרשת שבה האשכול פועל.
- ‫GKE_NODE_NETWORK_TAGS: תגי הרישות בצומתי GKE.
אם לא יצרתם תגי רשת בהתאמה אישית לצמתים, GKE יוצר עבורכם תגים באופן אוטומטי. כדי לחפש את התגים שנוצרו, מריצים את הפקודה הבאה:
```
gcloud compute instances describe INSTANCE_NAME
```
מחליפים את INSTANCE_NAME בשם של המכונה הווירטואלית המארחת של Compute Engine שבה פועל צומת GKE. לדוגמה, הפלט בקטע Inspect NEGs directly מציג את שמות המכונות בעמודה INSTANCE עבור צמתי GKE.

במקרים של אשכולות רגילים, אפשר גם להריץ את הפקודה gcloud compute instances list כדי להציג רשימה של כל המופעים בפרויקט.

במקום תגי רשת, ב-clusters של Autopilot צריך לטרגט את חשבון השירות של האשכול.

מחליפים את הדגל --target-tags=GKE_NODE_NETWORK_TAGS בדגל --target-service-accounts=SERVICE_ACCOUNT_EMAIL. מומלץ להשתמש בחשבון שירות מותאם אישית עם הרשאות מינימליות עבור האשכול.

יוצרים כתובת IP וירטואלית גלובלית למאזן העומסים:

gcloud compute addresses create tcp-lb-static-ipv4 \
   --ip-version=IPV4 \
   --global

הגדרת בדיקת תקינות לנקודות קצה של ה-Backend.

מאזן העומסים משתמש בבדיקות תקינות כדי לזהות את מצב הפעילות של נקודות קצה ספציפיות ב-NEG.
```
gcloud compute health-checks create tcp my-tcp-health-check \
   --use-serving-port
```

יצירת שירות לקצה העורפי עם שיוך סשנים.

שירות הקצה העורפי הזה מציין שמדובר במאזן עומסי רשת חיצוני בשרת proxy עם CLIENT_IP שיוך סשנים:

gcloud compute backend-services create my-tcp-lb \
   --load-balancing-scheme EXTERNAL_MANAGED \
   --global-health-checks \
   --global \
   --protocol TCP \
   --health-checks my-tcp-health-check \
   --timeout 5m \
   --session-affinity=CLIENT_IP

יוצרים שרת TCP Proxy ליעד עבור מאזן העומסים.

אם רוצים להפעיל את כותרת ה-proxy, צריך להגדיר אותה ל-PROXY_V1 במקום ל-NONE.
```
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy \
    --backend-service my-tcp-lb \
    --proxy-header NONE
```

יוצרים כלל העברה לניתוב התנועה.

כלל ההעברה הזה יוצר את מאזן העומסים.

 gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
    --load-balancing-scheme EXTERNAL_MANAGED \
    --global \
    --target-tcp-proxy my-tcp-lb-target-proxy \
    --address tcp-lb-static-ipv4 \
    --ports 80

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

יצרת את המשאבים הבאים:

כתובת IP וירטואלית חיצונית
כלל ההעברה
כלל חומת האש
שרת ה-proxy של היעד
השירות לקצה העורפי
בדיקת התקינות של Compute Engine

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

הקשר בין המשאבים שיצרתם.

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

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

הוספת קבוצות עצמאיות של נקודות קצה ברשת (NEGs) כקצה עורפי למאזן העומסים

משתמשים בפקודה gcloud compute backend-services add-backend כדי לחבר את ה-NEG למאזן העומסים על ידי הוספה שלו כקצה עורפי של שירות הקצה העורפי my-tcp-lb:

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode CONNECTION \
    --max-connections 100

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

‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת. השם הוא השם שציינתם כשיוצרים את ה-NEG או שם שנוצר אוטומטית. אם לא ציינתם שם ל-NEG, בהמשך מוסבר איך למצוא את השם שנוצר אוטומטית.
‫NEG_ZONE: האזור שבו נמצאת קבוצת נקודות הקצה ברשת. בהמשך מפורטות הוראות למציאת הערך הזה.

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

gcloud compute network-endpoint-groups list

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

NAME: k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
LOCATION: us-central1-a
ENDPOINT_TYPE: GCE_VM_IP_PORT
SIZE: 3

בדוגמה הזו, השם של קבוצת ה-NEG הוא kk8s1-65a95e90-default-neg-demo-svc-80-663a85e4 והאזור הוא us-central1-a.

אפשר להוסיף כמה קבוצות NEG לאותו שירות קצה עורפי. בשירותים גלובליים לקצה העורפי, כמו my-tcp-lb, יכולים להיות שרתי בק-אנד של NEG באזורים שונים, בעוד שבשירותים אזוריים לקצה העורפי חייבים להיות שרתי בק-אנד באזור אחד.

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

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

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

אימות של בדיקות תקינות

בודקים ששירות הקצה העורפי משויך לבדיקת תקינות ולקבוצות של נקודות קצה ברשת, ושהנקודות האישיות תקינות.

כדי לוודא ששירות ה-Backend משויך לבדיקת תקינות ולנקודת הקצה של קבוצת הרשת, משתמשים בפקודה הבאה:

gcloud compute backend-services describe my-tcp-lb --global

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

backends:
- balancingMode: CONNECTION
  group: ... /networkEndpointGroups/k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
  maxConnections: 100
...
healthChecks:
- ... /healthChecks/my-tcp-health-check
...
name: my-tcp-lb
...

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

gcloud compute backend-services get-health my-tcp-lb --global

הפלט של הקטע status: אמור להיראות כך:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

אימות הקישוריות של האפליקציה

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

קבלת כתובת ה-IP החיצונית של מאזן העומסים:

כדי לאחזר את כתובת ה-IP החיצונית ששמרתם למאזן העומסים, משתמשים בפקודה הבאה:
```
gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
```
הפקודה הזו מחזירה את כתובת ה-IP.
שליחת בקשה לכתובת ה-IP:

משתמשים בפקודה curl כדי לשלוח בקשה לכתובת ה-IP החיצונית.
```
curl EXTERNAL_IP_ADDRESS
```
מחליפים את EXTERNAL_IP_ADDRESS בכתובת ה-IP שקיבלתם בשלב הקודם:

התגובה מהאפליקציה serve_hostname צריכה להתחיל ב-neg-demo-app.

הטמעה של שירותים הטרוגניים (מכונות וירטואליות וקונטיינרים)

מאזני עומסים יכולים להיות חזיתות לעומסי עבודה (workload) מעורבים של Kubernetes ושל מערכות שאינן Kubernetes. זה יכול להיות חלק ממעבר ממכונות וירטואליות (VM) לקונטיינרים, או ארכיטקטורה קבועה שמרוויחה מאיזון עומסים משותף. אפשר לעשות זאת על ידי יצירת מאזני עומסים שמטרגטים סוגים שונים של שרתים עורפיים, כולל קבוצות NEGs עצמאיות.

מכונות וירטואליות וקונטיינרים באותו שירות בק-אנד

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

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

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

הארכיטקטורה המתוארת. מאזן העומסים שנוצר קודם מצביע על שתי קבוצות NEGs: קבוצת ה-NEG של הקונטיינרים שנוצרו קודם וקבוצת NEG חדשה שמכילה את כתובת ה-IP של מכונה וירטואלית.

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

פורסים מכונה וירטואלית ב-Compute Engine באמצעות הפקודה הבאה:
```
gcloud compute instances create vm1 \
    --zone=COMPUTE_ZONE \
    --network=NETWORK \
    --subnet=SUBNET \
    --image-project=cos-cloud \
    --image-family=cos-stable --tags=vm-neg-tag
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫COMPUTE_ZONE: שם האזור.
- ‫NETWORK: שם הרשת.
- ‫SUBNET: השם של רשת המשנה שמשויכת לרשת.
פריסת אפליקציה במכונה הווירטואלית:
```
gcloud compute ssh vm1 \
    --zone=COMPUTE_ZONE \
    --command="docker run -d --rm --network=host registry.k8s.io/e2e-test-images/agnhost:2.40 serve-hostname --port=9376 && sudo iptables -P INPUT ACCEPT"
```
הפקודה הזו פורסת במכונה הוירטואלית את אותה אפליקציה לדוגמה שבה נעשה שימוש בדוגמה הקודמת. כדי לפשט את התהליך, האפליקציה מורצת כקונטיינר ב-Docker, אבל זה לא חובה. הפקודה iptables נדרשת כדי לאפשר גישה לחומת האש של הקונטיינר הפועל.
מוודאים שהאפליקציה פועלת ביציאה 9376 ומדווחת שהיא פועלת ב-vm1:
```
gcloud compute ssh vm1 \
    --zone=COMPUTE_ZONE \
    --command="curl -s localhost:9376"
```
השרת אמור להגיב עם vm1.
יוצרים קבוצת נקודות קצה ברשת (NEG) לשימוש עם נקודת הקצה של המכונה הווירטואלית. גם קונטיינרים וגם מכונות וירטואליות יכולים להיות נקודות קצה של NEG, אבל ל-NEG יחיד לא יכולות להיות נקודות קצה של מכונות וירטואליות וגם של קונטיינרים.
```
gcloud compute network-endpoint-groups create vm-neg \
    --subnet=SUBNET \
    --zone=COMPUTE_ZONE
```
מצרפים את נקודת הקצה של ה-VM ל-NEG:
```
gcloud compute network-endpoint-groups update vm-neg \
    --zone=COMPUTE_ZONE \
    --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
```
מחליפים את VM_PRIMARY_IP בכתובת ה-IP הראשית של המכונה הווירטואלית.
מוודאים שלקבוצת נקודות הקצה של הרשת יש את נקודת הקצה של המכונה הווירטואלית:
```
gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
    --zone COMPUTE_ZONE
```

מצרפים את ה-NEG לשירות הבק-אנד באמצעות אותה פקודה שבה השתמשתם כדי להוסיף בק-אנד של קונטיינר:

gcloud compute backend-services add-backend my-bes
    --global \
    --network-endpoint-group vm-neg \
    --network-endpoint-group-zone COMPUTE_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 10

פתיחת חומת האש כדי לאפשר את בדיקת תקינות ה-VM:

gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=vm-neg-tag \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:9376

כדי לוודא שמאזן העומסים מעביר תנועה גם אל קצה העורף החדש vm1 וגם אל קצה העורף הקיים של הקונטיינר, שולחים תנועת נתונים לבדיקה:
```
for i in `seq 1 100`; do curl ${VIP};echo; done
```
אמורות להופיע תשובות מנקודות הקצה של מאגר התגים (neg-demo-app) ושל המכונה הווירטואלית (vm1).

מכונות וירטואליות וקונטיינרים לשירותים שונים של קצה עורפי

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

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

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

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

מיפוי של כתובת IP וירטואלית אחת לשני שמות מארחים, שם מארח אחד לעורף שמבוסס על קונטיינרים ושם מארח אחד לעורף שמבוסס על מכונות וירטואליות.

התרשים הבא מציג את הארכיטקטורה שמתוארת בקטע הקודם:

בארכיטקטורה יש שתי קבוצות של נקודות קצה ברשת (NEG): אחת לשירות שהוטמע באמצעות קונטיינרים ואחת לשירות שהוטמע באמצעות מכונות וירטואליות. יש אובייקט של שירות קצה עורפי לכל NEG. אובייקט מיפוי כתובות ה-URL מפנה את התנועה לשירות הקצה העורפי הנכון על סמך כתובת ה-URL המבוקשת.

יוצרים שירות קצה עורפי חדש למכונה הווירטואלית:

gcloud compute backend-services create my-vm-bes \
   --protocol HTTP \
   --health-checks http-basic-check \
   --global

מצרפים את ה-NEG של המכונה הווירטואלית, vm-neg, לשירות הקצה העורפי:

gcloud compute backend-services add-backend my-vm-bes \
    --global \
    --network-endpoint-group vm-neg \
    --network-endpoint-group-zone COMPUTE_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 10

מוסיפים כלל מארח למיפוי כתובות ה-URL כדי להפנות בקשות למארח container.example.com לשירות העורפי של מאגר התגים:

gcloud compute url-maps add-path-matcher web-map \
    --path-matcher-name=container-path --default-service=my-bes \
    --new-hosts=container.example.com --global

מוסיפים עוד כלל מארח למיפוי כתובות ה-URL כדי להפנות בקשות למארח vm.example.comלשירות הקצה העורפי של המכונה הווירטואלית:
```
gcloud compute url-maps add-path-matcher web-map \
    --path-matcher-name=vm-path --default-service=my-vm-bes \
    --new-hosts=vm.example.com --global
```
הערה: לוקח כמה דקות עד שמאזן העומסים מתוכנת באופן מלא.
מוודאים שמאזן העומסים שולח תנועה לקצה העורפי של ה-VM על סמך הנתיב המבוקש:
```
curl -H "HOST:vm.example.com" VIRTUAL_IP
```
מחליפים את VIRTUAL_IP בכתובת ה-IP הווירטואלית.

המגבלות של קבוצות עצמאיות של נקודות קצה ברשת (NEGs)

שגיאות באימות ההערות מוצגות למשתמשים באמצעות אירועים של Kubernetes.
המגבלות של NEGs חלות גם על NEGs עצמאיים.
‫NEGs עצמאיים לא פועלים עם רשתות מדור קודם.
אפשר להשתמש ב-NEGs עצמאיים רק עם שירותי רשת תואמים, כולל Cloud Service Mesh וסוגים תואמים של מאזני עומסים.

תמחור

בקטע בנושא איזון עומסים בדף התמחור אפשר לקרוא פרטים על התמחור של מאזן העומסים. אין חיוב נוסף על קבוצות NEG.

פתרון בעיות

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

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

תיאור הבעיה: לא נוצר NEG.

פתרון אפשרי:

בודקים את האירועים שמשויכים לשירות ומחפשים הודעות שגיאה.
מוודאים שההערה של ה-NEG העצמאי היא JSON תקין, ושהיציאות שנחשפות תואמות ליציאות קיימות במפרט השירות.
בודקים את הערת הסטטוס של ה-NEG כדי לראות אם ליציאות השירות הצפויות יש קבוצות NEG תואמות.
מוודאים שקבוצות ה-NEG נוצרו באזורים הצפויים באמצעות הפקודה gcloud compute network-endpoint-groups list.
אם משתמשים בגרסה 1.18 של GKE ואילך, בודקים אם משאב svcneg של השירות קיים. אם כן, בודקים את התנאי Initialized כדי לראות אם יש מידע על שגיאות.
אם אתם משתמשים בשמות NEG בהתאמה אישית, ודאו שכל שם NEG ייחודי באזור שלו.

התנועה לא מגיעה לנקודות הקצה

תיאור הבעיה: שגיאות 502 או חיבורים שנדחו.

פתרון אפשרי:

אחרי שמגדירים את השירות, בדרך כלל אפשר להגיע לנקודות קצה חדשות אחרי שמצרפים אותן ל-NEG, בתנאי שהן מגיבות לבדיקות תקינות.
אם אחרי פרק הזמן הזה התנועה עדיין לא מגיעה לנקודות הקצה ומופיע קוד השגיאה 502 עבור HTTP(S) או שהחיבורים נדחים עבור מאזני עומסים של TCP/SSL, צריך לבדוק את הדברים הבאים:
- מוודאים שכללי חומת האש מאפשרים תעבורת TCP נכנסת לנקודות הקצה מהטווחים הבאים: 130.211.0.0/22 ו-35.191.0.0/16.
- מוודאים שנקודות הקצה תקינות באמצעות Google Cloud CLI או על ידי קריאה ל-getHealth API ב-backendService או ל-listEndpoints API ב-NEG עם הפרמטר showHealth שהערך שלו הוא SHOW.

ההשקה הושהתה

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

פתרון אפשרי:

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

אם אתם משתמשים ב-kubectl בגרסה 1.13 ומעלה, אתם יכולים לבדוק את הסטטוס של שערים לבדיקת מוכנות של Pod באמצעות הפקודה הבאה:
```
kubectl get my-Pod -o wide
```
בודקים את העמודה READINESS GATES (נקודות מוכנות).

העמודה הזו לא קיימת ב-kubectl 1.12 ובגרסאות קודמות. יכול להיות ששער המוכנות של Pod שמסומן כמצב READY נכשל. כדי לוודא זאת, משתמשים בפקודה הבאה:
```
kubectl get my-pod -o yaml
```
שערי המוכנות והסטטוס שלהם מפורטים בפלט.
מוודאים שקובץ האימג' בקונטיינר במפרט ה-Pod של הפריסה פועל בצורה תקינה ויכול להגיב לבדיקות תקינות.
מוודאים שהגדרת בדיקות התקינות נכונה.

NEG אינו נאסף אשפה

הסימפטום: קבוצת NEG שאמורה להימחק עדיין קיימת.

פתרון אפשרי:

אם יש הפניה ל-NEG משירות backend, לא מתבצע איסוף אשפה של ה-NEG. פרטים נוספים זמינים במאמר בנושא מניעת דליפות של קבוצות NEG.
אם משתמשים בגרסה 1.18 ואילך, אפשר לבדוק אם יש אירועים במשאב ServiceNetworkEndpointGroup באמצעות התהליך של משא ומתן על שירות.
בודקים אם השירות עדיין צריך את ה-NEG. בודקים את המשאב svcneg של השירות שתואם ל-NEG, ומחפשים הערה של Service.

ה-NEG לא מסונכרן עם השירות

תסמין: נקודות הקצה הצפויות (כתובת ה-IP של ה-Pod) לא קיימות ב-NEG, ה-NEG לא מסונכרן או שמופיעה השגיאה Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

פתרון אפשרי:

אם אתם משתמשים ב-GKE 1.18 ואילך, כדאי לעיין במשאב svcneg כדי לקבל מידע:

בודקים את הערך של status.lastSyncTime כדי לוודא שה-NEG סונכרן לאחרונה.
בודקים את התנאי Synced כדי לראות אם היו שגיאות בסנכרון האחרון.

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

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

סקירה כללית

תעבורת נתונים נכנסת (ingress) עם קבוצות של נקודות קצה לרשת (NEGs)

קבוצות עצמאיות של נקודות קצה ברשת (NEGs)

מניעת הדלפות של קבוצות NEG

תרחישים לדוגמה לשימוש ב-NEGs עצמאיים

שירותים הטרוגניים של קונטיינרים ומכונות וירטואליות

בקרי Ingress בהתאמה אישית

שימוש ב-Cloud Service Mesh עם GKE

שימוש במאזני עומסים חיצוניים של רשת בשרת proxy עם GKE

מוכנות של Pod

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

שימוש בקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

יצירת פריסה

שימוש במשוב על מוכנות ה-Pod

שימוש בעיכוב שמוגדר בקוד

יצירת שירות

סוגי השירותים

מתן שמות ל-NEGs

ציון שם

שימוש בשם שנוצר באופן אוטומטי

מיפוי יציאות לכמה קבוצות של נקודות קצה ברשת (NEGs)

אחזור סטטוסים של קבוצות של נקודות קצה (NEG)

אימות יצירת ה-NEG

המשאב ServiceNetworkEndpointGroup

בדיקה ישירה של NEGs

צירוף מאזן עומסים חיצוני של אפליקציות (ALB) לקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

נקודת ביקורת

הוספת קצה עורפי למאזן העומסים

בדיקה שהמאזן עומסים פועל

אימות של בדיקות תקינות

גישה לאפליקציה

צירוף מאזן עומסים פנימי של אפליקציות (ALB) לקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

הגדרת רשת המשנה ל-Proxy בלבד

המסוף

gcloud

API

הגדרת כללים לחומת אש

המסוף

gcloud

API

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

המסוף

בחירת סוג איזון העומסים

הכנת מאזן העומסים

הזמנת רשת משנה לשרת proxy בלבד

הגדרת שירות הקצה העורפי

הגדרת מיפוי כתובות URL

הגדרת הקצה הקדמי

השלמת ההגדרה

gcloud

API

בדיקה

צירוף מאזן עומסי רשת חיצוני לשרת proxy ל-NEGs עצמאיים

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

הוספת קבוצות עצמאיות של נקודות קצה ברשת (NEGs) כקצה עורפי למאזן העומסים

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

אימות של בדיקות תקינות

אימות הקישוריות של האפליקציה

הטמעה של שירותים הטרוגניים (מכונות וירטואליות וקונטיינרים)

מכונות וירטואליות וקונטיינרים באותו שירות בק-אנד

מכונות וירטואליות וקונטיינרים לשירותים שונים של קצה עורפי

המגבלות של קבוצות עצמאיות של נקודות קצה ברשת (NEGs)

תמחור

פתרון בעיות

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

התנועה לא מגיעה לנקודות הקצה

ההשקה הושהתה

NEG אינו נאסף אשפה

ה-NEG לא מסונכרן עם השירות

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

איזון עומסים שמקורם בקונטיינר באמצעות קבוצות עצמאיות של נקודות קצה ברשת (NEGs) אזוריות

המשאב `ServiceNetworkEndpointGroup`