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

מאזני עומסים חיצוניים (ELB) חושפים שירותים לגישה מחוץ לארגון ממאגר של כתובות IP שהוקצו לארגון ממאגר גדול יותר של כתובות IP חיצוניות של מופעים.

כתובות IP וירטואליות (VIP) של ELB לא מתנגשות בין ארגונים והן ייחודיות בכל הארגונים. לכן, צריך להשתמש בשירותי ELB רק לשירותים שלקוחות מחוץ לארגון צריכים לגשת אליהם.

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

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

יצירת מאזן עומסים חיצוני לאשכולות משותפים

אפשר ליצור מאזני עומסים גלובליים או אזוריים. ההיקף של מאזני עומסים גלובליים (ELB) משתרע על פני יקום GDC. ההיקף של מאזני עומסים אזוריים מוגבל לאזור שצוין בזמן היצירה. מידע נוסף זמין במאמר מאזני עומסים גלובליים ואזוריים.

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

כדי להגדיר שירותי ELB, צריך:

  • הבעלים של הפרויקט שבו מגדירים את מאזן העומסים. מידע נוסף מופיע במאמר יצירת פרויקט.
  • יש לכם מדיניות כניסה מותאמת אישית של ProjectNetworkPolicy (PNP) כדי לאפשר תעבורה לשירות ELB הזה. מידע נוסף זמין במאמר הגדרת PNP כדי לאפשר תנועה ל-ELB.

  • יש לכם את התפקידים הנדרשים לניהול זהויות והרשאות גישה:

    • אדמין NetworkPolicy של פרויקט: יש לו גישה לניהול מדיניות הרשת של הפרויקט במרחב השמות של הפרויקט. צריך לבקש מאדמין IAM של הארגון להקצות לכם את התפקיד 'אדמין NetworkPolicy בפרויקט' (project-networkpolicy-admin).
    • אדמין מאזן עומסים: צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד אדמין מאזן עומסים (load-balancer-admin).
    • אדמין של מאזן עומסים גלובלי: כדי להשתמש במאזני עומסים גלובליים, צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד 'אדמין של מאזן עומסים גלובלי' (global-load-balancer-admin). מידע נוסף זמין במאמר בנושא תיאורים של תפקידים מוגדרים מראש.

הגדרת PNP כדי לאפשר תעבורת נתונים ל-ELB

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

מציינים את כתובת ה-CIDR החיצונית כדי לאפשר תנועה לעומסי העבודה של ה-ELB הזה:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

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

  • ‫MANAGEMENT_API_SERVER: נתיב kubeconfig של שרת Management API. אם עדיין לא יצרתם קובץ kubeconfig לשרת ה-API באזור היעד, תוכלו לקרוא פרטים נוספים במאמר בנושא כניסה.
  • ‫PROJECT: השם של פרויקט GDC.
  • ‫CIDR: ה-CIDR החיצוני שצריך לגשת ל-ELB ממנו. המדיניות הזו נדרשת כי מאזן העומסים החיצוני משתמש ב-Direct Server Return ‏ (DSR), ששומר על כתובת ה-IP החיצונית של המקור ומדלג על מאזן העומסים בנתיב החזרה. מידע נוסף זמין במאמר בנושא יצירת כלל חומת אש גלובלי לתעבורה חיצונית לארגון.
  • ‫PORT: היציאה של הקצה העורפי בתרמילים שמאחורי מאזן העומסים. הערך הזה מופיע בשדה .spec.ports[].targetPort של המניפסט עבור משאב Service. השדה הזה הוא אופציונלי.

יוצרים ELB בשלוש שיטות שונות ב-GDC:

  • משתמשים ב-CLI של gcloud כדי ליצור איזון עומסים גלובלי או אזורי.
  • אפשר להשתמש ב-Networking Kubernetes Resource Model (KRM) API כדי ליצור איזון עומסים גלובלי או אזורי.
  • שימוש בשירות Kubernetes ישירות באשכול Kubernetes. השיטה הזו זמינה רק ל-ELB אזוריים.

אתם יכולים לטרגט עומסי עבודה של פוד או מכונה וירטואלית באמצעות KRM API ו-gdcloud CLI. כשמשתמשים בשירות Kubernetes ישירות באשכול Kubernetes, אפשר לטרגט עומסי עבודה רק באשכול שבו נוצר אובייקט Service.

יצירת ELB אזורי

יוצרים איזון עומסים אזורי באמצעות gdcloud CLI,‏ KRM API או Kubernetes Service באשכול Kubernetes:

gdcloud

יוצרים ELB שמטרגט עומסי עבודה של פוד או מכונה וירטואלית באמצעות CLI של gcloud.

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

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

  1. יוצרים משאב Backend כדי להגדיר את נקודת הקצה של ELB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME

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

    • ‫BACKEND_NAME: השם שבחרתם למשאב העורפי, למשל my-backend.
    • ‫LABELS: סלקטור שמגדיר באילו נקודות קצה בין פודים ומכונות וירטואליות להשתמש בשביל משאב ה-Backend הזה. לדוגמה, app=web.
    • ‫PROJECT_NAME: שם הפרויקט.
    • ‫ZONE: האזור שבו רוצים להשתמש להפעלה הזו. כדי להגדיר מראש את דגל האזור לכל הפקודות שדורשות אותו, מריצים את הפקודה: gdcloud config set core/zone ZONE. הדגל של האזור זמין רק בסביבות מרובות אזורים. השדה הזה הוא אופציונלי.
    • ‫CLUSTER_NAME: האשכול שההיקף של הסלקטורים המוגדרים מוגבל אליו. אם לא מציינים את השדה הזה, כל נקודות הקצה עם התווית שצוינה נבחרות. השדה הזה הוא אופציונלי.

  2. אפשר לדלג על השלב הזה אם ה-ELB הזה מיועד לעומסי עבודה של Pod. אם מגדירים ELB לעומסי עבודה של מכונות וירטואליות, צריך להגדיר את סוג בדיקת התקינות עבור ה-ELB. לדוגמה, כדי ליצור בדיקת תקינות של TCP, מגדירים אותה כך:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

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

    • ‫HEALTH_CHECK_NAME: השם שבחרתם למשאב של בדיקת תקינות, למשל my-health-check.
    • ‫CHECK_INTERVAL: משך הזמן בשניות מתחילת בדיקה אחת עד לתחילת הבדיקה הבאה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫HEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות לעבור כדי שנקודת הקצה תיחשב תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5.
    • ‫TIMEOUT: משך הזמן בשניות שצריך להמתין לפני שמדווח על כשל. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫UNHEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות להיכשל כדי שנקודת הקצה תיחשב כלא תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.
    • ‫PORT: היציאה שבה מתבצעת בדיקת תקינות. ערך ברירת המחדל הוא 80. השדה הזה הוא אופציונלי.
    • ‫ZONE: האזור שבו יוצרים את ה-ELB.

  3. יוצרים משאב BackendService ומוסיפים לו את משאב Backend שנוצר קודם:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

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

    • ‫BACKEND_SERVICE_NAME: השם שנבחר לשירות ה-Backend הזה.
    • ‫TARGET_PORT: רשימה מופרדת בפסיקים של יציאות יעד שהשירות לקצה העורפי הזה מתרגם, כאשר כל יציאת יעד מציינת את הפרוטוקול, את היציאה בכלל ההעברה ואת היציאה בשרת העורפי. אפשר לציין כמה יציאות יעד. השדה הזה חייב להיות בפורמט protocol:port:targetport, לדוגמה TCP:80:8080. השדה הזה הוא אופציונלי.
    • ‫HEALTH_CHECK_NAME: השם של משאב בדיקת תקינות. השדה הזה הוא אופציונלי. צריך לכלול את השדה הזה רק אם מגדירים ELB לעומסי עבודה של מכונות וירטואליות.

  4. מוסיפים את המשאב BackendService למשאב Backend שיצרתם קודם:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. אופציונלי: משתמשים בזיקה לסשן (session affinity) ב-ELB כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל את ההגדרה 'זיקה לסשן (session affinity)' למאזני עומסים, יוצרים מדיניות של שירות לקצה העורפי באמצעות הפקודה gdcloud compute load-balancer-policy create:

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

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

    • ‫POLICY_NAME: השם שבחרתם למדיניות של שירות הקצה העורפי.

    • ‫MODE: מצב הזיקה לסשן. יש שני מצבים נתמכים:

      • ‫NONE: שיוך סשנים מושבת. הבקשות מנותבות לכל מערכת קצה עורפי זמינה. זהו מצב ברירת המחדל.
      • ‫CLIENT_IP_DST_PORT_PROTO: בקשות מאותו טופל (כתובת IP של המקור, כתובת IP של היעד, יציאת היעד ופרוטוקול) מנותבות לאותו קצה עורפי.

    • ‫RESOURCE_LABEL: בורר התוויות שבוחר את שירות לקצה העורפי שאליו מוחל משאב BackendServicePolicy במרחב השמות של הפרויקט. אם כמה משאבי BackendServicePolicy תואמים לאותו שירות לקצה העורפי, ולפחות לאחת ממדיניות ההרשאה הזו מופעלת זיקה לסשן (session affinity), אז הזיקה לסשן (session affinity) למשאב BackendService הזה מופעלת.

  6. יוצרים משאב חיצוני מסוג ForwardingRule שמגדיר את כתובת ה-IP הווירטואלית שבה השירות זמין:

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME

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

    • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
    • ‫FORWARDING_RULE_EXTERNAL_NAME: השם שבחרתם לכלל ההעברה.
    • ‫CIDR: השדה הזה הוא אופציונלי. אם לא מציינים כתובת, המערכת שומרת אוטומטית כתובת IPv4/32 CIDR ממאגר כתובות ה-IP האזורי. מציינים את השם של משאב Subnet באותו מרחב שמות כמו כלל ההעברה הזה. משאב Subnet מייצג את המידע על הבקשה וההקצאה של רשת משנה אזורית. מידע נוסף על משאבי Subnet זמין במאמר דוגמאות למשאבים בהתאמה אישית.
    • ‫PROTOCOL_PORT: הפרוטוקול והיציאה שיוצגו בכלל ההעברה. השדה הזה חייב להיות בפורמט ip-protocol=TCP:80. היציאה שנחשפת חייבת להיות זהה ליציאה שהאפליקציה בפועל חושפת בתוך הקונטיינר.

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

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. כדי לאמת את ה-ELB שהוגדר, צריך לוודא שהתנאי Ready מופיע בכל אחד מהאובייקטים שנוצרו. מאמתים את התנועה באמצעות curl בקשה לכתובת ה-VIP:

    1. כדי לקבל את כתובת ה-VIP שהוקצתה, מתארים את כלל ההעברה:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. מאמתים את התנועה באמצעות בקשת curl אל ה-VIP ביציאה שצוינה בשדה PROTOCOL_PORT בכלל ההעברה:

      curl http://FORWARDING_RULE_VIP:PORT

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

      • ‫FORWARDING_RULE_VIP: כתובת ה-VIP של כלל ההעברה.
      • ‫PORT: מספר היציאה בשדה PROTOCOL_PORT בכלל ההעברה.

API

יוצרים ELB שמטרגט עומסי עבודה של פוד או מכונה וירטואלית באמצעות KRM API. ה-ELB הזה מכוון לכל עומסי העבודה בפרויקט שתואמים לתווית שהוגדרה באובייקט Backend.

כדי ליצור איזון עומסים אזורי באמצעות KRM API, פועלים לפי השלבים הבאים:

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

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

    • ‫MANAGEMENT_API_SERVER: נתיב kubeconfig של שרת Management API אזורי. מידע נוסף זמין במאמר מעבר להקשר אזורי.
    • ‫PROJECT_NAME: שם הפרויקט.
    • ‫BACKEND_NAME: השם של משאב Backend.
    • ‫CLUSTER_NAME: זהו שדה אופציונלי. בשדה הזה מציינים את האשכול שאליו מוגבל ההיקף של הסלקטורים שהוגדרו. השדה הזה לא רלוונטי לעומסי עבודה של מכונות וירטואליות. אם משאב Backend לא כולל את השדה clusterName, התוויות שצוינו חלות על כל עומסי העבודה בפרויקט.

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

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

    • ‫HEALTH_CHECK_NAME: השם שבחרתם למשאב של בדיקת תקינות, למשל my-health-check.
    • ‫PORT: היציאה שבה מתבצעת בדיקת תקינות. ערך ברירת המחדל הוא 80.
    • ‫TIMEOUT: משך הזמן בשניות שצריך להמתין לפני שמדווח על כשל. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫CHECK_INTERVAL: משך הזמן בשניות מתחילת בדיקה אחת עד לתחילת הבדיקה הבאה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫HEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות לעבור כדי שנקודת הקצה תיחשב תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.
    • ‫UNHEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות להיכשל כדי שנקודת הקצה תיחשב כלא תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.

  3. יוצרים אובייקט BackendService באמצעות משאב Backend שנוצר קודם. אם אתם מגדירים ELB לעומסי עבודה של מכונות וירטואליות, צריך לכלול את המשאב HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

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

    • ‫BACKEND_SERVICE_NAME: השם שנבחר למשאב BackendService.
    • ‫HEALTH_CHECK_NAME: השם של משאב HealthCheck שיצרתם קודם. אל תכללו את השדה הזה אם אתם מגדירים ELB לעומסי עבודה של pods.

  4. אופציונלי: משתמשים בזיקה לסשן (session affinity) ב-ELB כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל זיקה לסשן (session affinity) למאזני עומסים, יוצרים משאב BackendServicePolicy. המשאב הזה מגדיר את ההגדרות של זיקה לסשן ומחיל את המשאב BackendServicePolicy על המשאב BackendService. יוצרים את משאב BackendServicePolicy ומחילים אותו:

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

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

    • ‫POLICY_NAME: השם שבחרתם למדיניות של שירות הקצה העורפי.

    • ‫MODE: מצב הזיקה לסשן. יש שני מצבים נתמכים:

      • ‫NONE: שיוך סשנים מושבת. הבקשות מנותבות לכל מערכת קצה עורפי זמינה. זהו מצב ברירת המחדל.
      • ‫CLIENT_IP_DST_PORT_PROTO: בקשות מאותו טופל (כתובת IP של המקור, כתובת IP של היעד, יציאת היעד ופרוטוקול) מנותבות לאותו קצה עורפי.

    • ‫RESOURCE_LABEL: בורר התוויות שבוחר את שירות לקצה העורפי שאליו מוחל משאב BackendServicePolicy במרחב השמות של הפרויקט. אם כמה משאבי BackendServicePolicy תואמים לאותו שירות לקצה העורפי, ולפחות לאחת ממדיניות ההרשאה הזו מופעלת זיקה לסשן (session affinity), אז הזיקה לסשן (session affinity) למשאב BackendService הזה מופעלת.

  5. יוצרים משאב חיצוני ForwardingRule שמגדיר את כתובת ה-IP הווירטואלית שבה השירות זמין.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

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

    • ‫BACKEND_SERVICE_NAME: השם של משאב BackendService.
    • ‫FORWARDING_RULE_EXTERNAL_NAME: השם שבחרתם למשאב ForwardingRuleExternal.
    • ‫CIDR_NAME: השדה cidrRef הוא אופציונלי. אם לא מציינים, המערכת שומרת אוטומטית IPv4/32 CIDR ממאגר כתובות ה-IP האזורי. מציינים את השם של משאב Subnet באותו מרחב שמות כמו כלל ההעברה הזה. משאב Subnet מייצג את הבקשה ואת פרטי ההקצאה של רשת משנה אזורית. מידע נוסף על Subnetמשאבים זמין במאמר דוגמאות למשאבים מותאמים אישית.
    • ‫PORT: משתמשים בשדה ports כדי לציין מערך של יציאות L4 שחבילות מועברות אליהן אל שרתי הקצה העורפי שהוגדרו עם כלל ההעברה הזה. צריך לציין לפחות יציאה אחת. משתמשים בשדה port כדי לציין מספר יציאה. היציאה שחשופה צריכה להיות זהה ליציאה שהאפליקציה בפועל חושפת בתוך הקונטיינר.

    • ‫PROTOCOL: הפרוטוקול שבו יש להשתמש לכלל ההעברה, כמו TCP. רשומה במערך ports צריכה להיראות כך:

      ports:
- port: 80
  protocol: TCP

  6. כדי לאמת את ה-ELB שהוגדר, צריך לוודא שהתנאי Ready מופיע בכל אחד מהאובייקטים שנוצרו. מאמתים את התנועה באמצעות curl בקשה לכתובת ה-VIP:

    1. כדי לקבל את ה-VIP, משתמשים ב-kubectl get:

      kubectl get forwardingruleexternal -n PROJECT_NAME

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

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. מאמתים את התנועה באמצעות בקשת curl אל ה-VIP ביציאה שצוינה בשדה PORT בכלל ההעברה:

      curl http://FORWARDING_RULE_VIP:PORT

      מחליפים את FORWARDING_RULE_VIP בכתובת ה-VIP של כלל העברת השיחות.

Kubernetes Service

אפשר ליצור ELB ב-GDC על ידי יצירת Service Kubernetes מסוג LoadBalancer באשכול Kubernetes.

כדי ליצור שירות ELB:

  1. יוצרים קובץ YAML להגדרה Service מסוג LoadBalancer.

    אובייקט Service לדוגמה של שירות ELB:

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

    • ‫ELB_SERVICE_NAME: השם של שירות ELB.
    • ‫PROJECT_NAME: מרחב השמות של הפרויקט שמכיל את עומסי העבודה של ה-Backend.

    השדה port מגדיר את יציאת הקצה הקדמי שמוצגת בכתובת ה-VIP. בשדה targetPort מגדירים את יציאת הקצה העורפי שאליה רוצים להעביר את התנועה בעומסי העבודה של הקצה העורפי. מאזן העומסים תומך בתרגום כתובות רשת (NAT). יכול להיות שהיציאות של הקצה הקדמי והבק-אנד יהיו שונות.

  2. בשדה selector של הגדרת Service, מציינים תרמילים או מכונות וירטואליות כעומסי העבודה של ה-Backend.

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

    מידע נוסף על בחירת שירות זמין בכתובת https://kubernetes.io/docs/concepts/services-networking/service/.

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

  4. מחילים את קובץ ההגדרה Service על האשכול:

    kubectl apply -f ELB_FILE

    מחליפים את ELB_FILE בשם של Serviceקובץ ההגדרה של שירות ELB.

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

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

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

    • ‫PROJECT_NAME: מרחב השמות של הפרויקט שמכיל את עומסי העבודה של ה-Backend.
    • ‫ELB_SERVICE_NAME: השם של שירות ELB.

    הפלט שמתקבל צריך להיות דומה לדוגמה הבאה:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    ‫EXTERNAL-IP היא כתובת ה-IP של השירות שאפשר לגשת אליו מחוץ לארגון.

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

יצירת ELB גלובלי

יוצרים איזון עומסים גלובלי באמצעות gdcloud CLI או KRM API.

gdcloud

יוצרים ELB שמטרגט עומסי עבודה של פוד או מכונה וירטואלית באמצעות CLI של gcloud.

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

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

  1. יוצרים משאב Backend כדי להגדיר את נקודת הקצה של ELB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE

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

    • ‫BACKEND_NAME: השם שבחרתם למשאב העורפי, למשל my-backend.
    • ‫LABELS: סלקטור שמגדיר באילו נקודות קצה בין פודים ומכונות וירטואליות להשתמש בשביל משאב ה-Backend הזה. לדוגמה, app=web.
    • ‫PROJECT_NAME: שם הפרויקט.
    • ‫CLUSTER_NAME: הקלאסטר שההיקף של הסלקטורים המוגדרים מוגבל אליו. אם לא מציינים את השדה הזה, כל נקודות הקצה עם התווית שצוינה נבחרות. השדה הזה הוא אופציונלי.
    • ‫ZONE: האזור שבו רוצים להשתמש להפעלה הזו. כדי להגדיר מראש את דגל האזור לכל הפקודות שדורשות אותו, מריצים את הפקודה: gdcloud config set core/zone ZONE. הדגל של התחום זמין רק בסביבות מרובות תחומים. השדה הזה הוא אופציונלי.

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

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

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

    • ‫HEALTH_CHECK_NAME: השם שבחרתם למשאב של בדיקת תקינות, למשל my-health-check.
    • ‫CHECK_INTERVAL: משך הזמן בשניות מתחילת בדיקה אחת עד לתחילת הבדיקה הבאה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫HEALTHY_THRESHOLD: משך הזמן להמתנה לפני שמדווח על כשל. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5.
    • ‫TIMEOUT: משך הזמן בשניות שצריך להמתין לפני שמדווח על כשל. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫UNHEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות להיכשל כדי שנקודת הקצה תיחשב כלא תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.
    • ‫PORT: היציאה שבה מתבצעת בדיקת תקינות. ערך ברירת המחדל הוא 80. השדה הזה הוא אופציונלי.

  3. יוצרים משאב BackendService ומוסיפים לו את משאב Backend שנוצר קודם:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

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

    • ‫BACKEND_SERVICE_NAME: השם שנבחר לשירות ה-Backend הזה.
    • ‫TARGET_PORTS: רשימה מופרדת בפסיקים של יציאות יעד שהשירות לקצה העורפי הזה מתרגם, כאשר כל יציאת יעד מציינת את הפרוטוקול, את היציאה בכלל ההעברה ואת היציאה בשרת העורפי. אפשר לציין כמה יציאות יעד. השדה הזה חייב להיות בפורמט protocol:port:targetport, לדוגמה TCP:80:8080. השדה הזה הוא אופציונלי.
    • ‫HEALTH_CHECK_NAME: השם של משאב בדיקת תקינות. השדה הזה הוא אופציונלי. צריך לכלול את השדה הזה רק אם מגדירים ELB לעומסי עבודה של מכונות וירטואליות.

  4. מוסיפים את המשאב BackendService למשאב Backend שיצרתם קודם:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

  5. אופציונלי: משתמשים בזיקה לסשן (session affinity) ב-ELB כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל את ההגדרה 'זיקה לסשן (session affinity)' למאזני עומסים, יוצרים מדיניות של שירות לקצה העורפי באמצעות הפקודה gdcloud compute load-balancer-policy create:

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

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

    • ‫POLICY_NAME: השם שבחרתם למדיניות של שירות הקצה העורפי.

    • ‫MODE: מצב הזיקה לסשן. יש שני מצבים נתמכים:

      • ‫NONE: שיוך סשנים מושבת. הבקשות מנותבות לכל מערכת קצה עורפי זמינה. זהו מצב ברירת המחדל.
      • ‫CLIENT_IP_DST_PORT_PROTO: בקשות מאותו טופל (כתובת IP של המקור, כתובת IP של היעד, יציאת היעד ופרוטוקול) מנותבות לאותו קצה עורפי.

    • ‫RESOURCE_LABEL: בורר התוויות שבוחר את שירות לקצה העורפי שאליו מוחל משאב BackendServicePolicy במרחב השמות של הפרויקט. אם כמה משאבי BackendServicePolicy תואמים לאותו שירות לקצה העורפי, ולפחות לאחת ממדיניות ההרשאה הזו מופעלת זיקה לסשן (session affinity), אז הזיקה לסשן (session affinity) למשאב BackendService הזה מופעלת.

  6. יוצרים משאב חיצוני מסוג ForwardingRule שמגדיר את כתובת ה-IP הווירטואלית שבה השירות זמין:

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT_NAME \
  --global

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

    • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
    • ‫FORWARDING_RULE_EXTERNAL_NAME: השם שבחרתם לכלל ההעברה.
    • ‫CIDR: השדה הזה הוא אופציונלי. אם לא מציינים כתובת IP, מערכת IPv4/32 CIDR נשמרת באופן אוטומטי ממאגר כתובות ה-IP הגלובלי. מציינים את השם של משאב Subnet באותו מרחב שמות כמו כלל ההעברה הזה. משאב Subnet מייצג את הבקשה ואת פרטי ההקצאה של רשת משנה גלובלית. מידע נוסף על משאבי Subnet זמין במאמר דוגמאות למשאבים מותאמים אישית.
    • ‫PROTOCOL_PORT: הפרוטוקול והיציאה שיוצגו בכלל ההעברה. השדה הזה חייב להיות בפורמט ip-protocol=TCP:80. היציאה שנחשפת חייבת להיות זהה ליציאה שהאפליקציה בפועל חושפת בתוך הקונטיינר.

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

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. כדי לאמת את ה-ELB שהוגדר, צריך לוודא שהתנאי Ready מופיע בכל אחד מהאובייקטים שנוצרו. מאמתים את התנועה באמצעות curl בקשה לכתובת ה-VIP:

    1. כדי לקבל את כתובת ה-VIP שהוקצתה, מתארים את כלל ההעברה:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global

    2. מאמתים את התנועה באמצעות בקשת curl אל ה-VIP ביציאה שצוינה בשדה PROTOCOL_PORT בכלל ההעברה:

      curl http://FORWARDING_RULE_VIP:PORT

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

      • ‫FORWARDING_RULE_VIP: כתובת ה-VIP של כלל ההעברה.
      • ‫PORT: מספר היציאה מהשדה PROTOCOL_PORT בכלל ההעברה.

API

יוצרים ELB שמטרגט עומסי עבודה של פוד או מכונה וירטואלית באמצעות KRM API. ה-ELB הזה מכוון לכל עומסי העבודה בפרויקט שתואמים לתווית שהוגדרה באובייקט Backend. כדי ליצור איזון עומסים אזורי באמצעות KRM API, פועלים לפי השלבים הבאים:

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

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

    • ‫MANAGEMENT_API_SERVER: נתיב kubeconfig של שרת Management API הגלובלי. מידע נוסף מופיע במאמר בנושא מעבר להקשר הגלובלי.
    • ‫PROJECT_NAME: שם הפרויקט.
    • ‫BACKEND_NAME: השם של משאב Backend.
    • ‫CLUSTER_NAME: זהו שדה אופציונלי. בשדה הזה מציינים את האשכול שאליו מוגבל ההיקף של הסלקטורים שהוגדרו. השדה הזה לא רלוונטי לעומסי עבודה של מכונות וירטואליות. אם משאב Backend לא כולל את השדה clusterName, התוויות שצוינו חלות על כל עומסי העבודה בפרויקט.

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

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

    • ‫HEALTH_CHECK_NAME: השם שבחרתם למשאב של בדיקת תקינות, למשל my-health-check.
    • ‫PORT: היציאה שבה מתבצעת בדיקת תקינות. ערך ברירת המחדל הוא 80.
    • ‫TIMEOUT: משך הזמן בשניות שצריך להמתין לפני שמדווח על כשל. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫CHECK_INTERVAL: משך הזמן בשניות מתחילת בדיקה אחת עד לתחילת הבדיקה הבאה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 5. לא מומלץ להגדיר זמן קצוב לתפוגה ארוך יותר מ-checkInterval.
    • ‫HEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות לעבור כדי שנקודת הקצה תיחשב תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.
    • ‫UNHEALTHY_THRESHOLD: מספר הבדיקות הרציפות שצריכות להיכשל כדי שנקודת הקצה תיחשב כלא תקינה. אם לא מציינים ערך או אם הערך הוא 0, ברירת המחדל היא 2.

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

  3. יוצרים אובייקט BackendService באמצעות משאב Backend שנוצר קודם. אם אתם מגדירים ELB לעומסי עבודה של מכונות וירטואליות, צריך לכלול את המשאב HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

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

    • ‫BACKEND_SERVICE_NAME: השם שנבחר למשאב BackendService.
    • ‫HEALTH_CHECK_NAME: השם של משאב HealthCheck שיצרתם קודם. אל תכללו את השדה הזה אם אתם מגדירים ELB לעומסי עבודה של פודים.

    • ‫ZONE: האזור שבו נוצר משאב Backend. אפשר לציין כמה קצה עורפי בשדה backendRefs. לדוגמה:

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

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

      • ‫PORT: היציאה שנחשפת על ידי השירות.
      • ‫PROTOCOL: פרוטוקול שכבה 4 שהתנועה צריכה להתאים לו. יש תמיכה רק ב-TCP וב-UDP.

      • ‫TARGET_PORT: היציאה שאליה מתורגם הערך PORT, למשל 8080. אי אפשר לחזור על הערך של TARGET_PORT באותו אובייקט. דוגמה ל-targetPorts:

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. אופציונלי: משתמשים בזיקה לסשן (session affinity) ב-ELB כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל זיקה לסשן (session affinity) למאזני עומסים, יוצרים משאב BackendServicePolicy. המשאב הזה מגדיר את ההגדרות של זיקה לסשן ומחיל את המשאב BackendServicePolicy על המשאב BackendService. יוצרים את משאב BackendServicePolicy ומחילים אותו:

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

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

    • ‫POLICY_NAME: השם שבחרתם למדיניות של שירות הקצה העורפי.

    • ‫MODE: מצב הזיקה לסשן. יש שני מצבים נתמכים:

      • ‫NONE: שיוך סשנים מושבת. הבקשות מנותבות לכל מערכת קצה עורפי זמינה. זהו מצב ברירת המחדל.
      • ‫CLIENT_IP_DST_PORT_PROTO: בקשות מאותו טופל (כתובת IP של המקור, כתובת IP של היעד, יציאת היעד ופרוטוקול) מנותבות לאותו קצה עורפי.

    • ‫RESOURCE_LABEL: בורר התוויות שבוחר את שירות לקצה העורפי שאליו מוחל משאב BackendServicePolicy במרחב השמות של הפרויקט. אם כמה משאבי BackendServicePolicy תואמים לאותו שירות לקצה העורפי, ולפחות לאחת ממדיניות ההרשאה הזו מופעלת זיקה לסשן (session affinity), אז הזיקה לסשן (session affinity) למשאב BackendService הזה מופעלת.

  5. יוצרים משאב חיצוני ForwardingRule שמגדיר את כתובת ה-IP הווירטואלית שבה השירות זמין.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

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

    • ‫FORWARDING_RULE_EXTERNAL_NAME: השם שנבחר למשאב ForwardingRuleExternal.
    • ‫CIDR_NAME: השדה cidrRef הוא אופציונלי. אם לא מציינים כתובת IP, מערכת IPv4/32 CIDR נשמרת באופן אוטומטי ממאגר כתובות ה-IP הגלובלי. מציינים את השם של משאב Subnet באותו מרחב שמות כמו כלל ההעברה הזה. משאב Subnet מייצג את הבקשה ואת פרטי ההקצאה של רשת משנה גלובלית. מידע נוסף על משאבי Subnet זמין במאמר דוגמאות למשאבים מותאמים אישית.
    • ‫PORT: משתמשים בשדה ports כדי לציין מערך של יציאות L4 שחבילות מועברות אליהן אל שרתי הקצה העורפי שהוגדרו עם כלל ההעברה הזה. צריך לציין לפחות יציאה אחת. משתמשים בשדה port כדי לציין מספר יציאה. היציאה שחשופה צריכה להיות זהה ליציאה שהאפליקציה בפועל חושפת בתוך הקונטיינר.

    • ‫PROTOCOL: הפרוטוקול שבו יש להשתמש לכלל ההעברה, כמו TCP. רשומה במערך ports צריכה להיראות כך:

      ports:
- port: 80
  protocol: TCP

  6. כדי לאמת את ה-ELB שהוגדר, צריך לוודא שהתנאי Ready מופיע בכל אחד מהאובייקטים שנוצרו. מאמתים את התנועה באמצעות curl בקשה לכתובת ה-VIP:

    1. כדי לקבל את ה-VIP, משתמשים ב-kubectl get:

      kubectl get forwardingruleexternal -n PROJECT_NAME

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

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. מאמתים את התנועה באמצעות בקשת curl אל ה-VIP ביציאה שצוינה בשדה PORT בכלל ההעברה:

      curl http://FORWARDING_RULE_VIP:PORT

      מחליפים את FORWARDING_RULE_VIP בכתובת ה-VIP של כלל העברת השיחות.

יצירת מאזן עומסים חיצוני לאשכולות רגילים

בעל אפליקציה (AO) יכול ליצור שירות Kubernetes מסוג LoadBalancer כדי לחשוף שירותים חיצוניים. השירות הזה יכול לבחור רק את השרתים העורפיים באשכול הרגיל שבו השירות נוצר. היא שקולה ל-ELB בהיקף אזורי של Cluster. אין תמיכה ב-ELB גלובלי עבור אשכולות רגילים. מידע נוסף זמין במאמר מאזני עומסים גלובליים ואזוריים.

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

כדי להגדיר שירותי ELB, צריך:

  • הבעלים של הפרויקט שבו מגדירים את מאזן העומסים. מידע נוסף מופיע במאמר יצירת פרויקט.
  • יש לכם מדיניות כניסה מותאמת אישית של ProjectNetworkPolicy (PNP) כדי לאפשר תעבורה לשירות ELB הזה. מידע נוסף מופיע במאמר הגדרת PNP כדי לאפשר תנועה אל ELB עבור אשכולות רגילים.

  • יש לכם את התפקידים הנדרשים לניהול זהויות והרשאות גישה:

    • אדמין NetworkPolicy בפרויקט: יש לו גישה לניהול מדיניות רשת בפרויקט במרחב השמות של הפרויקט. צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד אדמין NetworkPolicy בפרויקט (project-networkpolicy-admin).
    • אדמין מאזן עומסים: צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד אדמין מאזן עומסים (load-balancer-admin).

הגדרת PNP כדי לאפשר תעבורה ל-ELB עבור אשכולות רגילים

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

קובץ ה-YAML הבא של מדיניות רשת ברמת הפרויקט מאפשר לתנועה מעומס עבודה בפרויקט אחר לגשת לעומס עבודה בפרויקט הנוכחי דרך ה-ELB.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
    labelSelector:
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: my-sc-1
      namespaces:
        matchLabels:
          kubernetes.io/metadata.name: my-app-ns
      workloads:
        matchLabels:
          app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          workloads:
            matchLabels:
              app: my-client
    ports:
    - protocol: TCP
      port: 8080

יצירת ELB אזורי לאשכולות רגילים

אפשר ליצור ELB ב-GDC על ידי יצירת Kubernetes Service מסוג LoadBalancer באשכול Kubernetes רגיל.

כדי ליצור שירות ELB:

  1. יוצרים קובץ YAML להגדרה Service מסוג LoadBalancer.

    אובייקט Service לדוגמה של שירות ELB:

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer

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

    • ‫ELB_SERVICE_NAME: השם של שירות ELB.
    • ‫ELB_SERVICE_NAMESPACE: מרחב השמות באשכול הסטנדרטי שמכיל את עומסי העבודה של ה-Backend.
    • ‫PORT: היציאה שנחשפת על ידי שירות Kubernetes עצמו. שירותים אחרים או לקוחות חיצוניים באותו אשכול יתחברו ליציאה הזו בכתובת ה-IP של השירות.
    • ‫TARGET_PORT: היציאה בתוך הקונטיינר של ה-pod שבה האפליקציה פועלת ומאזינה לחיבורים נכנסים. זה יכול להיות יציאה מספרית או יציאה עם שם שמוגדרת במפרט של מאגר ה-Pod.

    השדה port מגדיר את יציאת הקצה הקדמי שמוצגת בכתובת ה-VIP. בשדה targetPort מגדירים את יציאת הקצה העורפי שאליה רוצים להעביר את התנועה בעומסי העבודה של הקצה העורפי. מאזן העומסים תומך בתרגום כתובות רשת (NAT). יכול להיות שהיציאות של הקצה הקדמי והבק-אנד יהיו שונות.

  2. בשדה selector של הגדרת Service, מציינים צמדי מפתח/ערך כדי להתאים לעומסי העבודה של ה-Backend. במקרים של אשכולות רגילים, רק פודים נתמכים כעומסי עבודה.

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

    מידע נוסף על בחירת שירות זמין בכתובת https://kubernetes.io/docs/concepts/services-networking/service/.

  3. שומרים את המפרט של Service בקובץ YAML. מחליפים את שם הקובץ ב-ELB_FILE בפקודה הבאה.

  4. מחילים את קובץ ההגדרה Service על האשכול:

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE

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

    • ‫ELB_FILE:השם של קובץ ההגדרה של שירות ELB‏ Service.
    • ‫KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של האשכול הרגיל.

    אפשר לקבל את כתובות ה-IP של שירות ELB על ידי הצגת סטטוס השירות:

    kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME

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

    • ‫ELB_SERVICE_NAMESPACE: מרחב השמות שמכיל את עומסי העבודה של ה-Backend.
    • ‫ELB_SERVICE_NAME: השם של שירות ELB.

    הפלט שמתקבל צריך להיות דומה לדוגמה הבאה:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h

    ‫EXTERNAL-IP היא כתובת ה-IP של השירות שאפשר לגשת אליו מחוץ לארגון.

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

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

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

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

    • ‫LABEL: תווית שתואמת ל-LabelSelector בתצורת מאזן העומסים, כמו app=server.
    • ‫VM_NAME: השם של המכונה הווירטואלית שמקשרים.
    • ‫PROJECT_NAME: שם הפרויקט.

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