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

כשמריצים מאגרי צמתים של Windows Server ב-Google Kubernetes Engine‏ (GKE), יכולות להתרחש בעיות כמו הפעלה שנכשלה של Pods, שגיאות בשליפה של תמונות קונטיינר של Windows, בעיות בקישוריות לרשת או צמתים שלא מופעלים.

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

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

הנחיות כלליות נוספות זמינות במאמרי העזרה של Kubernetes בנושא ניפוי באגים ב-Pods ובשירותים.

בעיות בצומת של Containerd

אם אתם משתמשים בתמונת צומת של containerd, תוכלו לקרוא מידע על פתרון בעיות במאמר בעיות במאגרי צמתים של Windows Server.

הפעלת Windows Pods נכשלת

חוסר תאימות בין קובץ האימג' הבסיסי לבין גרסאות מערכת ההפעלה המארחת של Windows Server עלול למנוע את הפעלת ה-Pods.

תסמינים

  • הפעלת ה-Pods של Windows נכשלת.
  • הצומת מדווח על הסטטוס של NotReady.

מטרה

קובץ האימג' של הקונטיינר נוצר על בסיס קובץ אימג' ישן יותר של Windows שלא תואם לגרסת Windows Server של צומת המארח.

רזולוציה

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

שגיאות בשליפת תמונות

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

תסמינים

  • הודעות שגיאה כמו Failed to pull image או context cancelled.
  • ב-Pods מוצג הסטטוס ErrImagePull.

מטרה

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

רזולוציה

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

  • הגדלת המעבד (CPU) של הצומת: חילוץ הקונטיינר מתבצע במקביל בין ליבות, ולכן סוגי מכונות עם יותר ליבות מקטינים את זמן השליפה הכולל.
  • אופטימיזציה של שכבות תמונה: כדי לשפר את השמירה במטמון של שכבות Docker ולהגדיל את הסיכוי להצלחה של ניסיונות חוזרים למשיכת תמונה, כדאי לחלק את שכבות האפליקציה לשכבות קטנות יותר. מידע נוסף זמין במאמר Images and layers במאמרי העזרה בנושא מנהל האחסון של Docker.
  • שימוש במשיכות ידניות: מתחברים לצמתים של Windows Server ומריצים ידנית את הפקודה docker pull בקובצי אימג' של קונטיינרים לפני שיוצרים את ה-Pods.

עצות כלליות נוספות זמינות במאמר בנושא פתרון בעיות בשליפת תמונות.

הגענו לסוף חיי המוצר של משפחת התמונות

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

תסמינים

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

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

מטרה

משפחת תמונות Windows Server שנבחרה לא נתמכת יותר ב-GKE.

רזולוציה

בוחרים תמונת Windows שזמינה ונתמכת. כדי לראות את תאריך סיום התמיכה בתמונות של צמתים ב-Windows ב-GKE, אפשר להשתמש בפקודה gcloud container get-server-config כמו שמתואר במאמר מיפוי גרסאות של GKE ו-Windows.

זמן קצוב לתפוגה במהלך יצירת מאגר הצמתים

הפעלת מספר גדול של צמתים של Windows Server בו-זמנית עלולה לגרום לפסק זמן.

תסמינים

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

מטרה

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

רזולוציה

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

צמתי Windows הופכים ל-NotReady עם השגיאה: PLEG is not healthy

תזמון מהיר של כמה קונטיינרים של Windows בצומת יחיד עלול להעמיס יתר על המידה על Pod Lifecycle Event Generator ‏ (PLEG).

תסמינים

  • צמתים של Windows עוברים לסטטוס NotReady.
  • מוצגת הודעת השגיאה PLEG is not healthy באירועים או ביומנים.

מטרה

מתרחשת בעיה מוכרת ב-Kubernetes כשמפעילים כמה יחידות Pod במהירות רבה בצומת Windows יחיד.

רזולוציה

כדי להתאושש מכשלים ב-PLEG ולמנוע הישנות שלהם:

  • מפעילים מחדש את צומת Windows Server המושפע.
  • הגבלת יצירת Windows Pod כך שלא ייווצר יותר מ-Pod אחד כל 30 שניות.

לא עקבי TerminationGracePeriod

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

תסמינים

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

מטרה

הזמן הקצוב לתפוגה של מערכת Windows הפנימית עבור הקונטיינר שונה מתקופת החסד שצוינה במניפסט של Kubernetes Pod.

רזולוציה

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

בעיות בחיבור לרשת

אי התאמה בגודל של יחידת השידור המקסימלית (MTU) בין רשתות של קונטיינר Windows Server לבין רשתות Google Cloud יכולה לגרום להשמטת חבילות.

תסמינים

אפליקציות שפועלות בתוך קונטיינרים של Windows Server נתקלות בכשלים בקישוריות לרשת או באיבוד מנות.

מטרה

בדרך כלל, רשתות של מאגרי תגים בצד השרת ב-Windows Server מניחות שערך ה-MTU של הרשת הוא 1500, וזה לא תואם לערך ה-MTU של Google Cloudשהוא 1460.

רזולוציה

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

בעיות בהפעלה של צומת

יכול להיות שסקריפטים של אתחול לא יושלמו במופעים חדשים של Windows Server, או שהם לא יירשמו במישור הבקרה.

תסמינים

האתחול של צמתי Windows Server נכשל או שהם לא מצטרפים לאשכול.

מטרה

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

רזולוציה

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

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

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

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

באשכולות שמופעלת בהם גרסה 1.24 או גרסה מוקדמת יותר, הפעלה מחדש של רכיב kube-proxy יוצרת עיכובים זמניים בניתוב ברשת בזמן שכללי איזון העומסים של Host Network Service ‏(HNS) עוברים עיבוד מחדש.

תסמינים

אי אפשר להגיע לשירותים לסירוגין מ-Pods שפועלים בצמתי Windows.

מטרה

ב-GKE clusters שפועלת בהם גרסה 1.24 או גרסה קודמת, אם אירוע מפעיל מחדש את הרכיב kube-proxy בצומת Windows – לדוגמה, הפעלה של צומת, שדרוג של צומת או הפעלה מחדש ידנית – הרכיב צריך לסנכרן וליצור מחדש את כל הכללים של HNS Load Balancer. אם באשכול יש מספר גבוה של כללים כאלה, יכול להיות שיהיה עיכוב משמעותי בעיבוד שלהם, שנמשך כ-30 שניות לכל כלל. במהלך העיכוב בסנכרון, אי אפשר להגיע לשירותים לסירוגין מ-Pods שפועלים בצומת הזה. מידע נוסף אפשר למצוא בבעיה המקורית ב-GitHub.

רזולוציה

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

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