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

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

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

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

יש הוראות נפרדות להגדרת מאזני עומסים אלסטיים (ELB) לאשכולות משותפים ורגילים.

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

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

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

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

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

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

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

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

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

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

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

יצירת ELB אזורי

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

gdcloud

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

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

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

  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: בורר שמגדיר באילו נקודות קצה בין Pods לבין מכונות וירטואליות להשתמש במשאב העורפי הזה. לדוגמה, app=web.
    • ‫PROJECT_NAME: שם הפרויקט.
    • ‫ZONE: האזור שבו משתמשים להפעלה הזו. כדי להגדיר מראש את דגל האזור לכל הפקודות שדורשות אותו, מריצים את הפקודה: gdcloud config set core/zone 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: השם שנבחר לשירות לקצה העורפי.
    • ‫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 כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל את הזיקה לסשן במאזני עומסים, יוצרים מדיניות של שירות לקצה העורפי באמצעות הפקודה 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 תואמים לאותו שירות לקצה העורפי, ולפחות באחת מהמדיניות האלה מופעלת זיקה לסשן, הזיקה לסשן מופעלת במשאב BackendService הזה.

  6. יוצרים משאב ForwardingRule חיצוני שמגדיר את ה-VIP שבו השירות זמין:

    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: השדה הזה הוא אופציונלי. אם לא מציינים CIDR, המערכת שומרת באופן אוטומטי CIDR של IPv4/32 ממאגר ה-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 שמטרגט עומסי עבודה של Pod או של VM באמצעות KRM API. ה-ELB הזה מטרגט את כל עומסי העבודה בפרויקט שתואמים לתווית שהוגדרה באובייקט Backend.

כדי ליצור ELB אזורי באמצעות 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 לעומסי עבודה של Pod.

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

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

    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 הוא אופציונלי. אם לא מציינים טווח, המערכת מקצה באופן אוטומטי טווח CIDR של IPv4/32 ממאגר כתובות ה-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

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

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

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

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

יוצרים ELB גלובלי באמצעות ה-gdcloud CLI או ה-API של KRM.

gdcloud

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

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

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

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

  6. יוצרים משאב ForwardingRule חיצוני שמגדיר את ה-VIP שבו השירות זמין:

    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: השדה הזה הוא אופציונלי. אם לא מציינים טווח, המערכת מקצה באופן אוטומטי טווח CIDR של IPv4/32 ממאגר כתובות ה-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 שמטרגט עומסי עבודה של Pod או של VM באמצעות KRM API. ה-ELB הזה מטרגט את כל עומסי העבודה בפרויקט שתואמים לתווית שהוגדרה באובייקט של ה-backend. כדי ליצור ELB אזורי באמצעות 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.

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

    • ‫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 כדי להבטיח שבקשות מאותו לקוח ינותבו באופן עקבי לאותו קצה עורפי. כדי להפעיל את הזיקה לסשן במאזני עומסים, צריך ליצור משאב BackendServicePolicy. המשאב הזה מגדיר את הגדרות הזיקה לסשן (session affinity) ומחיל את המשאב 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 תואמים לאותו שירות לקצה העורפי, ולפחות באחת מהמדיניות האלה מופעלת זיקה לסשן, הזיקה לסשן מופעלת במשאב BackendService הזה.

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

    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 הוא אופציונלי. אם לא מציינים טווח, המערכת מקצה באופן אוטומטי טווח CIDR של IPv4/32 ממאגר כתובות ה-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 ברמת האשכול באזור. אי אפשר להשתמש ב-ELB גלובלי באשכולות רגילים. מידע נוסף זמין במאמר מאזני עומסים גלובליים ואזוריים.

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

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

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

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

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

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

כדי ששירותי ELB יפעלו, צריך להגדיר ולהחיל מדיניות כניסה מותאמת אישית משלכם, שתאפשר תנועה לעומסי העבודה של שירות ה-ELB הזה.ProjectNetworkPolicy מדיניות הרשת ב-Kubernetes שולטת בגישה לעומסי העבודה, ולא במאזן העומסים עצמו. מאזני העומסים חושפים את עומסי העבודה לרשת של הלקוח, ולכן צריך להגדיר מדיניות רשת מפורשת כדי לאפשר תנועה חיצונית ליציאה של עומס העבודה, כמו 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:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

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

כדי ליצור מאזני עומסים חיצוניים ב-GDC, יוצרים Service של Kubernetes מסוג 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: מרחב השמות באשכול הרגיל שמכיל את עומסי העבודה בקצה העורפי.
    • ‫PORT: היציאה שנחשפת על ידי שירות Kubernetes עצמו. שירותים אחרים או לקוחות חיצוניים בתוך האשכול יתחברו ליציאה הזו בכתובת ה-IP של השירות.
    • ‫TARGET_PORT: היציאה בתוך הקונטיינר של ה-pod שבה האפליקציה פועלת ומאזינה לחיבורים נכנסים. היציאה יכולה להיות יציאה מספרית או יציאה עם שם שמוגדר במפרט של מאגר ה-Pod.

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

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

    בורר שאתם מגדירים, על סמך התאמה בין התוויות שאתם מציינים לבין התוויות של עומסי העבודה. ה-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:השם של קובץ ההגדרה של Service לשירות ELB.
    • ‫KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של האשכול הרגיל.

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

    kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME

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

    • ‫ELB_SERVICE_NAMESPACE: מרחב השמות שמכיל את עומסי העבודה בקצה העורפי.
    • ‫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 של השירות שאפשר לגשת אליו מחוץ לארגון.

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

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

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

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

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

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