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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת ILB אזורי

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

gdcloud

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

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

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

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

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

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

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

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

כדי ליצור ILB אזורי באמצעות KRM API:

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

    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 לעומסי עבודה של Pod.

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

    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 הוא אופציונלי. אם לא מציינים CIDR, המערכת שומרת באופן אוטומטי CIDR של IPv4/32 ממאגר ה-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, יוצרים אובייקט Service של Kubernetes מסוג 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: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

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

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

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

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

    הפלט אמור להיראות כמו בדוגמה הבאה:

    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.

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

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

gdcloud

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

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

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

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

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

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

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

יצירת ILB שמטרגט עומסי עבודה של Pod או VM באמצעות KRM API. ה-ILB הזה מטרגט את כל עומסי העבודה בפרויקט שתואמים לתווית שהוגדרה באובייקט של ה-backend. כדי ליצור ILB אזורי באמצעות KRM API:

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

    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.

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

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

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

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

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

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

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

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

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

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

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

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

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

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

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

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

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

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

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

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