פתרון בעיות בשדרוג אשכולות

טייס אוטומטי רגילה

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

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

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

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

מעקב אחר תהליך השדרוג של האשכול

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

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

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

בקטעים הבאים מוסבר איך להריץ שאילתות על היומנים האלה באמצעות Logs Explorer או ה-CLI של gcloud. מידע נוסף זמין במאמר בנושא בדיקת יומני שדרוג.

זיהוי פעולת השדרוג באמצעות יומני ביקורת

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

סוג אירוע	שאילתה ביומן
שדרוג אוטומטי של מישור הבקרה	resource.type="gke_cluster" protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal" log_id("cloudaudit.googleapis.com/activity") protoPayload.metadata.operationType="UPGRADE_MASTER" resource.labels.cluster_name="`CLUSTER_NAME`" מחליפים את `CLUSTER_NAME` בשם של האשכול שרוצים לבדוק. בשליחה של השאילתה הזו מוצגת גרסת מישור הבקרה של היעד וגרסת מישור הבקרה הקודמת.
שדרוג ידני של מישור הבקרה	resource.type="gke_cluster" log_id("cloudaudit.googleapis.com/activity") protoPayload.response.operationType="UPGRADE_MASTER" resource.labels.cluster_name="`CLUSTER_NAME`"
שדרוג אוטומטי של מאגר צמתים (גרסת יעד בלבד)	resource.type="gke_nodepool" protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal" log_id("cloudaudit.googleapis.com/activity") protoPayload.metadata.operationType="UPGRADE_NODES" resource.labels.cluster_name="`CLUSTER_NAME`" resource.labels.nodepool_name="`NODEPOOL_NAME`" מחליפים את `NODEPOOL_NAME` בשם של מאגר הצמתים ששייך לאשכול.
שדרוג ידני של מאגר צמתים	resource.type="gke_nodepool" protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool" log_id("cloudaudit.googleapis.com/activity") protoPayload.response.operationType="UPGRADE_NODES" resource.labels.cluster_name="`CLUSTER_NAME`" resource.labels.nodepool_name="`NODEPOOL_NAME`" כדי למצוא את הגרסה הקודמת של מאגר הצמתים, בודקים את היומנים של Kubernetes API: resource.type="k8s_cluster" resource.labels.cluster_name="`CLUSTER_NAME`" protoPayload.methodName="nodes.patch"

איך מוצאים הודעות שגיאה מפורטות ביומני GKE

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

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

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

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

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

שימוש ב-CLI של gcloud כדי להציג אירועי שדרוג

בנוסף ל-Logs Explorer, אפשר להשתמש בפקודות של ה-CLI של gcloud כדי לבדוק אירועי שדרוג.

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

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

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

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

הפלט הזה כולל את הערכים הבאים:

‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
‫CLUSTER_NAME: השם של האשכול.

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

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

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

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

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

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

נכנסים לדף Logs Explorer במסוף Google Cloud .

כניסה לדף Logs Explorer
בחלונית השאילתה, מסננים את היומנים של שדרוג מישור הבקרה על ידי הזנת השאילתה הבאה:
```
resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"
```
מחליפים את CLUSTER_NAME בשם של האשכול שרוצים לבדוק.
לוחצים על Run query.
בודקים את פלט היומן כדי לראות את המידע הבא:
מוודאים שהשדרוג התחיל: מחפשים אירועים אחרונים UPGRADE_MASTER בסביבות הזמן שבו התחלתם את השדרוג. הנוכחות של האירועים האלה מאשרת שאתם או GKE הפעלתם את תהליך השדרוג.
- מאמתים את הגרסאות: בודקים את השדות הבאים כדי לוודא מהן הגרסה הקודמת וגרסת היעד:
  - ‫protoPayload.metadata.previousMasterVersion: מציג את גרסת מישור הבקרה לפני השדרוג.
  - ‫protoPayload.metadata.currentMasterVersion: הגרסה שאליה GKE ניסה לשדרג את מישור הבקרה.
    
    לדוגמה, אם התכוונתם לשדרג לגרסה 1.30.1-gke.1234 אבל בטעות ציינתם 1.30.2-gke.4321 (גרסה חדשה יותר, שאולי לא תואמת לעומסי העבודה שלכם), בדיקה של שני השדות האלה תדגיש את הפער הזה. לחלופין, אם השדה currentMasterVersion עדיין מציג את הגרסה הקודמת אחרי תקופה ממושכת, הממצא הזה מצביע על כך שהשדרוג לא הצליח להחיל את הגרסה החדשה.
- מחפשים שגיאות: בודקים אם יש אירועים חוזרים של UPGRADE_MASTER או הודעות שגיאה אחרות. אם יומן הפעולות מפסיק בלי לציין שהפעולה הושלמה או נכשלה, זה מצביע על בעיה.

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

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

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

בודקים את הערך של terminationGracePeriodSeconds במניפסט של ה-Pods. הערך הזה מגדיר את משך הזמן המקסימלי שבו Kubernetes מחכה ש-Pod ייסגר בצורה מסודרת. ערך גבוה (לדוגמה, כמה דקות) יכול להאריך באופן משמעותי את משך השדרוג, כי Kubernetes מחכה לפרק הזמן המלא לכל Pod. אם העיכוב הזה גורם לבעיות, כדאי להקטין את הערך.
בודקים את האובייקטים של PodDisruptionBudget. כשמבצעים ניקוי של צומת, GKE ממתין לכל היותר שעה לכל צומת כדי להוציא את עומסי העבודה שלו בצורה מסודרת. אם האובייקט PodDisruptionBudget מגביל מדי, הוא יכול למנוע את ההצלחה של פינוי תקין. בתרחיש הזה, מערכת GKE משתמשת בכל תקופת החסד של שעה אחת כדי לנסות לנקז את הצומת לפני שחלף הזמן והשדרוג נכפה. העיכוב הזה, כשחוזר על עצמו בכמה צמתים, הוא סיבה נפוצה לשדרוג איטי של האשכול כולו. כדי לבדוק אם אובייקט מגביל PodDisruptionBudget הוא הסיבה לשדרוגים איטיים, משתמשים ב-Logs Explorer:
1. נכנסים לדף Logs Explorer במסוף Google Cloud .
  
  כניסה לדף Logs Explorer
2. בחלונית השאילתה, מזינים את השאילתה הבאה:
```
resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")
```
3. לוחצים על Run query.
4. בודקים את פלט היומן. אם האובייקט PodDisruptionBudget הוא הגורם לבעיה, הפלט ייראה כך:
```
resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}
```
5. אחרי שמוודאים שאובייקט PodDisruptionBudget הוא הגורם, צריך לרשום את כל האובייקטים PodDisruptionBudget ולוודא שההגדרות מתאימות:
```
kubectl get pdb --all-namespaces
```
  הפלט אמור להיראות כך:
```
NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d
```
  בדוגמה הזו, ל-PodDisruptionBudget שנקרא one_pdb נדרשים לפחות שלושה פודים זמינים. הוצאת Pod במהלך השדרוג תשאיר רק שני Pods זמינים, ולכן הפעולה הזו חורגת מהתקציב וגורמת לעצירה של השדרוג.
  
  אם אובייקט PodDisruptionBudget פועל כמו שרוצים, לא צריך לבצע שום פעולה. אם לא, כדאי להגדיר את ההגדרות של PodDisruptionBudget בצורה פחות מחמירה במהלך חלון השדרוג.
בודקים את ההעדפות של הצומת. כללים מגבילים עלולים להאט את השדרוגים כי הם מונעים את התזמון מחדש של ה-Pods בצמתים זמינים אם הצמתים האלה לא תואמים לתוויות הנדרשות. הבעיה הזו משמעותית במיוחד במהלך שדרוגים של עליות תנועה, כי זיקות של צמתים יכולות להגביל את מספר הצמתים שאפשר לשדרג בו-זמנית אם לצמתים עם התוויות הנכונות אין מספיק קיבולת של אשכול כדי לארח את ה-Pods החדשים.
בודקים אם אתם משתמשים באסטרטגיית שדרוג לזמן קצר. ב-GKE נעשה שימוש באסטרטגיית שדרוג לזמן קצר לצמתים עם הפעלה גמישה ולצמתים שמשתמשים רק בהקצאת משאבים בתור באשכולות שמריצים את גרסה GKE 1.32.2-gke.1652000 ואילך. אם משתמשים בשיטת השדרוג הזו, פעולת השדרוג יכולה להימשך עד שבעה ימים.
בודקים אם אתם משתמשים בתאי Pod עם משך זמן ממושך (זמין באשכולות Autopilot). במהלך שדרוג, מערכת GKE צריכה לרוקן את כל ה-Pods מצומת לפני שהתהליך מסתיים. עם זאת, במהלך שדרוג שמתחיל ב-GKE,‏ GKE לא מפנה Pods עם משך זמן ממושך למשך עד שבעה ימים. ההגנה הזו מונעת את הניקוז של הצומת. ‫GKE יסיים את הפוד בכוח רק אחרי שהתקופה הזו תסתיים, והעיכוב המשמעותי הזה של כמה ימים בצומת יחיד עלול לעכב שדרוגים של צמתים נוספים באשכול Autopilot.
נפחים מתמידים שמצורפים יכולים לגרום לתהליך השדרוג להימשך זמן רב יותר מהרגיל, בגלל הזמן שנדרש לניהול מחזור החיים של הנפחים האלה.
בודקים את סטטוס השדרוג האוטומטי של האשכול. אם הסיבה היא SYSTEM_CONFIG, השדרוגים האוטומטיים מושהים זמנית מסיבות טכניות או עסקיות. אם הסיבה הזו מופיעה, אנחנו ממליצים לא לבצע שדרוג ידני אלא אם יש בכך צורך.

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

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

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

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

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

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

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

מידע נוסף על האופן שבו פעולות ספציפיות פועלות עם מדיניות תחזוקה זמין בעמודות Respects maintenance policies בטבלאות שבמאמר Types of changes to a GKE cluster.

פתרון בעיות בהתנהגות לא צפויה של שדרוג אוטומטי

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

שדרוג אשכולות נכשל כשהשדרוג האוטומטי מופעל
שדרוג אוטומטי של אשכולות כששדרוג אוטומטי לא מופעל

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

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

אם אתם משתמשים בערוץ הפצה, אתם צריכים לוודא ששדרוגים אוטומטיים של הצמתים לא חסומים. באשכולות שרשומים בערוץ הפצה, maintenancePolicy היא הדרך העיקרית לשלוט בשדרוגים אוטומטיים. היא יכולה למנוע את תחילת השדרוג או להפריע לשדרוג שכבר מתבצע. החרגה פעילה של תחזוקה עלולה לחסום שדרוג לחלוטין, והתזמון של חלון תחזוקה עלול לגרום להפרעה. כדאי לבדוק את maintenancePolicy כדי לראות אם אחת מההגדרות האלה היא הסיבה לבעיה:
```
gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול של מאגר הצמתים שרוצים לתאר.
- ‫PROJECT_ID: מזהה הפרויקט של האשכול.
- ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
הפלט אמור להיראות כך:
```
…
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…
```
בפלט, בודקים את הקטע maintenancePolicy כדי לראות אם מתקיימים שני התנאים הבאים:
- כדי לבדוק אם השדרוג חסום: מחפשים מינוי פעיל maintenanceExclusion עם היקף NO_MINOR_OR_NODE_UPGRADES. ההגדרה הזו בדרך כלל מונעת מ-GKE להתחיל שדרוג חדש.
- כדי לראות אם השדרוג הופסק: בודקים את לוח הזמנים של dailyMaintenanceWindow או maintenanceExclusions. אם השדרוג נמשך מעבר לחלון הזמן המתוזמן, GKE משהה את השדרוג, וכתוצאה מכך מתבצע שדרוג חלקי. מידע נוסף על שדרוגים חלקיים זמין בקטע פתרון בעיות בשדרוגים לא מלאים.
כדי לפתור את הבעיות האלה, אפשר לחכות עד לסיום ההחרגה, להסיר אותה או לשנות את חלונות התחזוקה כדי לאפשר יותר זמן להשלמת השדרוגים.
אם אתם לא משתמשים בערוץ הפצה, צריך לוודא שהשדרוג האוטומטי עדיין מופעל עבור מאגר הצמתים:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION
```
מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים שרוצים לתאר.

אם ההגדרה node pool auto-upgrades (שדרוגים אוטומטיים של מאגר הצמתים) מופעלת במאגר הצמתים הזה, הפלט בשדה autoUpgrade הוא:
```
management:
  autoUpgrade: true
```
אם הערך של autoUpgrade הוא false, או אם השדה לא קיים, צריך להפעיל שדרוגים אוטומטיים.
יכול להיות שהשדרוג לא הושק באזור או באזור הזמינות שבהם נמצא האשכול שלכם, גם אם השדרוג הוזכר בהערות לגבי הגרסה. שדרוגים של GKE מושקים בהדרגה במשך כמה ימים (בדרך כלל ארבעה ימים או יותר). אחרי שהשדרוג יגיע לאזור או לאזור הזמינות שלכם, הוא יתחיל רק במהלך חלונות הזמנים המאושרים לתחזוקה. לדוגמה, פריסה יכולה להגיע לאזור של האשכול ביום הראשון של הפריסה, אבל חלון התחזוקה הבא של האשכול הוא רק ביום השביעי. בתרחיש הזה, מערכת GKE לא תשדרג את האשכול עד היום השביעי. מידע נוסף זמין במאמר בנושא לוח הזמנים של מהדורות GKE.

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

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

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

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

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

פתרון בעיות בשדרוגים שנכשלו

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

שגיאה: kube-apiserver לא תקין
שגיאה: DeployPatch נכשל

שגיאה: `kube-apiserver` לא תקין

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

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

ההודעה הזו מופיעה ב-CLI של gcloud וברשומות ביומן של סוגי המשאבים gke_cluster ו-gke_nodepool.

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

במהלך שדרוג של מישור הבקרה, GKE יוצר מחדש את רכיב שרת ה-API של Kubernetes‏ (kube-apiserver). אם ה-webhook חוסם את תפקיד ה-RBAC עבור רכיב שרת ה-API, שרת ה-API לא יופעל ושדרוג האשכול לא יושלם. גם אם ה-webhook פועל בצורה תקינה, הוא עלול לגרום לשדרוג האשכול להיכשל כי יכול להיות שלמישור הבקרה שנוצר לא תהיה גישה ל-webhook.

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

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

כדי לזהות את ה-webhook שנכשל, בודקים את יומני הביקורת של GKE לגבי קריאות RBAC עם המידע הבא:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

בפלט הזה, RBAC_RULE הוא השם המלא של תפקיד ה-RBAC, למשל rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

שם ה-webhook שנכשל מוצג ביומן בפורמט הבא:

admission webhook WEBHOOK_NAME denied the request

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

בודקים את ClusterRoles כדי לוודא שהם לא מגבילים מדי. הכללים שלכם לא צריכים לחסום את הבקשות של GKE ליצור או לעדכן את ClusterRoles עם הקידומת system: שמוגדרת כברירת מחדל.
משנים את ה-webhook כך שלא ייחתו בקשות ליצירה ולעדכון של תפקידי RBAC במערכת.
משביתים את ה-webhook.

שגיאה: DeployPatch נכשל

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

DeployPatch failed

השגיאה הזו יכולה לקרות אם מישור הבקרה של Kubernetes נשאר לא תקין במשך יותר מ-20 דקות.

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

פתרון בעיות אחרי שדרוג שהושלם

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

התנהגות לא צפויה בגלל שינויים שגורמים לבעיות
עומסי עבודה שהוצאו אחרי שדרוג של אשכול רגיל
Pods תקועים במצב Pending
השימוש במעבד (CPU) של הצומת גבוה מהצפוי

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

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

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

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

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

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

‫Pods תקועים במצב `Pending` אחרי הגדרת Node Allocatable

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

אם הסטטוס של ה-Pods הוא Pending אחרי שדרוג, נסו את הפתרונות הבאים:

מוודאים שהבקשות ל-CPU ולזיכרון עבור ה-Pods לא חורגות משיא השימוש שלהם. ‫GKE שומר CPU וזיכרון לתקורה, ולכן Pods לא יכולים לבקש את המשאבים האלה. אם פודים מבקשים יותר משאבי מעבד (CPU) או זיכרון ממה שהם משתמשים בפועל, הם מונעים מפודים אחרים לבקש את המשאבים האלה, ועלולים לגרום לניצול חלקי של האשכול. מידע נוסף זמין במאמר How Pods with resource requests are scheduled (איך מתזמנים פודים עם בקשות למשאבים) במסמכי התיעוד של Kubernetes.
מומלץ להגדיל את גודל האשכול.
כדי לבדוק אם השדרוג הוא הגורם לבעיה, חזור לגרסה קודמת של מאגרי הצמתים.
מגדירים את האשכול כך שמדדי מתזמן Kubernetes יישלחו אל Cloud Monitoring, ואז צופים במדדי המתזמן. מעקב אחרי המדדים האלה מאפשר לכם לקבוע אם יש מספיק משאבים להפעלת ה-Pods.

פתרון בעיות שקשורות לגרסה ולתאימות

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

בדיקה של חוסר תאימות בין מישור הבקרה לבין גרסת הצומת

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

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

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

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

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

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

‫CLUSTER_NAME: השם של האשכול של מאגר הצמתים שרוצים לתאר.
‫PROJECT_ID: מזהה הפרויקט של האשכול.
‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.

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

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

בדוגמה הזו, הגרסה של מישור הבקרה לא תואמת לגרסה של מאגר הצמתים.

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

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

יוצרים מאגר צמתים חדש עם גרסה תואמת.
מבודדים את הצמתים במאגר הצמתים הקיים.
אופציונלי: מעדכנים את עומסי העבודה שפועלים במאגר הצמתים הקיים כדי להוסיף nodeSelector לתווית cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. מחליפים את NEW_NODE_POOL_NAME בשם של מאגר הצמתים החדש. הפעולה הזו מבטיחה ש-GKE יציב את עומסי העבודה האלה בצמתים במאגר הצמתים החדש.
מרוקנים את מאגר הצמתים הקיים.
בודקים שעומסי העבודה פועלים בהצלחה במאגר הצמתים החדש. אם כן, אפשר למחוק את מאגר הצמתים הישן. אם מבחינים בשיבושים בעומסי העבודה, מתזמנים מחדש את עומסי העבודה בצמתים הקיימים על ידי ביטול ההסגר של הצמתים במאגר הצמתים הקיים וריקון הצמתים החדשים.

השימוש במעבד (CPU) של הצומת גבוה מהצפוי

יכול להיות שתיתקלו בבעיה שבה חלק מהצמתים משתמשים ביותר CPU מהצפוי מה-Pods הפועלים.

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

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

אם לא מצאתם פתרון לבעיה שלכם במסמכים, תוכלו להיעזר בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
- פתיחת באגים או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.

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

מעקב אחר תהליך השדרוג של האשכול

זיהוי פעולת השדרוג באמצעות יומני ביקורת

איך מוצאים הודעות שגיאה מפורטות ביומני GKE

שימוש ב-CLI של gcloud כדי להציג אירועי שדרוג

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

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

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

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

פתרון בעיות בהתנהגות לא צפויה של שדרוג אוטומטי

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

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

פתרון בעיות בשדרוגים שנכשלו

שגיאה: kube-apiserver לא תקין

שגיאה: DeployPatch נכשל

פתרון בעיות אחרי שדרוג שהושלם

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

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

‫Pods תקועים במצב Pending אחרי הגדרת Node Allocatable

פתרון בעיות שקשורות לגרסה ולתאימות

בדיקה של חוסר תאימות בין מישור הבקרה לבין גרסת הצומת

השימוש במעבד (CPU) של הצומת גבוה מהצפוי

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

פתרון בעיות בשדרוג אשכולות

שגיאה: `kube-apiserver` לא תקין

‫Pods תקועים במצב `Pending` אחרי הגדרת Node Allocatable