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

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

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

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

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

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

  • מפעילים את ממשק 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.
  7. לוחצים על Save.

gcloud

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

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

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

    12345678901
  2. מקצים את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine: 
    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 יש גם תמיכה בהקצאת צמתים אוטומטית (NAP), שמאפשרת לנהל באופן אוטומטי את מאגרי הצמתים באשכול על סמך דרישות ההתאמה לעומס.

שיטה מומלצת:

יוצרים חשבון שירות עם הרשאות מינימליות לניהול זהויות והרשאות גישה (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. לוחצים על הכרטיסייה Nodes.

  4. לוחצים על Create user-managed node pool (יצירת מאגר צמתים בניהול המשתמש).

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

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

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

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

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

Terraform

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

  • מוסיפים מאגר צמתים שמשתמש בחשבון השירות שמוגדר כברירת מחדל ב-IAM של 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 או hyperdisk-balanced, בהתאם לסדרת המכונות. אי אפשר להשתמש ב-hyperdisk-extreme או ב-hyperdisk-throughput כדיסקים לאתחול. מידע נוסף על הדיסקים שסדרות המכונות תומכות בהם זמין בטבלה השוואה בין סדרות מכונות.
  • ‫DISK_SIZE: הגודל של דיסקי האתחול של מכונות וירטואליות של צמתים ב-GB. ברירת המחדל היא 100GB.

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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