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

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

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

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

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הפרויקט.

הגדרה של חשבונות שירות ב-IAM ל-GKE

‫GKE משתמש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

כדי להעניק את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות שמוגדר כברירת המחדל של Compute Engine, מבצעים את השלבים הבאים:

המסוף

  1. נכנסים לדף Welcome:

    מעבר לדף Welcome

  2. בשדה מספר הפרויקט, לוחצים על העתקה ללוח.
  3. נכנסים לדף IAM:

    כניסה לדף IAM

  4. לוחצים על Grant access.
  5. בשדה New principals, מציינים את הערך הבא:
    ‫
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     מחליפים את PROJECT_NUMBER במספר הפרויקט שהעתקתם.
  6. בתפריט Select a role (בחירת תפקיד), בוחרים בתפקיד Kubernetes Engine Default Node Service Account (חשבון השירות שמשמש כברירת מחדל לצומת ב-Kubernetes Engine).
  7. לוחצים על Save.

gcloud

  1. איך מוצאים את Google Cloud מספר הפרויקט: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    מחליפים את PROJECT_ID במזהה הפרויקט.

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

    12345678901
  2. מקצים לחשבון השירות של Compute Engine שמוגדר כברירת מחדל את התפקיד roles/container.defaultNodeServiceAccount: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    מחליפים את PROJECT_NUMBER במספר הפרויקט מהשלב הקודם.

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

אפשר להוסיף מאגר צמתים חדש לאשכול GKE Standard באמצעות ה-CLI של gcloud, Google Cloud המסוף או Terraform. ב-GKE יש גם תמיכה בהקצאת צמתים אוטומטית, שמאפשרת לנהל באופן אוטומטי את מאגרי הצמתים באשכול על סמך דרישות ההרחבה.

שיטה מומלצת:

יוצרים חשבון שירות עם הרשאות מינימליות לניהול זהויות והרשאות גישה (IAM) כדי שמאגרי הצמתים ישתמשו בו במקום בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. הוראות ליצירת חשבון שירות עם הרשאות מינימליות זמינות במאמר הקשחת האבטחה באשכול.

gcloud

כדי ליצור מאגר צמתים, מריצים את הפקודה gcloud container node-pools create:

gcloud container node-pools create POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --service-account SERVICE_ACCOUNT

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

  • ‫POOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: השם של האשכול הקיים.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
  • ‫SERVICE_ACCOUNT: השם של חשבון השירות ב-IAM שהצמתים ישתמשו בו.

    מומלץ מאוד לציין חשבון שירות IAM עם הרשאות מינימליות, שהצמתים יוכלו להשתמש בו במקום בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. במאמר שימוש בחשבון שירות עם הרשאות מינימליות מוסבר איך ליצור חשבון שירות עם הרשאות מינימליות.

    כדי לציין חשבון שירות מותאם אישית ב-CLI של gcloud, מוסיפים את הדגל הבא לפקודה:

    --service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    מחליפים את SERVICE_ACCOUNT_NAME בשם של חשבון השירות עם ההרשאות המינימליות.

רשימה מלאה של הדגלים האופציונליים שניתן לציין מופיעה במאמר בנושא gcloud container node-pools create.

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

Creating node pool POOL_NAME...done.
Created [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/us-central1/clusters/CLUSTER_NAME/nodePools/POOL_NAME].
NAME: POOL_NAME
MACHINE_TYPE: e2-medium
DISK_SIZE_GB: 100
NODE_VERSION: 1.21.5-gke.1302

בפלט הזה אפשר לראות פרטים על מאגר הצמתים, כמו סוג המכונה וגרסת GKE שפועלת בצמתים.

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

gcloud container node-pools list --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

המסוף

כדי להוסיף מאגר צמתים לאשכול קיים מסוג Standard, מבצעים את השלבים הבאים:

  1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על השם של אשכול Standard שרוצים לשנות.

  3. לוחצים על הוספת מאגר צמתים.

  4. מגדירים את מאגר הצמתים.

  5. בתפריט הניווט, לוחצים על אבטחה.

  6. אופציונלי, אפשר לציין חשבון שירות מותאם אישית ב-IAM עבור הצמתים:
    1. בדף הגדרות מתקדמות, מרחיבים את הקטע אבטחה.
    2. בתפריט Service account בוחרים את חשבון השירות המועדף.

    מומלץ מאוד לציין חשבון שירות IAM עם הרשאות מינימליות, שהצמתים יוכלו להשתמש בו במקום בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. במאמר שימוש בחשבון שירות עם הרשאות מינימליות מוסבר איך ליצור חשבון שירות עם הרשאות מינימליות.

  7. לוחצים על יצירה כדי להוסיף את מאגר הצמתים.

Terraform

אפשר להשתמש באחת מהדוגמאות הבאות:

  • מוסיפים מאגר צמתים שמשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine:
resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    service_account = google_service_account.default.email
  }
}
  • הוספת מאגר צמתים שמשתמש בחשבון שירות מותאם אישית ב-IAM:

  1. יוצרים חשבון שירות ב-IAM ומקצים לו את התפקיד roles/container.defaultNodeServiceAccount בפרויקט:

    resource "google_service_account" "default" {
  account_id   = "service-account-id"
  display_name = "Service Account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

  2. יוצרים מאגר צמתים שמשתמש בחשבון השירות החדש:

    resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    service_account = google_service_account.default.email
  }
}

מידע נוסף על שימוש ב-Terraform זמין במאמר תמיכה ב-Terraform ל-GKE.

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

gcloud

כדי להציג ברשימה את כל מאגרי הצמתים של אשכול רגיל, מריצים את הפקודה gcloud container node-pools list:

gcloud container node-pools list --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

כדי לראות את הפרטים של מאגר צמתים ספציפי, מריצים את הפקודה gcloud container node-pools describe:

gcloud container node-pools describe POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫POOL_NAME: השם של מאגר הצמתים שרוצים להציג.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

המסוף

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

  1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על השם של אשכול Standard.

  3. לוחצים על הכרטיסייה Nodes.

  4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים להציג.

שינוי גודל של מאגר צמתים

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

שינוי מספר הצמתים כדי לשנות את קנה המידה אופקית

gcloud

כדי לשנות את הגודל של מאגרי הצמתים של אשכול, מריצים את הפקודה gcloud container clusters resize:

gcloud container clusters resize CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-pool POOL_NAME \
    --num-nodes NUM_NODES

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

  • ‫CLUSTER_NAME: שם האשכול שרוצים לשנות את הגודל שלו.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
  • ‫POOL_NAME: השם של מאגר הצמתים שרוצים לשנות את הגודל שלו.
  • ‫NUM_NODES: מספר הצמתים במאגר באשכול אזורי. אם אתם משתמשים באשכולות אזוריים או רב-אזוריים, NUM_NODES הוא מספר הצמתים בכל אזור שבו נמצא מאגר הצמתים.

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

המסוף

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

  1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על השם של אשכול Standard שרוצים לשנות.

  3. לוחצים על הכרטיסייה Nodes.

  4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים לשנות את הגודל שלו.

  5. לוחצים על שינוי גודל.

  6. בשדה Number of nodes (מספר הצמתים), מזינים את מספר הצמתים שרוצים במאגר הצמתים ולוחצים על Resize (שינוי גודל).

  7. חוזרים על הפעולה לכל מאגר צמתים לפי הצורך.

שינוי קנה מידה אנכי על ידי שינוי מאפייני המכונה של הצומת

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

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

מעדכנים לפחות אחד ממאפייני המכונה המודגשים בפקודה הבאה:

gcloud container node-pools update POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --machine-type MACHINE_TYPE \
    --disk-type DISK_TYPE \
    --disk-size DISK_SIZE

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

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

  • ‫POOL_NAME: השם של מאגר הצמתים שרוצים לשנות את הגודל שלו.
  • ‫CLUSTER_NAME: שם האשכול שרוצים לשנות את הגודל שלו.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
  • ‫MACHINE_TYPE: סוג המכונה שבה רוצים להשתמש לצמתים. מידע נוסף זמין במאמר בנושא gcloud container node-pools update.
  • ‫DISK_TYPE: סוג דיסק האתחול של מכונת ה-VM של הצומת. הערך חייב להיות אחד מהאפשרויות הבאות: pd-standard,‏ pd-ssd,‏ pd-balanced.
  • ‫DISK_SIZE: הגודל של דיסקי האתחול של מכונות וירטואליות של צמתים ב-GB. ברירת המחדל היא 100GB.

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

שדרוג מאגר צמתים

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

שיטה מומלצת:

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

כשמשדרגים מאגר צמתים ב-GKE Standard, אפשר לבחור בין שלוש שיטות שדרוג שניתנות להגדרה, כולל שדרוגים עם צמתים זמניים, שדרוגים מסוג blue-green ושדרוגים מסוג blue-green עם התאמה אוטומטית לעומס (גרסת Preview). מאגרי צמתים שמנוהלים על ידי Autopilot באשכולות Standard תמיד משתמשים בשדרוגים מצטברים.

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

איך פועלים שדרוגי צמתים

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

במהלך שדרוגים אוטומטיים או ידניים של צמתים, PodDisruptionBudgets (PDBs) וPod termination grace period נשמרים למשך שעה לכל היותר. אם לא ניתן לתזמן את הפודים שפועלים בצומת להפעלה בצמתים חדשים אחרי שעה, GKE יתחיל את השדרוג בכל מקרה. ההתנהגות הזו מתרחשת גם אם מגדירים את ה-PDB כך שכל הרפליקות יהיו זמינות תמיד. כדי לעשות את זה, צריך להגדיר את השדה maxUnavailable לערך 0 או 0%, או להגדיר את השדה minAvailable לערך 100% או למספר הרפליקות. בכל התרחישים האלה, GKE מוחק את ה-Pods אחרי שעה אחת כדי לאפשר את מחיקת הצומת.

שיטה מומלצת:

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

מידע נוסף על מה צפוי במהלך סיום של צומת באופן כללי זמין בנושא Pods.

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

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

כדי ששדרוג של מאגר צמתים ייחשב להשלמה, צריך ליצור מחדש את כל הצמתים במאגר. אם השדרוג התחיל אבל לא הסתיים והוא במצב של שדרוג חלקי, יכול להיות שהגרסה של מאגר הצמתים לא תשקף את הגרסה של כל הצמתים. מידע נוסף זמין במאמר Some node versions don't match the node pool version after an incomplete node pool upgrade. כדי לוודא ששדרוג מאגר הצמתים הסתיים, בודקים את סטטוס השדרוג של מאגר הצמתים. אם פעולת השדרוג חורגת מתקופת השמירה, צריך לוודא שגרסת כל צומת בודד תואמת לגרסת מאגר הצמתים.

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

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

ההגבלות הבאות חלות על דיסקים קשיחים קבועים:

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

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

שדרוג ידני של מאגר צמתים

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

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

לפני שמשדרגים ידנית את מאגר הצמתים, חשוב לקחת בחשבון את התנאים הבאים:

  • שדרוג של מאגר צמתים עלול לשבש את עומסי העבודה שפועלים במאגר הצמתים הזה. כדי להימנע מכך, אפשר ליצור מאגר צמתים חדש עם הגרסה הנדרשת ולהעביר את עומס העבודה. אחרי ההעברה, אפשר למחוק את מאגר הצמתים הישן.
  • אם משדרגים מאגר צמתים עם Ingress במצב שגיאה, קבוצת המופעים לא מסתנכרנת. כדי לפתור את הבעיה, קודם בודקים את הסטטוס באמצעות הפקודה kubectl get ing. אם קבוצת המופעים לא מסונכרנת, אפשר לפתור את הבעיה על ידי הפעלה מחדש של המניפסט ששימש ליצירת ה-ingress.

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

המסוף

כדי לשדרג מאגר צמתים רגיל באמצעות Google Cloud המסוף, מבצעים את השלבים הבאים:

  1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. לוחצים על שם האשכול.

  3. בדף פרטי האשכול, לוחצים על הכרטיסייה צמתים.

  4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים לשדרג.

  5. לוחצים על עריכה.

  6. לוחצים על שינוי בקטע גרסת הצומת.

  7. בוחרים את הגרסה הרצויה מהרשימה הנפתחת Node version ואז לוחצים על Change.

יכול להיות שיחלפו כמה דקות עד שגרסת הצומת תשתנה.

gcloud

המשתנים הבאים משמשים בפקודות שבקטע הזה:

  • ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים שיש לשדרג.
  • ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לשדרג.
  • ‫CONTROL_PLANE_LOCATION: המיקום (אזור או אזור זמינות) של מישור הבקרה, למשל us-central1 או us-central1-a.
  • ‫VERSION: גרסת Kubernetes שאליה יש לשדרג את הצמתים. לדוגמה, --cluster-version=1.34.1-gke.1293000 או cluster-version=latest.

שדרוג מאגר צמתים:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

כדי לציין גרסה אחרת של GKE בצמתים, משתמשים בדגל האופציונלי --cluster-version:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

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

מידע נוסף מופיע במאמרי העזרה בנושא gcloud container clusters upgrade.

פריסת Pod למאגר צמתים ספציפי

אתם יכולים לפרוס באופן מפורש Pod למאגר צמתים ספציפי באמצעות nodeSelector במניפסט של ה-Pod. ‫nodeSelector מתזמן Pods בצמתים עם תווית תואמת.

לכל מאגרי הצמתים של GKE יש תוויות בפורמט הבא: cloud.google.com/gke-nodepool: POOL_NAME. מוסיפים את התווית הזו לשדה nodeSelector ב-Pod, כמו בדוגמה הבאה:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    cloud.google.com/gke-nodepool: POOL_NAME

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

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

שדרוג לאחור של מאגר צמתים

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

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

שיטה מומלצת:

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

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

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

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

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

אפשר למחוק רק מאגרי צמתים רגילים. אי אפשר למחוק את מאגרי הצמתים שמנוהלים על ידי Autopilot ופועלים באשכולות Standard. מערכת GKE מנקה אותם באופן אוטומטי כשכבר לא צריך אותם.

כדי למחוק מאגר צמתים באמצעות ה-CLI של gcloud או מסוףGoogle Cloud :

gcloud

כדי למחוק מאגר צמתים, מריצים את הפקודה gcloud container node-pools delete:

gcloud container node-pools delete POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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

  • ‫POOL_NAME: השם של מאגר הצמתים שרוצים למחוק.
  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

המסוף

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

  1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על השם של אשכול Standard שרוצים לשנות.

  3. לוחצים על הכרטיסייה Nodes.

  4. בקטע Node Pools (מאגרי צמתים), לוחצים על לצד מאגר הצמתים שרוצים למחוק.

  5. כשמופיעה בקשה לאישור, לוחצים על מחיקה.

עדכון מאגר צמתים כדי להתחשב ב-PDB במהלך מחיקה של מאגר צמתים

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

כדי לעדכן את ההגדרה של מאגר הצמתים, מריצים את הפקודה הבאה ב-CLI של gcloud:

gcloud container node-pools update POOL_NAME
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --respect-pdb-during-node-pool-deletion

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

  • ‫POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

אפשר גם להשתמש בדגל --respect-pdb-during-node-pool-deletion כשמוסיפים מאגר צמתים.

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

עדכון מאגר צמתים כך שלא יתחשב ב-PDB במהלך מחיקה של מאגר צמתים

אתם יכולים לעדכן מאגר צמתים כדי לחזור להגדרת ברירת המחדל של אי-התחשבות ב-PDB במהלך מחיקה של מאגר צמתים.

כדי לעדכן את ההגדרה, מריצים את הפקודה הבאה ב-CLI של gcloud:

gcloud container node-pools update POOL_NAME
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-respect-pdb-during-node-pool-deletion

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

  • ‫POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

העברת צמתים לסוג מכונה אחר

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

העברת עומסי עבודה בין מאגרי צמתים

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

פתרון בעיות

מידע לפתרון בעיות זמין במאמרים בנושא פתרון בעיות במאגרי צמתים רגילים ופתרון בעיות ברישום צמתים.

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