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

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

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

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

כדי להגדיר איזון עומסים פנימי, צריך:

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

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

    • צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד Load Balancer Admin (אדמין מאזן עומסים) ‏(load-balancer-admin).
    • עבור איזון עומסים גלובלי, צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד אדמין איזון עומסים גלובלי (global-load-balancer-admin). מידע נוסף זמין במאמר בנושא תיאורים של תפקידים מוגדרים מראש.

  • חשוב לדעת את סוג האירוח של האשכול שעליו פועלים עומסי העבודה. יש הוראות שונות להגדרת איזון עומסים ב-ILB עבור אשכולות משותפים ורגילים.

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

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

אפשר ליצור מאזני עומסים פנימיים בשלוש שיטות שונות ב-GDC:

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

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

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

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

gdcloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME

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

      curl http://FORWARDING_RULE_VIP:PORT

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

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

API

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

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

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

    אפשר להשתמש באותו משאב Backend לכל אזור, או ליצור משאבי Backend עם קבוצות שונות של תוויות לכל אזור.

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

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

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

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

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

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

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

      ports:
- port: 80
  protocol: TCP

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

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

      kubectl get forwardingruleinternal -n PROJECT_NAME

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

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-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, צריך ליצור אובייקט Kubernetes‏ Service מסוג LoadBalancer באשכול Kubernetes. מאזן העומסים הפנימי הזה מכוון רק לעומסי עבודה באשכול שבו נוצר אובייקט Service.

כדי ליצור ILB באמצעות האובייקט Service, פועלים לפי השלבים הבאים:

  1. יוצרים קובץ YAML להגדרה Service מסוג LoadBalancer. צריך לעצב את שירות ה-ILB כשירות פנימי באמצעות ההערה networking.gke.io/load-balancer-type: internal.

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

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

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

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

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

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

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

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

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

    kubectl apply -f ILB_FILE

    מחליפים את ILB_FILE בשם של קובץ ההגדרה Service של שירות ה-ILB.

    כשיוצרים שירות ILB, השירות מקבל כתובת IP. אפשר לראות את כתובת ה-IP של שירות ה-ILB בסטטוס השירות:

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

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

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

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

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

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

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

    ‫GDC תומך בשמות של מערכת שמות דומיינים (DNS) לשירותים. עם זאת, השמות האלה פועלים רק באותו אשכול עבור שירותי ILB. ממערכות אחרות, צריך להשתמש בכתובת ה-IP כדי לגשת לשירות ILB.

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

יוצרים איזון עומסים גלובלי באמצעות ה-CLI של gcloud או KRM API.

gdcloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

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

      curl http://FORWARDING_RULE_VIP:PORT

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

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

API

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.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, התוויות שצוינו חלות על כל עומסי העבודה בפרויקט.

    אפשר להשתמש באותו משאב Backend לכל אזור, או ליצור משאבי Backend עם קבוצות שונות של תוויות לכל אזור.

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

    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

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

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

    • ‫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. יוצרים משאב פנימי ForwardingRule שמגדיר את כתובת ה-IP הווירטואלית שבה השירות זמין.

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

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

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

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

      ports:
- port: 80
  protocol: TCP

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

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

      kubectl get forwardingruleinternal -n PROJECT_NAME

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

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-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 ישירות באשכול Kubernetes. אפשר לטרגט עומסי עבודה רק באשכול שבו נוצר אובייקט Service כשמשתמשים בשירות Kubernetes ישירות מאשכול Kubernetes.

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

כדי ליצור מאזני עומסים פנימיים ב-GDC, צריך ליצור אובייקט Kubernetes‏ Service מסוג LoadBalancer באשכול Kubernetes. ה-ILB הזה מכוון רק לעומסי עבודה באשכול שבו נוצר אובייקט Service.

כדי ליצור ILB באמצעות האובייקט Service, פועלים לפי השלבים הבאים:

  1. יוצרים קובץ YAML להגדרה Service מסוג LoadBalancer. צריך לעצב את שירות ה-ILB כשירות פנימי באמצעות ההערה networking.gke.io/load-balancer-type: internal.

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

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: ILB_SERVICE_NAMESPACE
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

    • ‫ILB_SERVICE_NAME: השם של שירות איזון העומסים הפנימי.
    • ‫ILB_SERVICE_NAMESPACE: מרחב השמות שמכיל את עומסי העבודה של ה-Backend.

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

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

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

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

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

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

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

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

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

    כשיוצרים שירות ILB, השירות מקבל כתובת IP. אפשר לראות את כתובת ה-IP של שירות ה-ILB בסטטוס השירות:

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

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

    • ‫ILB_SERVICE_NAMESPACE: מרחב השמות שמכיל את עומסי העבודה של ה-Backend.
    • ‫ILB_SERVICE_NAME: השם של שירות איזון העומסים הפנימי.
    • ‫KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של האשכול הרגיל.

    הפלט שיתקבל ייראה בערך כך:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h

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

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

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

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

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

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

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