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

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

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

סקירה כללית

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

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

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

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

תעבורת נתונים נכנסת (ingress) עם קבוצות NEG

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

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

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

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

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

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

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

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

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

• כשמ删除ים אשכול, לא יימחקו קבוצות עצמאיות של נקודות קצה ברשת (NEGs) בתרחישים הבאים:

  • ה-NEG עדיין מפנה לשירות קצה עורפי.
  • תהליך המחיקה של האשכול משבית את בקר ה-NEG לפני שהבקר יכול למחוק את ה-NEG.

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

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

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

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

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

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

קבוצות NEG יכולות להכיל כתובות IP של מכונות וירטואליות ושל קונטיינרים. המשמעות היא שכתובת IP וירטואלית אחת יכולה להפנות לשרת בק-אנד שמורכב מעומסי עבודה של Kubernetes וגם מעומסי עבודה שלא שייכים ל-Kubernetes. אפשר להשתמש בו גם כדי להעביר עומסי עבודה (workloads) קיימים לאשכול 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 נפרסות ומנוהלות בשם מאזן העומסים. עם זאת, קבוצות NEG עצמאיות לא מניחות הנחות לגבי בדיקות התקינות של Compute Engine, כי הן אמורות להיות פרוסות ומנוהלות בנפרד. תמיד צריך להגדיר בדיקות תקינות ב-Compute Engine יחד עם איזון העומסים, כדי למנוע שליחת תעבורה לקצוות עורפיים שלא מוכנים לקבל אותה. אם אין סטטוס של בדיקת תקינות שמשויך ל-NEG (בדרך כלל כי לא מוגדרת בדיקת תקינות), אז בקר ה-NEG יסמן את ערך שער המוכנות של ה-Pod כ-True כשהנקודה המתאימה שלו מתוכנתת ב-NEG.

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

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

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

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

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

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

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

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

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

יצירת פריסה

בדוגמה הבאה מוצגים קובצי מניפסט של פריסות שמריצות שלוש דוגמאות של שרת HTTP מבוסס-קונטיינר. שרת ה-HTTP מגיב לבקשות עם שם המארח של שרת האפליקציות, השם של ה-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/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

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/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

שומרים את קובץ המניפסט הזה בשם 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) נוצרת תוך כמה דקות אחרי יצירת השירות. אם יש Pods שתואמים לתווית שצוינה במניפסט של השירות, אז לאחר היצירה ה-NEG יכיל את כתובות ה-IP של ה-Pods.

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

משאב ServiceNetworkEndpointGroup

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

kubectl get svcneg

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

kubectl get svcneg NEG_NAME -o yaml

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

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

kubectl describe service SERVICE_NAME

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

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

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

בדיקה ישירה של קבוצות ביטויים רגולריים שליליים

כדי לוודא שקבוצת ה-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 בשם של קבוצת נקודות הקצה שרוצים להציג את נקודות הקצה שלה.

בפלט מוצגות שלוש נקודות קצה, שלכל אחת מהן יש כתובת 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) לקבוצות עצמאיות של נקודות קצה ברשת (NEG)

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

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

   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 כדי להציג רשימה של כל המופעים בפרויקט.

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

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

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

   gcloud compute health-checks create http http-basic-check \
       --use-serving-port
   

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

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

5. יוצרים מפת 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
   

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

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

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

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"
}

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

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

• ‫fw-allow-ssh: כלל תעבורת נתונים נכנסת (ingress) שחל על המכונות שמתבצע עליהן איזון עומסים, שמאפשר קישוריות SSH נכנסת ביציאה 22 ב-TCP מכל כתובת. אפשר לבחור טווח מצומצם יותר של כתובות 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.

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"
}

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"
}

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"
}

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

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

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"
   }
}

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"
}

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"
}

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"
}

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/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

בדיקה

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

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --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), מומלץ להשתמש במאזן עומסים של אפליקציות.

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

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

   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.

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

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

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

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

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

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

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

   gcloud compute health-checks create tcp my-tcp-health-check \
      --use-serving-port
   

4. יצירת שירות לקצה העורפי עם זיקה לסשן.

   שירות לקצה העורפי הזה מציין שמדובר במאזן עומסי רשת חיצוני בשרת proxy עם CLIENT_IP זיקה לסשן (session affinity):

   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
   

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

   אם רוצים להפעיל את כותרת ה-proxy, צריך להגדיר אותה ל-PROXY_V1 במקום ל-NONE.

   gcloud beta compute target-tcp-proxies create my-tcp-lb-target-proxy \
       --backend-service my-tcp-lb \
       --proxy-header NONE
   

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

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

    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 באזורים שונים, בעוד שבשירותים אזוריים לקצה העורפי חייבים להיות שרתי בק-אנד באזור אחד.

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

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

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

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

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

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

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 החיצונית של מאזן העומסים.

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

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

   gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
   

   הפקודה הזו מחזירה את כתובת ה-IP.

2. שליחת בקשה לכתובת ה-IP:

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

   curl EXTERNAL_IP_ADDRESS
   

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

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

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

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

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

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

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

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

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

1. מפעילים את הפקודה הבאה כדי לפרוס מכונה וירטואלית ב-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: השם של רשת המשנה שמשויכת לרשת.

2. פריסת אפליקציה במכונה הווירטואלית:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
   

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

3. מוודאים שהאפליקציה פועלת ביציאה 9376 ומדווחת שהיא פועלת ב-vm1:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="curl -s localhost:9376"
   

   השרת אמור להשיב עם vm1.

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

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. מצרפים את נקודת הקצה של ה-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 הראשית של המכונה הווירטואלית.

6. מוודאים של-NEG יש נקודת קצה של מכונה וירטואלית:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. מצרפים את ה-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
   

8. פתיחת חומת האש כדי לאפשר את בדיקת תקינות ה-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
   

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

   for i in `seq 1 100`; do curl ${VIP};echo; done
   

   אמורות להופיע תשובות מנקודות הקצה של הקונטיינר (neg-demo-app) ושל המכונה הווירטואלית (vm1).

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

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

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

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

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

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

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

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

2. מצרפים את ה-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
   

3. מוסיפים כלל מארח למפת 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
   

4. מוסיפים עוד כלל מארח למפת 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
   

5. מוודאים שמאזן העומסים שולח תנועה לקצה העורפי של ה-VM על סמך הנתיב המבוקש:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   מחליפים את VIRTUAL_IP בכתובת ה-IP הווירטואלית.

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

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

תמחור

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

פתרון בעיות

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

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

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

• אם אתם משתמשים ב-kubectl בגרסה 1.13 ומעלה, אתם יכולים לבדוק את הסטטוס של שערי המוכנות של Pod באמצעות הפקודה הבאה:

  kubectl get my-Pod -o wide
  

  בודקים את העמודה READINESS GATES.

  העמודה הזו לא קיימת ב-kubectl 1.12 ובגרסאות קודמות. יכול להיות ש-Pod שמסומן כמצב READY (מוכן) נכשל בשער המוכנות. כדי לוודא זאת, משתמשים בפקודה הבאה:

  kubectl get my-pod -o yaml
  

  שערי המוכנות והסטטוס שלהם מפורטים בפלט.

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

• מוודאים שבדיקות התקינות מוגדרות בצורה נכונה.

‫NEG לא עובר garbage collection

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

פתרון אפשרי:

• אם יש הפניה ל-NEG משירות קצה עורפי, לא מתבצע איסוף אשפה של ה-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 באמצעות ה-CLI של gcloud או Google Cloud המסוף באזור של האשכול (או באחד מהאזורים של האשכול). במקרה כזה, צריך למחוק את ה-NEG הקיים לפני שבקר ה-NEG יוכל לסנכרן את נקודות הקצה שלו. היצירה של קבוצת נקודות קצה עצמאית והחברות בה מיועדות לניהול על ידי בקר קבוצת נקודות הקצה.

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

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