פתרון בעיות ברישום צמתים

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

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

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

לפתרון בעיות באשכולות GKE Autopilot, אפשר לעיין במאמר פתרון בעיות באשכולות Autopilot.

מידע על רישום צמתים

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

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

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

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

  1. מספר הצמתים שמוגדר למאגר הצמתים משוכפל לקבוצות המופעים המנוהלות (MIG).
  2. קבוצות ה-MIG יוצרות את המספר הנדרש של מכונות וירטואליות.

  3. לכל מכונה וירטואלית שנוצרת:

    1. המכונה הווירטואלית מופעלת.
    2. המכונה הווירטואלית מגדירה ומתקינה את החבילות הנדרשות כדי לפעול כצומת Kubernetes.
    3. ה-kubelet שפועל עכשיו במכונה הווירטואלית מתקשר עם שרת ה-API של מישור הבקרה כדי להירשם כצומת.

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

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

  All cluster resources were brought up, but: only 0 nodes out of * have
  registered; this is likely due to the Nodes failing to start correctly; try
  re-creating the cluster or contact support if that doesn't work.

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

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

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

  • חיבור לרשת.
  • זמינות מקורות המידע.
  • הרשאות של חשבון שירות.

דרישות מוקדמות ליצירת מכונה

כש-GKE יוצר צומת לאשכול, השלב הראשון הוא יצירת מכונת VM חדשה ב-Compute Engine.

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

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

הרשאות של חשבון שירות

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

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

דרישות מוקדמות לחיבור רשת ל-Google APIs ולשירותים של Google

החבילות מורדות למופע של VM כדי להכין אותו להפעלה כצומת GKE, וזמן קצוב לתפוגה לחיבור יכול להיות סימן לכך שהאשכול לא עומד בדרישות הרישות שנדרשות כדי להתחבר ל-Google APIs ולשירותים של Google, כמו storage.googleapis.com. אם מופע לא יכול להתחבר לשירותים האלה, הוא לא יכול להוריד את הפצת Kubernetes ולהשלים את תהליך הרישום של הצומת.

בהתאם לחיבור הרשת שלכם, כדי לאפשר את החיבור הזה יכול להיות שתצטרכו להגדיר גישה פרטית ל-Google, או להגדיר כללי חומת אש ונתיבים ברשת הענן הווירטואלי הפרטי (VPC) של האשכול, שיאפשרו את החיבור.

דרישות מוקדמות לחיבור לרשת עם מישור הבקרה

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

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

שימוש בכלי לבדיקת רישום צמתים כדי לפתור בעיות ברישום צמתים

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

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

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

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

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

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

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

    כניסה לדף Logs Explorer

  2. כדי למצוא את היומנים של יצירת מכונת VM, משתמשים במסנן היומנים הבא:

    resource.type="gce_instance"
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.requestMetadata.callerSuppliedUserAgent="GCE Managed Instance Group for GKE"
protoPayload.response.status="RUNNING"

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

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

  4. לוחצים על אחד מהיומנים שמופיעים בקטע Query results ואז לוחצים על Expand nested fields כדי להציג פרטים נוספים.

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

    ‫gke-cluster-1-default-pool-b0ac62d3-9g1v הוא מופע של מאגר הצמתים default-pool ב-gke-cluster-1.

  6. נכנסים לדף VM instances של Compute Engine במסוף Google Cloud :

    כניסה לדף VM instances

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

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

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

בכרטיסייה Details של מכונת ה-VM, בקטע Logs, לוחצים על יציאה טורית 1 (console).

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

** Starting Node Registration Checker **
** Loading variables from kube-env **
** Sleeping for 7m to allow registration to complete  **

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

** Node ready and registered. **
** Completed running Node Registration Checker **

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

** Here is a summary of the checks performed: **

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

------------------------------
Service    DNS      Reachable
------------------------------
LOGGING    true     true
GCR        true     true
GCS        true     true
Master     N/A      false
------------------------------

אם LOGGING,‏ GCR או GCS מופיעים כבלתי ניתנים להשגה, כדאי לבדוק את הרשאות חשבון השירות לרישום צמתים וחיבור הרשת ל-Google APIs ולשירותים לרישום צמתים.

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

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

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

פתרון בעיות ברישום צמתים בלי הכלי לבדיקת רישום צמתים

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

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

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

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

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

  1. איתור מופע שבו נכשלה הרשמת הצומת

  2. בכרטיסייה Details של מופע מכונה וירטואלית, בקטע API and identity management, מוצאים את השם של חשבון השירות בשדה Service account. אם הצומת השתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, השם יהיה בפורמט PROJECT_NUMBER-compute@developer.gserviceaccount.com. לחשבון השירות הזה צריכות להיות ההרשאות המינימליות הנדרשות.

  3. בודקים אם יש אינדיקטורים להרשמה מוצלחת בפלט של המסוף הטורי. בכרטיסייה Details של מכונת ה-VM, בקטע Logs, לוחצים על יציאה טורית 1 (console).

    אם המופע השתמש בחשבון שירות עם ההרשאות הנכונות, הפלט כולל את הפרטים הבאים:

    • Started Download and install k8s binaries and configurations
    • Started Docker Application Container Engine.
    • Started Configure kubernetes node.
    • Reached target Kubernetes.

    ההודעות האלה יופיעו במקומות שונים בפלט הזה. יכול להיות שיופיעו בהם גם חותמות זמן או פריטים אחרים שיפריעו לצפייה, כמו בדוגמה הבאה: Starting [0;1;39mConfigure kubernetes node. אם אתם רואים את כל ההודעות האלה, סימן שחשבון השירות עומד בדרישות המוקדמות.

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

בדיקת החיבור לרשת לממשקי API ולשירותים של Google לצורך רישום הצומת

בדיקת החיבור באמצעות גישת SSH

אם יש לכם גישת SSH למכונות וירטואליות בפרויקט, אתם יכולים גם לבדוק אם למכונה הווירטואלית יש חיבור לרשת ל-Google APIs ולשירותים של Google.

  1. איתור מופע שבו נכשלה הרשמת הצומת

  2. בכרטיסייה פרטים של מכונת ה-VM, לוחצים על SSH.

  3. אחרי שמתחברים לשורת הפקודה של מכונת ה-VM, מריצים את הפקודה הבאה כדי לבדוק את החיבור ל-Google APIs ולשירותים של Google:

    curl -m 5 -v https://storage.googleapis.com/generate_204

    אם החיבור מצליח, הפלט דומה לזה:

    *   Trying 142.250.148.128:443...
* Connected to storage.googleapis.com (142.250.148.128) port 443 (#0)

...

< HTTP/1.1 204 No Content
< Content-Length: 0
< Cross-Origin-Resource-Policy: cross-origin
< Date: Wed, 04 Jan 2023 00:58:41 GMT
<
* Connection #0 to host storage.googleapis.com left intact

    אם החיבור לא מצליח, הפלט דומה לזה:

    *   Trying 142.250.148.128:443...
* Connection timed out after 5000 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5000 milliseconds

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

    משאירים את חיבור ה-SSH למופע של המכונה הווירטואלית פתוח ועוברים לקטע הבא.

בדיקת החיבור ללא גישת SSH באמצעות בדיקות קישוריות

אם אין לכם גישת SSH למכונות וירטואליות, תוכלו להשתמש בבדיקות קישוריות כדי לוודא שיש למכונה הווירטואלית חיבור ל-Google APIs ולשירותים של Google.

  1. איתור מופע שבו נכשלה הרשמת הצומת

  2. יוצרים ומריצים בדיקות קישוריות עם מופע מכונת ה-VM כמקור ו-storage.googleapis.com TCP/443 כיעד.

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

בדיקת החיבור לרשת עם מישור הבקרה לצורך רישום הצומת

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

  1. איתור מופע שבו נכשלה הרשמת הצומת

  2. בכרטיסייה פרטים של מכונת ה-VM, לוחצים על SSH.

  3. אחרי שמתחברים לשורת הפקודה של מכונת ה-VM, שומרים את נקודת הקצה של מישור הבקרה של האשכול כמשתנה סביבתי:

    source <(sudo grep KUBERNETES_MASTER_NAME /home/kubernetes/kube-env)

  4. שליחת בקשת GET לנקודת הקצה של מישור הבקרה:

    curl -k -m 5  https://${KUBERNETES_MASTER_NAME}/version

    אם הפלט דומה לזה שמופיע בהמשך, מכונת ה-VM יכולה ליצור חיבור למישור הבקרה:

    {
"major": "1",
"minor": "24",
"gitVersion": "v1.24.7-gke.900",
"gitCommit": "e35c4457f66187eff006dda6d2c0fe12144ef2ec",
"gitTreeState": "clean",
"buildDate": "2022-10-26T09:25:34Z",
"goVersion": "go1.18.7b7",
"compiler": "gc",
"platform": "linux/amd64"
}

    אם הפלט דומה לזה, מכונת ה-VM לא יכולה ליצור חיבור למישור הבקרה:

    curl: (28) Connection timed out after 5000 milliseconds

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

השלמת רישום הצומת אחרי תיקון שורש הבעיה

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

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

איסוף מידע לצורך בדיקה נוספת

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

  1. איתור מופע שבו נכשלה הרשמת הצומת

  2. איסוף מידע על תוצאות ניפוי הבאגים באמצעות sosreport.

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

     # Check cloud-init logs for issues during early VM boot
 sudo journalctl -u cloud-init-local --no-pager
 sudo journalctl -u cloud-init --no-pager
 sudo journalctl -u cloud-final --no-pager
 sudo journalctl -u cloud-config --no-pager

 # Check kubelet status and logs
 sudo systemctl status kubelet
 sudo journalctl -u kubelet --no-pager

 # Check GKE node installation service status and logs
 sudo systemctl status kube-node-installation.service
 sudo journalctl -u kube-node-installation.service --no-pager

 # Check GKE node configuration service status and logs
 sudo systemctl status kube-node-configuration.service
 sudo journalctl -u kube-node-configuration.service --no-pager

  3. אורזים את המידע הזה בקובץ ZIP ומצרפים אותו כששולחים בקשת תמיכה ל-Cloud Customer Care.

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