מידע על מאגרי צמתים

במאמר הזה מוסבר איך פועלים מאגרי צמתים ב-Google Kubernetes Engine ‏ (GKE). מאגר צמתים הוא קבוצה של צמתים באשכול Standard, שלכולם יש את אותה הגדרה. במצב GKE Standard, אתם יכולים לבחור מבין כמה אפשרויות למאגרי הצמתים כדי לענות על הצרכים של עומסי העבודה. אם אתם בוחרים להשתמש ב-Autopilot, אתם לא צריכים להגדיר מאגרי צמתים: GKE מנהל את הצמתים בשבילכם, אבל אתם יכולים לשדרג ידנית מאגרי צמתים שמנוהלים על ידי Autopilot באשכולות Standard במקרה הצורך.

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

סקירה כללית

מאגר צמתים הוא קבוצה של צמתים באשכול, שלכולם יש את אותה הגדרה. מאגרי צמתים משתמשים במפרט NodeConfig. לכל צומת במאגר יש תווית צומת של Kubernetes,‏ cloud.google.com/gke-nodepool, שהערך שלה הוא השם של מאגר הצמתים.

כשיוצרים אשכול במצב רגיל, מספר הצמתים וסוג הצמתים שאתם מציינים משמשים ליצירת מאגר הצמתים הראשון של האשכול. כברירת מחדל, מאגר הצמתים הראשון (שנקרא מאגר הצמתים שמוגדר כברירת מחדל) מורכב משלושה צמתים בכל אחד מאזורי המחשוב של האשכול, עם תמונת הצומת שמוגדרת כברירת מחדל cos_containerd וסוג מכונה לשימוש כללי. אפשר לציין מגוון מאפיינים למאגר הצמתים, בהתאם לדרישות של עומס העבודה. לדוגמה, אתם יכולים ליצור מאגר צמתים באשכול עם כונני SSD מקומיים, פלטפורמת CPU מינימלית, מכונות וירטואליות במודל Spot, קובץ אימג' אחר של צומת, סוגי מכונות שונים או ממשק רשת וירטואלית יעיל יותר. אם מציינים את הדגל --num-nodes=0 כשיוצרים אשכול, GKE מדלג על יצירת מאגר הצמתים שמוגדר כברירת מחדל, כדי שתוכלו להוסיף מאגרי צמתים בהתאמה אישית מאוחר יותר. לשם כך נדרשת גרסת GKE‏ 1.36.4-gke.1469000 ואילך, 1.37.1-gke.1153000 ואילך או 1.38.0-gke.2352000 ואילך.

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

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

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

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

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

מאגרי צמתים בניהול Autopilot

באשכולות Standard, בנוסף למאגרי הצמתים הרגילים שמתוארים במסמך הזה, יכולים להיות גם מאגרי צמתים בניהול Autopilot, שנוצרים ומנוהלים על ידי GKE בשביל Autopilot ComputeClasses. מידע נוסף מופיע במאמר מידע על עומסי עבודה במצב אוטומטי ב-GKE Standard.

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

פריסת שירותים למאגרי צמתים ספציפיים

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

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

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

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

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

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

מחיקת מאגרי צמתים

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

  • ‫GKE מרוקן כל צומת במאגר הצמתים על ידי מחיקת פודים עם תקופת סיום תקינה שהוקצתה של MAX_POD. ‫MAX_POD הוא הערך המקסימלי של terminationGracePeriodSeconds שמוגדר ב-Pods שמתוזמנים בצומת, עם מגבלה של שעה אחת.
  • כברירת מחדל, GKE לא מכבד את ההגדרות של PodDisruptionBudget (PDB) במהלך מחיקה של מאגר צמתים. עם זאת, אתם יכולים לעדכן את ההגדרות של מאגר הצמתים כך ש-GKE יכבד את ה-PDB במהלך המחיקה של מאגר הצמתים, גם עם מגבלה של שעה. התחשבות ב-PDB מאפשרת לעומסי העבודה לעבור לצמתים אחרים באשכול. למידע נוסף על קביעת ההגדרה הזו, קראו את המאמר עדכון מאגר צמתים כך שיכבד את ה-PDB במהלך מחיקת מאגר הצמתים.

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

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

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

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