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

בדף הזה מוסבר מהם דומיינים של טופולוגיה ואיך מגדירים אותם.

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

הדף הזה מיועד לאדמינים ולארכיטקטים שמגדירים פתרונות IT וארכיטקטורת מערכת בהתאם לאסטרטגיית החברה, ויוצרים ומנהלים כללי מדיניות שקשורים להרשאות משתמשים. במאמר תפקידים ומשימות נפוצים של משתמשי GKE מפורטים תפקידים ומשימות לדוגמה שמוזכרים בתוכן של Google Cloud .

סקירה כללית

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

  • כשל בתוכנה, כמו שרתי vCenter שונים
  • כשל בחומרה, כמו ארונות שרתים שונים, מקורות חשמל שונים ובניינים שונים

ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware, כשיוצרים אשכול ומגדירים דומיין טופולוגיה, צריך להגדיר תווית טופולוגיה. אחרי שיוצרים את האשכול, תווית הטופולוגיה מאוכלסת בתוויות של הצמתים בדומיין הטופולוגיה.

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

  • גרסה 1.32 ואילך: מגדירים אילוצים של פריסת טופולוגיה כברירת מחדל ברמת האשכול. מידע נוסף מופיע במאמר schedulerConfiguration.

  • משתמשים באילוץ ברירת המחדל ברמת האשכול של Kubernetes,‏ "topology.kubernetes.io/zone", כמפתח בתווית הטופולוגיה. מידע נוסף מופיע במאמר אילוצי ברירת מחדל מובנים.

  • מגדירים את PodTemplate ב-Deployment, ב-StatefulSet או ב-ReplicaSet, בהתאם למפתח התווית של הטופולוגיה. במפרט של ה-Pod, משתמשים במפתח בתווית הטופולוגיה כערך של השדה topologySpreadConstraints.topologyKey. המפתח הזה מאפשר למתזמן של Kubernetes לפזר Pods בדומיין הטופולוגיה כדי להבטיח זמינות גבוהה ולמנוע ריכוז יתר באזור אחד במקרה של כשל. מידע נוסף על הגדרת topologySpreadConstraints במפרט של ה-Pod זמין במאמר אילוצי פריסה של טופולוגיית Pod במסמכי התיעוד של Kubernetes.

דוגמאות לתוויות של דומיינים בטופולוגיה

נניח שאתם יוצרים את שלושת הדומיינים הבאים של טופולוגיה כשאתם יוצרים אשכול משתמשים:

...
topologyDomains:
- name: "topology-domain-1"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-1"
...

...
topologyDomains:
- name: "topology-domain-2"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-2"
...

...
topologyDomains:
- name: "topology-domain-3"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-3"
...

אחרי שיוצרים את האשכול, מעדכנים את המפרט של ה-Pod, לדוגמה:

...
topologySpreadConstraints:
  topologyKey: "topology.examplepetstore.com/zone"
...

ברמה גבוהה, מתזמן Kubernetes משתמש ב-topology.examplepetstore.com/zone כדי להפריד את צומתי האשכול לקבוצות שונות, zone-1,‏ zone-2 ו-zone-3. לאחר מכן, המתזמן מפזר את ה-Pods בין שלוש קבוצות הצמתים האלה.

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

כדי להבטיח שימוש יעיל בכל משאבי האשכולות על ידי מתזמן Kubernetes, מומלץ לפעול לפי ההנחיות הבאות:

  • הדומיינים של הטופולוגיה צריכים להיות מאוזנים. צריך לספק כמויות כמעט שוות של קיבולת מעבד (CPU) ו-RAM בכל דומיין טופולוגיה.
  • צריך לספק לפחות שני דומיינים של טופולוגיה, ועדיף שלושה.
  • אל תפזרו לפי יותר ממפתח טופולוגיה אחד.
  • הצמתים צריכים להיות בגודל דומה בכל דומיין טופולוגיה.
  • אם אתם משתמשים בtaints ו-tolerations להפרדת עומסי עבודה בתוך אשכול, כל קבוצת צמתים צריכה לעמוד בדרישות הקודמות.

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

מגבלות

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

המאמרים הבאים