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

במאמר הזה מוסבר איך לפתור בעיות בשרת המטא-נתונים של Compute Engine.

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

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

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

למידע על פתרון בעיות ב-gke-metadata-server, אפשר לעיין במאמר פתרון בעיות באימות GKE.

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

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

פתרון בעיות בקודי שרת

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

קודי שרת נפוצים

קודי השרת האלה מוחזרים לעיתים קרובות משרת המטא-נתונים.

קוד שרת תיאור פתרון
200 OK: הבקשה בוצעה בהצלחה לא רלוונטי
400 בקשה שגויה: סטטוס השגיאה הזה מוחזר בתרחישים שונים, למשל כשבקשה מכילה פרמטרים של שאילתה לא תקינים או כשלא מתקיימות הדרישות של נקודת הקצה הזו. בודקים את הודעת השגיאה כדי לקבל הצעות לפתרון השגיאה.
403 Forbidden: סטטוס השגיאה הזה מוחזר בתרחישים הבאים:
  • נקודת הקצה המבוקשת מושבתת בהגדרות של הפרויקט או של המופעים
  • הבקשה נכשלת בבדיקות האבטחה. הבעיה הזו יכולה לקרות אם חיבור ה-TCP שלכם לשרת נסגר בשכבת הרשת.
 צריך לבדוק את הגדרות הפרויקט והמופע כדי לוודא שנקודת הקצה מופעלת, או לבדוק את הגדרות הרשת.
404 לא נמצא: נקודת הקצה המבוקשת לא קיימת תיקון נתיב הבקשה
429 יותר מדי בקשות: הבעיה הזו מתרחשת כי חלק מנקודות הקצה משתמשות בהגבלת קצב כדי למנוע עומס יתר בשירות האחורי. מומלץ מאוד לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). מידע נוסף זמין ברשימת נקודות הקצה (endpoint) עם הגבלת קצב. ממתינים כמה שניות ומנסים להתקשר שוב.
503 השירות לא זמין: שרת המטא-נתונים לא מוכן להצגה. שרת המטא-נתונים עשוי להחזיר את קוד המצב Error 503 בכל אחת מהנסיבות הבאות: שגיאות 503 הן זמניות והן אמורות להיפתר תוך כמה שניות לכל היותר. כדי לפתור את הבעיה, מחכים כמה שניות ומנסים להתקשר שוב.

קודי שרת נדירים

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

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

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

קודי שגיאה של נקודות קצה שהוגדרה להן הגבלת קצב

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

נקודת קצה (endpoint) קוד סטטוס תיאור
oslogin/ 429 מגבלות הקצב של OS Login משותפות בין בקשות של משתמשים, הרשאות וקבוצות.
instance/service-accounts/identity 429 נקודת הקצה לחתימת הזהות מחזירה קוד תגובה 429 כדי לציין תגובה עם הגבלת קצב.
instance/service-accounts/default/token 429 אין הגבלת קצב על טוקנים ששמורים במטמון בשרת המטא-נתונים. אסימונים שלא נשמרו במטמון כפופים להגבלת קצב.
instance/guest-attributes/ 429, 503 יכול להיות שנחיל הגבלת קצב על בקשות למאפייני אורחים אם תחרגו מ-3 בקשות לשנייה או מ-10 בקשות לדקה. אם מתרחש ויסות, מוחזרים קודי השגיאה 429 או 503.

ניסיון נוסף להצגת ההדרכה

שרת המטא-נתונים מחזיר באופן שגרתי את קודי השגיאה 503 ו-429. כדי שהאפליקציות שלכם יהיו עמידות, מומלץ להטמיע לוגיקה של ניסיון חוזר באפליקציות שמבצעות שאילתות בשרת המטא-נתונים. מומלץ גם להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) בסקריפטים כדי להביא בחשבון אפשרות של הגבלת קצב.

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

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

curl: (6) Could not resolve host: metadata.google.internal

postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused

אם ל-VM אין יותר גישה לשרת המטא-נתונים, צריך לבצע את הפעולות הבאות:

Linux

  1. מתחברים ל-VM של Linux.

  2. במכונת ה-Linux הווירטואלית, מריצים את הפקודות הבאות כדי לבדוק את הקישוריות לשרת המטא-נתונים:

    1. שליחת שאילתה לשרת השמות של הדומיין:

      nslookup metadata.google.internal

      הפלט של מכונות וירטואליות שמשתמשות ב-IPv4 אמור להיראות כך:

      Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254

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

      ping -c 3 metadata.google.internal

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

      PING metadata.google.internal (169.254.169.254) 56(84) bytes of data.
64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms

      ping -c 3 169.254.169.254

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

      PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.
64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms

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

      ping -c 3 fd20:ce::254

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

      PING fd20:ce::254(fd20:ce::254) 56 data bytes
64 bytes from fd20:ce::254: icmp_seq=1 ttl=255 time=1.11 ms

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

      1. בודקים ששרת השמות מוגדר לשרת המטא-נתונים:

        cat /etc/resolv.conf

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

        domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

        אם הפלט לא כולל את השורות הקודמות, אפשר לעיין במסמכי התיעוד של מערכת ההפעלה כדי לקבל מידע על עריכת מדיניות ה-DHCP כדי לשמור את הגדרת שרת השמות ב-169.254.169.254. אם הגדרות DNS אזורי מוחלות על מכונות וירטואליות בפרויקט, השינויים ב-/etc/resolv.conf מוחלפים תוך שעה. אם הפרויקט שלכם עדיין משתמש ב-DNS גלובלי, קובץ resolv.conf יחזור ל-DHCP שמוגדר כברירת מחדל תוך 24 שעות.

      2. בודקים שקיימת מיפוי בין שם הדומיין של שרת המטא-נתונים לבין כתובת ה-IP שלו:

        cat /etc/hosts

        השורה הבאה צריכה להופיע בפלט:

        169.254.169.254 metadata.google.internal  # Added by Google

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

        echo "169.254.169.254 metadata.google.internal" >> /etc/hosts

Windows

  1. מתחברים ל-VM של Windows.

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

    1. שליחת שאילתה לשרת השמות של הדומיין:

      nslookup metadata.google.internal

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

      Server:  UnKnown
Address:  10.128.0.1

Non-authoritative answer:
Name:    metadata.google.internal
Address:  169.254.169.254

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

      ping -n 3 metadata.google.internal

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

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255


      ping -n 3 169.254.169.254

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

      Pinging 169.254.169.254 with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

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

      ping -n 3 fd20:ce::254

      הפלט של מכונות וירטואליות עם IPv6 אמור להיראות כך:

      Pinging fd20:ce::254 with 32 bytes of data:
Reply from fd20:ce::254: bytes=32 time=1ms TTL=255

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

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

        route print

        הפלט צריך לכלול את הפרטים הבאים:

        Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1

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

        $Adapters = Get-NetKVMAdapterRegistry
$FirstAdapter = $Adapters | Select-Object -First 1
route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1

      2. בודקים שהמיפוי בין שם הדומיין של שרת המטא-נתונים לבין כתובת ה-IP שלו קיים:

        type %WINDIR%\System32\Drivers\Etc\Hosts

        השורה הבאה צריכה להופיע בפלט:

        169.254.169.254 metadata.google.internal  # Added by Google

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

        echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts

פתרון בעיות שקשורות לבקשות שנכשלו במהלך השימוש בשרת proxy של רשת

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

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

אם לא מגדירים את ההגדרה NO_PROXY, יכול להיות שיופיעו שגיאות כשמריצים פקודות של Google Cloud CLI או כששולחים שאילתות ישירות לשרת המטא-נתונים, כי הקריאות ל-NO_PROXY יישלחו לפרוקסי בלי שהן יטופלו באופן מקומי במופע עצמו.metadata.google.internal

לדוגמה, יכול להיות שתופיע השגיאה הבאה:

ERROR 403 (Forbidden): Your client does not have permission to get URL

כדי לפתור את הבעיה עם ה-proxy, מוסיפים את שם המארח ואת כתובת ה-IP של שרת המטא-נתונים למשתנה הסביבה NO_PROXY באופן הבא:

Linux

  1. מתחברים ל-VM של Linux.

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

    export no_proxy=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal

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

    echo no_proxy=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal >> /etc/environment

Windows

  1. מתחברים ל-VM של Windows.

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

    set NO_PROXY=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal

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

    setx NO_PROXY 169.254.169.254,fd20:ce::254,metadata,metadata.google.internal /m

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

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

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

אישור לקוח שגוי

השגיאות הבאות מתרחשות אם מספקים ערך שגוי לדגל -E 

  • curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate
required, errno 0
  • curl: (58)  unable to set private key file:
  • curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory

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

שם מארח שגוי

השגיאה הבאה מתרחשת אם שם המארח שמשמש לגישה לשרת המטא-נתונים לא נמצא באישור.

curl: (60) SSL: no alternative certificate subject name matches target host name

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

אישור בסיס או אישור לקוח שגויים

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

curl: (77) error setting certificate verify locations:

מצב כזה יכול לקרות בתרחישים הבאים:

  • יכול להיות שהנתיב של הדגל --cacert לא תקין
  • יכול להיות שאישור הבסיס חסר במאגר האישורים המהימנים

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

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

user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \
    -E /run/google-mds-mtls/client.key \
    --cacert /run/google-mds-mtls/root.crt \
    -H "Metadata-Flavor: Google"

פתרון בעיות שקשורות לפורמט שגוי של כותרות

שרת המטא-נתונים מבצע בדיקות פורמט כדי לוודא שהכותרות עומדות בהנחיות לעיצוב כותרות RFC 7230 סעיף 3.2. אם פורמט הכותרת לא עובר את הבדיקות האלה, קורה אחד מהדברים הבאים:

  • הבקשה אושרה. עם זאת, תקבלו המלצות לגבי מכונות וירטואליות ששולחות בקשות לשרת המטא-נתונים עם כותרות בפורמט שגוי. ההמלצות נשלחות פעם אחת לכל מכונה וירטואלית. אפשר לגשת להמלצות האלה באמצעות Google Cloud CLI או Recommender API בארכיטקטורת REST.

    אחרי שמיישמים את ההמלצה, מגדירים את סטטוס ההמלצה לערך succeeded.

  • החל מ-20 בינואר 2024, שרת המטא-נתונים דוחה כל בקשה עם כותרת בפורמט שגוי.

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

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

Metadata-Flavor : Google

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

Metadata-Flavor: Google

תקין: אין רווחים בכותרת

Metadata-Flavor:Google

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

פתרון בעיות שקשורות לטוקן שלא ניתן להשיג

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

  • ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
  • curl: (22) The requested URL returned error: 401

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