הגדרת מאזני עומסים בחבילה עם BGP

במאמר הזה מוסבר איך להגדיר מאזני עומסים בחבילה ולהשתמש בהם עם פרוטוקול Border Gateway ‏ (BGP) ב-Google Distributed Cloud. מצב איזון העומסים הזה תומך בפרסום של ServiceType LoadBalancer כתובות IP וירטואליות (VIP) באמצעות פרוטוקול שער הגבולות החיצוני (eBGP) עבור האשכולות שלכם. בתרחיש הזה, רשת האשכול היא מערכת אוטונומית שמקושרת למערכת אוטונומית אחרת, רשת חיצונית, באמצעות שיתוף פעולה.

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

השימוש בתכונה 'מאזני עומסים בחבילה עם BGP' מספק את היתרונות הבאים:

  • משתמש ביכולת איזון עומסים פעיל/פעיל N-way, ומספק מעבר מהיר יותר לגיבוי ושימוש יעיל יותר ברוחב הפס הזמין.
  • תמיכה בפרוטוקול Layer 3 שפועל עם מתגים ונתבים של צד שלישי מסוג top-of-rack ‏ (ToR) שתואמים ל-eBGP.
  • מאפשרת למרכזי נתונים שמריצים מחסנית מתקדמת של רשתות מוגדרות בתוכנה (SDN) לדחוף את הגבול של שכבה 3 עד לאשכולות.

איך פועל איזון עומסים בחבילה עם BGP

בקטעים הבאים מוסבר בקצרה איך פועלים מאזני עומסים בחבילה עם BGP.

קישור BGP בין רשתות שכנות

מאזני העומסים שכלולים בחבילה עם תכונת ה-BGP מתחילים כמה חיבורי BGP לתשתית שלכם. יש דרישות טכניות ל-BGP:

  • סשנים של Peering נפרדים ל-VIP של מישור הבקרה ול-VIP של השירותים.
  • סשנים של שיתוף פעולה בין רשתות במישור הבקרה מתחילים מכתובות ה-IP של צמתי מישור הבקרה.
  • סשנים של קישוריות שירות מתחילים מכתובות IP צפות שאתם מציינים בNetworkGatewayGroup משאב מותאם אישית.
  • שער הרשת של בקר GDC מנהל את כתובות ה-IP הצפות.
  • איזון עומסים משולב שמבוסס על BGP תומך רק בחיבור eBGP.
  • קישור מעבר בין רשתות שכנות (peering) מרובות קפיצות נתמך כברירת מחדל.
  • אין תמיכה בסיסמאות MD5 בסשנים של BGP.
  • אין תמיכה בסשנים של קישור מעבר בין רשתות שכנות (peering) שמבוססים על IPv6.
  • הנתיבים שמפורסמים לכל עמית צפויים להיות מופצים מחדש ברחבי הרשת, וניתן יהיה להגיע אליהם מכל מקום אחר באשכול.
  • מומלץ להשתמש ביכולת BGP ADD-PATH במצב קבלה עבור סשנים של שיתוף פעולה.
  • פרסום של כמה נתיבים מכל עמית מוביל לאיזון עומסים פעיל/פעיל.
  • צריך להפעיל את הניתוב הרב-נתיבי בעלות שווה (ECMP) ברשת כדי שאפשר יהיה להשתמש בכמה נתיבים לפיזור התנועה בין קבוצה של צמתי איזון עומסים.
  • מגדירים את סשני ה-BGP בציוד החיצוני (כמו מתגים מסוג Top-of-Rack) במצב פסיבי. צמתי האשכול וכתובות ה-IP הצפות פועלים כציוד פעיל ויוזמים את סשני ה-BGP.

איזון עומסים במישור הבקרה

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

בתרשים הבא מוצגת דוגמה לחיבור בין מישורי בקרה. באשכול יש שני צמתים של מישור הבקרה ברשת משנה אחת וצומת אחד ברשת משנה אחרת. בכל רשת משנה יש עמית חיצוני (TOR), והצמתים של מישור הבקרה של Google Distributed Cloud הם עמיתים של ה-TOR שלהם.

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

איזון עומסים בשירות

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

שירותים עם מדיניות רשת externalTrafficPolicy=Local נתמכים. עם זאת, ההגדרה externalTrafficPolicy=Local תלויה בעומס העבודה וגורמת לעדכון המסלולים בכל פעם שמוסיפים או מסירים Pod שתומך בשירות באופן מלא מצומת. התנהגות העדכון של המסלול הזה עלולה לגרום לניתוב של נתיבים מרובים בעלות שווה (ECMP) לשנות את זרימת התנועה, מה שעלול להוביל לירידה בתנועת הגולשים.

כתובות IP צפות

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

כתובות IP צפות מסירות את הדאגה לגבי מיפוי כתובות IP של רמקולי BGP לצמתים. שער הרשת של בקר GDC דואג להקצאת NetworkGatewayGroup לצמתים ומנהל גם את כתובות ה-IP הצפות. אם צומת מושבת, שער הרשת של בקר GDC מקצה מחדש כתובות IP צפות כדי להבטיח שלעמיתים חיצוניים תהיה כתובת IP דטרמיניסטית להתקשרות.

אפליקציות חיצוניות להשוואה

כדי לבצע איזון עומסים במישור הנתונים, אפשר להשתמש באותם עמיתים חיצוניים שצוינו עבור שיתוף פעולה במישור הבקרה בקטע loadBalancer.controlPlaneBGP של קובץ ההגדרות של האשכול. אפשרות אחרת היא לציין עמיתי BGP שונים.

אם רוצים לציין עמיתי BGP שונים עבור שילוב של מישור הנתונים, מוסיפים את המפרטים של המשאבים BGPLoadBalancer ו-BGPPeer לקובץ ההגדרות של האשכול. אם לא מציינים את המשאבים המותאמים אישית האלה, מישורי הבקרה של העמיתים משמשים באופן אוטומטי למישור הנתונים.

מציינים את עמיתי ה-BGP החיצוניים שמשמשים להפעלת סשנים של BGP עם כתובות IP צפות במשאב המותאם אישית BGPPeer, שמוסיפים לקובץ ההגדרות של האשכול. המשאב BGPPeer כולל תווית לזיהוי על ידי המשאב המותאם אישית BGPLoadBalancer התואם. מציינים את התווית התואמת בשדה peerSelector במשאב המותאם אישית BGPLoadBalancer כדי לבחור את המשאב BGPPeer לשימוש.

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

צמתים של מאזן עומסים

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

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

דוגמה לטופולוגיית פירינג

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

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

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

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

תכנון השילוב עם תשתית חיצונית

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

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

  • צריך להגדיר תשתית חיצונית כדי ליצור קשר עם קבוצה של כתובות IP צפות שמורות לצורך תקשורת במישור הנתונים. כתובות ה-IP הצפות משמשות ליצירת קשר BGP עם כתובות ה-VIP של השירות. מומלץ להשתמש בשתי כתובות IP צפות ובשני עמיתים כדי להבטיח זמינות גבוהה של סשנים של BGP. תהליך שמירת כתובות IP צפות מתואר כחלק מהגדרת האשכול לאיזון עומסים מאוגד עם BGP.

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

הגדרת אשכול לאיזון עומסים בחבילה באמצעות BGP

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

  • ‫NetworkGatewayGroup: מציין כתובות IP צפות שמשמשות להפעלת סשנים של BGP peering בשירותים.

  • ‫BGPLoadBalancer: מציין באמצעות בוררי תוויות אילו עמיתים משמשים לאיזון עומסים של BGP.

  • ‫BGPPeer: מציין עמיתים בודדים, כולל תווית לבחירה, עבור סשנים של BGP peering.

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

  1. מוסיפים את השדה advancedNetworking לקובץ התצורה של האשכול בקטע clusterNetwork ומגדירים אותו ל-true.

    השדה הזה מאפשר יכולות מתקדמות של רשת, במיוחד משאב Network Gateway Group.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: CLUSTER_NAMESPACE
spec:
...
  clusterNetwork:
    advancedNetworking: true

    מחליפים את CLUSTER_NAMESPACE במרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכולות ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם שם האשכול הוא test, מרחב השמות הוא cluster-test.

  2. בקטע loadBalancer של קובץ ההגדרות של האשכול, מגדירים את mode ל-bundled ומוסיפים שדה type עם ערך של bgp.

    ערכי השדות האלה מאפשרים איזון עומסים משולב שמבוסס על BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. כדי לציין את פרטי ה-BGP-peering למישור הבקרה, מוסיפים את השדות הבאים לקטע loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

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

    • ‫CLUSTER_ASN: מספר המערכת האוטונומית של האשכול שנוצר.
    • PEER_IP: כתובת ה-IP של מכשיר ה-peer החיצוני.
    • ‫PEER_ASN: מספר המערכת האוטונומית של הרשת שמכילה את מכשיר ה-peer החיצוני.
    • ‫CP_NODE_IP: (אופציונלי) כתובת ה-IP של צומת מישור הבקרה שמתחבר לצומת החיצוני. אם לא מציינים צמתים של מישור הבקרה, כל הצמתים של מישור הבקרה יכולים להתחבר לצומת החיצוני. אם מציינים כתובת IP אחת או יותר, רק הצמתים שצוינו משתתפים בסשנים של שיתוף פעולה.

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

  4. מגדירים את השדות loadBalancer.ports, loadBalancer.vips ו-loadBalancer.addressPools (מוצגים ערכי ברירת המחדל).

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

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

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

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. כדי לשמור כתובות IP צפות, מגדירים את המשאב המותאם אישית NetworkGatewayGroup:

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

    ...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
  nodeSelector:    # optional
  - NODE_SELECTOR
...

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

    • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכול ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם נותנים לאשכול את השם test, מרחב השמות הוא cluster-test.
    • ‫FLOATING_IP: כתובת IP מאחת מרשתות המשנה של האשכול. צריך לציין לפחות כתובת IP אחת, אבל מומלץ לציין לפחות שתי כתובות IP.
    • ‫NODE_SELECTOR: (אופציונלי) בורר תוויות לזיהוי צמתים ליצירת מופעים של סשנים של שיתוף פעולה עם עמיתים חיצוניים, כמו מתגי ToR (מתגים בחלק העליון של המתקן). אם לא צריך את השדה הזה, מסירים אותו.

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

  7. (אופציונלי) כדי לציין את עמיתי ה-BGP שבהם יש להשתמש לאיזון עומסים במישור הנתונים, מגדירים את המשאב המותאם אישית BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...

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

    • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכול ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם נותנים לאשכול את השם test, מרחב השמות הוא cluster-test.
    • ‫PEER_LABEL: התווית שמשמשת לזיהוי העמיתים שבהם צריך להשתמש לאיזון עומסים. כל משאב מותאם אישית BGPPeer עם תווית תואמת מציין את הפרטים של כל עמית.

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

  8. (אופציונלי) כדי לציין את עמיתי ה-VPC החיצוניים למישור הנתונים, מגדירים משאב מותאם אישית אחד או יותר מסוג BGPPeer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: BGP_PEER_NAME
  namespace: CLUSTER_NAMESPACE
  labels:
    PEER_LABEL: "true"
spec:
  localASN: CLUSTER_ASN
  peerASN: PEER_ASN
  peerIP: PEER_IP
  sessions: SESSION_QTY
  selectors:   # Optional
    gatewayRefs:
    - GATEWAY_REF
  ...

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

    • ‫BGP_PEER_NAME: השם של העמית.
    • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכול ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם נותנים לאשכול את השם test, מרחב השמות הוא cluster-test.
    • ‫PEER_LABEL: התווית שמשמשת לזיהוי העמיתים שבהם צריך להשתמש לאיזון עומסים. התווית הזו צריכה להתאים לתווית שצוינה במשאב המותאם אישית BGPLoadBalancer.
    • ‫CLUSTER_ASN: מספר המערכת האוטונומית של האשכול שנוצר.
    • PEER_IP: כתובת ה-IP של מכשיר ה-peer החיצוני. מומלץ לציין לפחות שני עמיתים חיצוניים, אבל חובה לציין לפחות אחד.
    • ‫PEER_ASN: מספר המערכת האוטונומית של הרשת שמכילה את מכשיר ה-peer החיצוני.
    • ‫SESSION_QTY: מספר הסשנים שצריך ליצור עבור העמית הזה. מומלץ ליצור לפחות שני סשנים כדי לשמור על חיבור לעמית למקרה שאחד מהצמתים יושבת.
    • ‫GATEWAY_REF: (אופציונלי) השם של משאב NetworkGatewayGroup לשימוש בפירינג. אם לא מגדירים את המדיניות, אפשר להשתמש בכל המשאבים של השער. משתמשים בהגדרה הזו בשילוב עם השדה nodeSelector במשאב NetworkGatewayGroups כדי לבחור באילו צמתים להשתמש לצורך קישור בין רשתות שכנות (peering) עם עמית חיצוני ספציפי, כמו מתג ToR. אם מציינים שער אחד בכל שורה, יכול להיות שיהיה צורך בכמה רשומות כדי לבחור כמה NetworkGatewayGroups.

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

  9. כשמריצים את bmctl cluster create כדי ליצור את האשכול, מתבצעות בדיקות קדם הפעלה. בין היתר, בדיקות קדם-הפעלה מאמתות את ההגדרה של קישור בין רשתות שכנות (peering) באמצעות BGP למישור הבקרה, ומדווחות על בעיות ישירות לתחנת העבודה של האדמין לפני שאפשר ליצור את האשכול.

    אם הפעולה תצליח, משאבי איזון העומסים של BGP שנוספו (NetworkGatewayGroup,‏ BGPLoadBalancer ו-BGPPeer) יועברו לאשכול הניהול במרחב השמות של אשכול המשתמשים. כדאי להשתמש בקובץ kubeconfig של אשכול האדמין כשמבצעים עדכונים נוספים במשאבים האלה. אחר כך, אשכול האדמין מבצע גישור בין השינויים באשכול המשתמשים. אם עורכים את המשאבים האלה ישירות באשכול המשתמשים, אשכול האדמין מחליף את השינויים שלכם בפעולות השוואה הבאות.

מומלץ להשתמש ביכולת ADD-PATH של BGP עבור סשנים של קישור בין רשתות שכנות (peering), כפי שמפורט ב-RFC 7911. כברירת מחדל, פרוטוקול BGP מאפשר לפרסם רק הצעד הבא יחיד לעמיתים עבור קידומת יחידה. BGP ADD-PATH מאפשר לפרסם כמה הצעדים הבאים לאותה קידומת. כשמשתמשים ב-ADD-PATH עם איזון עומסים מאוגד שמבוסס על BGP, האשכול יכול לפרסם כמה צמתי אשכול כצמתי קצה קדמי (הצעדים הבאים) עבור שירות מאזן עומסים (LB) (קידומת). צריך להפעיל ECMP ברשת כדי שתעבורת נתונים תתפזר על פני כמה נתיבים. היכולת לפזר את תעבורת נתונים על ידי פרסום של כמה צמתי אשכול כהצעדים הבאים משפרת את ההתאמה לעומס (scaling) של קיבולת מישור הנתונים לאיזון עומסים.

אם מכשיר חיצוני עמית, כמו מתג או נתב ToR (Top-of-Rack), תומך ב-BGP ADD-PATH, מספיק להפעיל רק את תוסף הקבלה. איזון עומסים בחבילה עם BGP פועל ללא היכולת ADD-PATH, אבל ההגבלה של פרסום צומת אחד של איזון עומסים לכל סשן של שותפות מאפשרת קיבולת מוגבלת של מישור הנתונים של איזון העומסים. בלי ADD-PATH,‏ Google Distributed Cloud בוחר צמתים לפרסום ממאגר הצמתים של מאזן העומסים ומנסה לפזר את הקפיצות הבאות עבור כתובות VIP שונות בצמתים שונים.

הגבלת קישור BGP בין רשתות שכנות לצמתים של מאזן העומסים

‫Google Distributed Cloud מקצה באופן אוטומטי כתובות IP צפות בכל צומת באותה רשת משנה כמו כתובת ה-IP הצפה. סשנים של BGP מופעלים מכתובות ה-IP האלה גם אם הם לא מגיעים לצמתים של איזון העומסים. ההתנהגות הזו היא מכוונת, כי הפרדנו את מישור הבקרה (BGP) ממישור הנתונים (מאגרי צמתים של איזון עומסים).

אם רוצים להגביל את קבוצת הצמתים שאפשר להשתמש בהם לצורך BGP peering, אפשר להקצות רשת משנה אחת לשימוש רק בצמתים של מאזן העומסים. כלומר, אפשר להגדיר את כל הצמתים ברשת המשנה הזו כך שיהיו במאגר הצמתים של מאזן העומסים. לאחר מכן, כשמגדירים כתובות IP צפות שמשמשות לחיבור BGP, צריך לוודא שהן מאותה רשת משנה. ‫Google Distributed Cloud מוודא שהקצאות של כתובות IP צפות וחיבורי BGP מתבצעים רק מצמתים של מאזן העומסים.

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

החל מגרסה 1.14.0 של Google Distributed Cloud, מאזן העומסים המשולב שמבוסס על BGP תומך ב-IPv6. עם ההשקה של תמיכת IPv6, אתם יכולים להגדיר שירותי LoadBalancer של IPv6 ושל סטאק כפול באשכול שהוגדר לרשתות של סטאק כפול. בקטע הזה מוסבר על השינויים שנדרשים כדי להגדיר איזון עומסים משולב עם BGP בשיטת dual-stack.

כדי להפעיל שירותים של איזון עומסים עם תמיכה ב-dual-stack, צריך לבצע את שינויי ההגדרות הבאים:

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

    • מציינים גם IPv4 וגם IPv6 Service CIDR בקובץ ההגדרות של האשכול בקטע spec.clusterNetwork.services.cidrBlocks.

    • הגדרת משאבי ClusterCIDRConfig מתאימים כדי לציין טווחי CIDR של IPv4 ו-IPv6 עבור Pods.

    מידע נוסף על הגדרת אשכול לרשתות עם תמיכה כפולה ב-IPv4/IPv6 זמין במאמר בנושא רשתות עם תמיכה כפולה ב-IPv4/IPv6.

  • מציינים מאגר כתובות IPv6 בקובץ התצורה של האשכול בקטע spec.loadBalancer.addressPools. כדי ש-MetalLB יקצה כתובות IP לשירות Dual Stack, צריך שיהיה לפחות מאגר כתובות אחד עם כתובות בפורמט IPv4 וגם בפורמט IPv6.

ההגדרה לדוגמה הבאה מדגישה את השינויים שנדרשים לאיזון עומסים משולב עם BGP ב-dual-stack:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

מגבלות על איזון עומסים משולב עם BGP, בעל תמיכה כפולה ב-IPv4 ו-IPv6

כשמגדירים את האשכול לשימוש במאזן עומסים משולב עם BGP, חשוב לשים לב למגבלות הבאות:

  • אין תמיכה באיזון עומסים במישור הבקרה של IPv6.

  • לא ניתן להשתמש בסשנים של IPv6 BGP, אבל אפשר לפרסם מסלולי IPv6 באמצעות סשנים של IPv4 באמצעות BGP מרובה פרוטוקולים.

הגדרות לדוגמה

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

הגדרת כל הצמתים לשימוש באותם עמיתים

כפי שמוצג בתרשים הבא, ההגדרה הזו יוצרת קבוצה של עמיתים חיצוניים (10.8.0.10 ו-10.8.0.11) שכל הצמתים יכולים להגיע אליהם. הגישה לכל הצמתים במישור הבקרה (10.0.1.10, 10.0.1.11 ו-10.0.2.10) ולכתובות ה-IP הצפות (10.0.1.100 ו-10.0.2.100) שמוקצות לצמתים במישור הנתונים מתבצעת דרך עמיתים.

אותם עמיתים חיצוניים נגישים באמצעות כל אחת מכתובות ה-IP הצפות (10.0.1.100 או 10.0.2.100) ששמורות ל-loadBalancerServices peering. אפשר להקצות את כתובות ה-IP הצפות לצמתים שנמצאים באותה רשת משנה.

איזון עומסים של BGP שבו כל הצמתים משתמשים באותם עמיתים

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

מציינים את כתובות ה-IP הצפות שבהן רוצים להשתמש עבור סשנים של שירותים להעברת נתונים בין רשתות (peering) לאיזון עומסים במשאב המותאם אישית NetworkGatewayGroup. בדוגמה הזו, מכיוון שלא צוין BGPLoadBalancer, נעשה שימוש אוטומטי בחיבורי ה-Peering של מישור הבקרה עבור סשנים של BGP במישור הנתונים.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

הגדרת צמתים ספציפיים של מישור הבקרה לצורך יצירת קשר עם עמיתים חיצוניים ספציפיים

כפי שמוצג בתרשים הבא, ההגדרה הזו מובילה לשני צמתים של מישור הבקרה (10.0.1.10 ו-10.0.1.11) שמתבצעת ביניהם הצצה עם עמית חיצוני אחד (10.0.1.254). הצומת השלישי של מישור הבקרה (10.0.2.10) מבצע הצצה עם עמית חיצוני אחר (10.0.2.254). ההגדרה הזו שימושית כשלא רוצים שכל הצמתים יתחברו לכל העמיתים. לדוגמה, יכול להיות שתרצו שצמתים של מישור הבקרה יבצעו הצצה רק עם המתגים התואמים שלהם בחלק העליון של המתלה (ToR).

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

איזון עומסים של BGP עם מיפוי מפורש של צמתי מישור הבקרה לעמיתים

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

מציינים את כתובות ה-IP הצפות שבהן רוצים להשתמש עבור סשנים של שירותים להעברת נתונים בין רשתות (peering) לאיזון עומסים במשאב המותאם אישית NetworkGatewayGroup. בדוגמה הזו, מכיוון שלא צוין BGPLoadBalancer, נעשה שימוש אוטומטי בחיבורי ה-Peering של מישור הבקרה עבור סשנים של BGP במישור הנתונים.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

הגדרה של מישור הבקרה ורמת הנתונים בנפרד

כפי שמוצג בתרשים הבא, התצורה הזו יוצרת שני צמתים של מישור הבקרה (10.0.1.10 ו-10.0.1.11) שמבצעים פירינג עם עמית חיצוני אחד (10.0.1.254), והצומת השלישי של מישור הבקרה (10.0.2.11) מבצע פירינג עם עמית חיצוני אחר (10.0.2.254).

אפשר להגיע לצד שלישי חיצוני (10.0.3.254) באמצעות כל אחת מכתובות ה-IP הצפות (10.0.3.100 או 10.0.3.101) ששמורות להפעלת סשנים של שירותי איזון עומסים ב-Peering. אפשר להקצות את כתובות ה-IP הצפות לצמתים שנמצאים באותה תת-רשת.

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

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

מציינים את כתובות ה-IP הצפות שבהן רוצים להשתמש עבור סשנים של שירותים להעברת נתונים בין רשתות (peering) לאיזון עומסים במשאב המותאם אישית NetworkGatewayGroup.

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

  • מציינים את ה-peer החיצוני למישור הנתונים במשאב BGPPeer ומוסיפים תווית לשימוש בבחירת ה-peer, כמו cluster.baremetal.gke.io/default-peer: "true".

  • מציינים את התווית התואמת לשדה peerSelector במשאב BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

שינוי ההגדרה של איזון עומסים מבוסס-BGP

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

משתמשים בקובץ ה-kubeconfig של אשכול האדמין כשמבצעים עדכונים נוספים במשאבים שקשורים ל-BGP‏ (NetworkGatewayGroup,‏ BGPLoadBalancer ו-BGPPeer). לאחר מכן, אשכול האדמין מתאם את השינויים לאשכול המשתמש. אם עורכים את המשאבים האלה ישירות באשכול המשתמשים, אשכול האדמין ידרוס את השינויים שביצעתם בפיוסים הבאים.

מישור הבקרה

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

בקטעים הבאים מפורטות השיטות המומלצות לעדכון פרטי ה-BGP Peering במישור הבקרה.

בדיקת הסטטוס של העמית לפני העדכון

כדי לצמצם את הסיכון להגדרת עמיתים בצורה שגויה, חשוב לבדוק שמפגשי BGP של מישור הבקרה נמצאים במצב הצפוי לפני שמבצעים שינויים. לדוגמה, אם אתם מצפים שכל סשני ה-BGP peering יהיו פעילים, אתם צריכים לוודא שכל bgp-advertiser הפודים מדווחים ready, מה שמצביע על כך שהסשנים פעילים. אם הסטטוס הנוכחי לא תואם למה שציפיתם, צריך לפתור את הבעיה לפני שמעדכנים את הגדרת ה-peer.

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

עדכון עמיתים בצורה מבוקרת

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

  1. להוסיף או לעדכן עמית אחד.
  2. מחכים שההגדרה תסתנכרן.
  3. מוודאים שהאשכול יכול להתחבר לעמית החדש או המעודכן.
  4. מסירים את עמיתי ה-Peering הישנים או המיותרים.

שירותים

כדי לעדכן את מאגרי הכתובות ואת הגדרות הצומת של מאזן העומסים, עורכים את nodePoolSpec במשאב Cluster.

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

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

פתרון בעיות

בסעיפים הבאים מוסבר איך לגשת למידע על פתרון בעיות שקשורות לאיזון עומסים בחבילה עם BGP.

סשנים של BGP במישור הבקרה

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

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

אם יצירת האשכול נכשלת בבדיקות קדם הפעלה, צריך לבדוק את היומנים של בדיקות קדם ההפעלה כדי לראות אם יש שגיאות. קובצי יומן של בדיקת טרום-טיסה עם חותמת תאריך נמצאים בספרייה baremetal/bmctl-workspace/CLUSTER_NAME/log.

בזמן הריצה, רכיבי ה-BGP של מישור הבקרה פועלים כ-pods סטטיים בכל צומת של מישור הבקרה וכותבים פרטי אירועים ליומנים. ה-Pods הסטטיים האלה כוללים את המחרוזת bgpadvertiser בשם שלהם, לכן משתמשים בפקודה kubectl get pods הבאה כדי להציג את הסטטוס של ה-Pods של רמקול ה-BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

כשה-Pods פועלים בצורה תקינה, התגובה נראית כך:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

משתמשים בפקודה הבאה כדי להציג את היומנים של Pod‏ bgpadvertiser-node-01:

kubectl -n kube-system logs bgpadvertiser-node-01

סשני BGP של שירותים

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

משתמשים בפקודה kubectl get הבאה כדי להציג את הסשנים הנוכחיים:

kubectl -n kube-system get bgpsessions

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

NAME                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

משתמשים בפקודה kubectl describe הבאה כדי לקבל את משאב BGPSession של סשן ה-BGP‏ 10.0.1.254-node-01:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

משאב BGPSession שמוחזר צריך להיראות בערך כמו הדוגמה הבאה:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

משתמשים בפקודה kubectl get כדי לקבל את משאבי BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

התגובה, שצריכה להיות דומה לדוגמה הבאה, מציגה את המסלולים שמפורסמים:

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

משתמשים בפקודה kubectl describe כדי לראות פרטים על קפיצות הביניים שכל מסלול מפרסם.

שחזור גישה ל-VIP של מישור הבקרה עבור אשכולות בניהול עצמי

כדי לקבל שוב גישה ל-VIP של מישור הבקרה באשכול אדמין, באשכול היברידי או באשכול עצמאי, צריך לעדכן את הגדרת ה-BGP באשכול. כמו שמוצג בדוגמה הבאה של פקודה, משתמשים ב-SSH כדי להתחבר לצומת, ואז משתמשים בפקודה kubectl כדי לפתוח את משאב האשכול לעריכה.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

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

  • ‫IDENTITY_FILE: השם של קובץ הזהות של SSH שמכיל את מפתח הזהות לאימות מפתח ציבורי.
  • ‫CLUSTER_NODE_IP: כתובת ה-IP של צומת האשכול.
  • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
  • ‫CLUSTER_NAME: שם האשכול.

משנים את הגדרת ה-peering של BGP באובייקט של האשכול. אחרי ששומרים את ההגדרה החדשה של האשכול, עוקבים אחרי תקינות הפודים bgpadvertiser. אם ההגדרה פועלת, הפודים מופעלים מחדש והופכים לתקינים אחרי שהם מתחברים לעמיתים שלהם.

אימות ידני של BGP

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

בדיקות קדם-הפעלה מבצעות אוטומציה של משימות האימות הבאות של BGP:

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

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

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

חשוב לזכור שחיבורי BGP נוצרים מצמתי מישור הבקרה, ולכן צריך לבדוק את התהליך הזה מאחד מצמתי מישור הבקרה המתוכננים.

קבלת קובץ בינארי של תוכנית בדיקה של BGP

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

  1. מושכים את תמונת ה-Docker של ansible-runner.

    ללא שימוש במראה של מאגר הרישום

    אם אתם לא משתמשים ב-registry mirror, מריצים את הפקודות הבאות כדי למשוך את תמונת ה-Docker של ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    עם Registry Mirror

    אם משתמשים ב-registry mirror, מריצים את הפקודות הבאות כדי למשוך את קובץ האימג' של ansible-runner docker:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    מחליפים את REGISTRY_HOST בשם של שרת ה-mirror של הרישום.

  2. כדי לחלץ את הקובץ הבינארי bgpadvertiser.

    ללא שימוש במראה של מאגר הרישום

    כדי לחלץ את הקובץ הבינארי של bgpadvertiser, מריצים את הפקודה הבאה:

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    עם Registry Mirror

    כדי לחלץ את הקובץ הבינארי של bgpadvertiser, מריצים את הפקודה הבאה:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

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

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

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

    • ‫USERNAME: שם המשתמש שבו אתם משתמשים כדי לגשת לצומת של מישור הבקרה.

    • ‫CP_NODE_IP: כתובת ה-IP של צומת מישור הבקרה.

הגדרת חיבור BGP

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

  1. יוצרים קובץ תצורה בצומת בנתיב /tmp/bgpadvertiser.conf שדומה לקובץ הבא:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

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

    • ‫NODE_IP: כתובת ה-IP של צומת מישור הבקרה שאתם נמצאים בו.
    • ‫CLUSTER_ASN: מספר המערכת האוטונומית שמשמש את האשכול.
    • ‫PEER_IP: כתובת ה-IP של אחד מהעמיתים החיצוניים שרוצים לבדוק.
    • ‫PEER_ASN: מספר המערכת האוטונומית של הרשת שמכילה את מכשיר ה-peer החיצוני.

  2. מריצים את ה-daemon‏ bgpadvertiser, ומחליפים את ה-VIP של מישור הבקרה בפקודה הבאה:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    מחליפים את CONTROL_PLANE_VIP בכתובת ה-IP שבה תשתמשו עבור ה-VIP של מישור הבקרה. הפקודה הזו גורמת למפרסם BGP לפרסם את הכתובת הזו למכשיר העמית.

  3. צופים בפלט של התוכנית.

    בשלב הזה, הדימון (daemon) של bgpadvertiser מתחיל לפעול, מנסה להתחבר למחשב העמית ומפרסם את כתובת ה-VIP. התוכנית מדפיסה מעת לעת הודעות (ראו את פלט הדוגמה הבא) שכוללות את BGP_FSM_ESTABLISHED כשהחיבור ל-BGP נוצר.

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

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

בדיקת תנועה

כדי לבדוק שהרשת יכולה להעביר תנועה לכתובת ה-VIP, צריך להוסיף את כתובת ה-VIP לצומת של מישור הבקרה שבו פועל bgpadvertiser. מריצים את הפקודה הבאה במסוף אחר כדי שאפשר יהיה להשאיר את bgpadvertiser פועל:

  1. מוסיפים את ה-VIP לצומת של מישור הבקרה:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

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

    • ‫CONTROL_PLANE_VIP: הארגומנט --advertise-ip של ה-VIP של bgpadvertiser.
    • ‫INTF_NAME: ממשק Kubernetes בצומת. כלומר, הממשק עם כתובת ה-IP שהזנתם בהגדרת Google Distributed Cloud עבור loadBalancer.bgpPeers.controlPlaneNodes.

  2. מבצעים פינג ל-VIP מצומת אחרת:

    ping CONTROL_PLANE_VIP

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

הסרת המשאבים

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

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

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. בצומת של מישור הבקרה, מקישים על Ctrl+C במסוף bgpadvertiser כדי להפסיק את bgpadvertiser.

  3. מוודאים שלא פועלים תהליכי bgpadvertiser:

    ps -ef | grep bgpadvertiser

  4. אם אתם רואים תהליכים שפועלים, צריך להפסיק אותם באמצעות הפקודה kill.

מגבלה של BGP Selector עם Cloud API/Terraform

כשמנהלים אשכולות של Google Distributed Cloud באמצעות GKE On-Prem API (Terraform, מסוף Google Cloud או gcloud CLI), אי אפשר לציין סלקטורים של BGP בהגדרת האשכול. אם האשכול משתמש באיזון עומסים של BGP וב-Egress NAT, יכול להיות שפירינג של BGP ייכשל.

דרך לעקיפת הבעיה

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

  1. הפעלת אכיפה של אנטי-אפיניות לכתובות IP: מפצלים את BGP NetworkGatewayGroup למשאבי NetworkGatewayGroup נפרדים (אחד לכל כתובת IP צפה) ומשתמשים ב-nodeSelector בכל NetworkGatewayGroup כדי להצמיד את כתובת ה-IP הצפה לצומת פיזי ספציפי. כך מונעים מכתובות IP מרובות של BGP להגיע לאותו צומת.
  2. ביטול הניהול של איזון העומסים: באשכול האדמין, מסירים את ההערה baremetal.cluster.gke.io/managed: "true" מהמשאב BGPLoadBalancer במרחב השמות של אשכול המשתמשים. הפעולה הזו תמנע מבקרי ה-GDC להחזיר את השינויים הידניים שלכם.
  3. תיקון משאבי BGPPeer: מתקנים ידנית את משאבי BGPPeer באשכול האדמין כדי להוסיף את הבלוק selectors שמפנה למשאבי NetworkGatewayGroup ולכתובות ה-IP הצפות הנכונות. השינויים האלה מסתנכרנים עם אשכול המשתמשים ומייצבים את סשני ה-BGP.