פתרון בעיות ב-Cloud Run

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

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

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

בקטעים הבאים מוסבר איך לפתור בעיות ב-Cloud Run:

שגיאות בפריסה

בקטע הזה מתוארות שגיאות פריסה נפוצות ב-Cloud Run ושיטות לפתרון הבעיות.

הפעלת הקונטיינר נכשלה

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

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

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

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

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

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

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

  5. משתמשים ב-Cloud Logging כדי לחפש שגיאות באפליקציה ביומנים של stdout או של stderr. אפשר גם לחפש קריסות שתועדו ב-Error Reporting.

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

שגיאה בייבוא מאגר התגים

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

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

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

  1. צריך לוודא שמערכת הקבצים של הקונטיינר לא מכילה תווים שהם לא UTF-8.

  2. בחלק מקובצי האימג' של Docker שמבוססים על Windows נעשה שימוש בשכבות זרות. מישור הבקרה של Cloud Run לא תומך בשכבות חיצוניות. כדי לפתור את הבעיה, נסו להגדיר את הדגל --allow-nondistributable-artifacts בדמון של Docker.

התכונה לא נתמכת

השגיאה הבאה מתרחשת כששולחים קריאה ל-Cloud Run Admin API:

The feature is not supported in the declared launch stage

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

כדי לפתור את הבעיה, צריך להוסיף את השדה launch stage לבקשות.

בדוגמאות הבאות מוסבר איך להוסיף הפניות לשלב ההשקה כשמשתמשים ב-API בארכיטקטורת REST בגרסה 1 או בגרסה 2:

המשתמש root לא נמצא

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

ERROR: "User \"root\""not found in /etc/passwd

כדי לפתור את הבעיה, צריך לציין את USER 0 במקום את USER root בקובץ Docker.

חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine נמחק

השגיאה הבאה מתרחשת במהלך הפריסה:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@ (or it may not exist).

הבעיה הזו מתרחשת באחד מהמקרים הבאים:

כדי לפתור את הבעיה:

  1. מציינים חשבון שירות באמצעות הדגל --service-account:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

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

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

  1. נכנסים לדף Permissions של ניהול זהויות והרשאות גישה (IAM) במסוף Google Cloud :

    לדף ההרשאות

  2. מסמנים את התיבה Include Google-provided role grants.

  3. ברשימה Principals, מאתרים את המזהה של סוכן השירות של Compute Engine, שמופיע בפורמט PROJECT_NUMBER-compute@.

בעיות בחשבון השירות של Cloud Build

השגיאה הבאה מתרחשת במהלך פריסות מקור כשאין לחשבון השירות של Cloud Build את ההרשאות הנדרשות או כשהוא מושבת:

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

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

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

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

  • מקצים את התפקיד Cloud Run Builder ‏(roles/run.builder) לחשבון השירות של ה-build.

לסוכן השירות של Cloud Run אין הרשאה לקרוא את קובץ האימג'

השגיאה הבאה מתרחשת כשמנסים לפרוס מפרויקט באמצעות קובץ אימג' שמאוחסן ב-Artifact Registry, באמצעות הדומיין gcr.io בפרויקט אחר:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

יכול להיות שתוצג גם השגיאה הבאה כשמנסים לפרוס מפרויקט באמצעות קובץ אימג' שמאוחסן ב-Artifact Registry בפרויקט אחר:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

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

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

  • הבעיה הזו יכולה לקרות גם אם הפרויקט נמצא בגבולות הגזרה של VPC Service Controls, עם הגבלה על Cloud Storage API שאוסרת על בקשות מסוכן השירות של Cloud Run. כדי לפתור את הבעיה:

    1. פותחים את Logs Explorer במסוף Google Cloud . (אל תשתמשו בדף Logs שבתוך הדף Cloud Run):

      כניסה לדף Logs Explorer

    2. מזינים את הטקסט הבא בשדה השאילתה:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod."

    3. אם מופיעות רשומות ביומן אחרי השימוש בשאילתה הזו, צריך לבדוק את הרשומות ביומן כדי לקבוע אם צריך לעדכן את כללי המדיניות של VPC Service Controls. יכול להיות שהם יציינו שצריך להוסיף את service-PROJECT_NUMBER@serverless-robot-prod. למדיניות גישה קיימת.

חסרות הרשאות לפריסות של מקורות

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

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

כל שירות Cloud Run משויך לחשבון שירות שמשמש כזהות שלו כשהשירות ניגש למשאבים אחרים. חשבון השירות הזה יכול להיות חשבון השירות שמוגדר כברירת מחדל (PROJECT_NUMBER-compute@) או חשבון שירות בניהול המשתמשים.

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

כדי לפתור את הבעיה, צריך להקצות לחשבון הפריסה את התפקיד משתמש בחשבון שירות (roles/iam.serviceAccountUser) בחשבון השירות שמשמש כזהות השירות. התפקיד המוגדר מראש הזה כולל את ההרשאה iam.serviceAccounts.actAs, שנדרשת כדי לצרף חשבון שירות לשירות או לגרסה. משתמש שיוצר חשבון שירות שמנוהל על ידי משתמש מקבל באופן אוטומטי את ההרשאה iam.serviceAccounts.actAs, אבל משתמשים אחרים שמבצעים פריסה צריכים לקבל את ההרשאה הזו מהמשתמש שיוצר את חשבון השירות שמנוהל על ידי משתמש.

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

למשתמש אין מספיק הרשאות כדי להשלים פריסות של מקורות

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

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

כדי לפתור את השגיאה, צריך לבקש מהאדמין להקצות לכם את התפקידים הבאים בניהול זהויות והרשאות גישה (IAM):

שגיאה בפריסת שירות Cloud Run מפרויקטים אחרים של Google Cloud

השגיאה הבאה מתרחשת כשפורסים שירות Cloud Run מפרויקט מקור לפרויקט יעד:

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

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

  1. מקצים את התפקיד משתמש בחשבון שירות (roles/iam.serviceAccountUser) בחשבון השירות שמשמש כזהות השירות בפרויקט היעד.

  2. מקצים את התפקיד יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) לחשבון השירות של Cloud Run בפרויקט היעד. מוסיפים את כתובת האימייל של סוכן השירות של Cloud Run‏ (service-PROJECT_NUMBER@SERVICE_DOMAIN.) בתור החשבון הראשי מפרויקט המקור.

  3. משביתים את מדיניות הארגון iam.disableCrossProjectServiceAccountUsage.

הוראות מפורטות זמינות במאמר הגדרת זהות שירות לשירותים.

שגיאות בפריסה של קוד המקור ב-Python ב-Cloud Run

כשפורסים שירות Cloud Run מקוד מקור עם סביבת זמן הריצה של Python, מתרחשת אחת מהשגיאות הבאות:

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • הפריסה מצליחה עם קודי שגיאה HTTP 500 ביומנים.

ה-buildpack של Python מגדיר את נקודת הכניסה שמוגדרת כברירת מחדל לפריסות של קוד מקור ב-Cloud Run. בגרסה 3.13 ומעלה של Python, ה-buildpack של Python מגדיר את נקודת הכניסה על סמך הגדרת שירות האינטרנט בקובץ requirements.txt. אם לא מציינים שרת אינטרנט או מסגרת בקובץ requirements.txt, או אם משתמשים בגרסת Python 3.12 ומטה, ה-buildpack של Python מגדיר את נקודת הכניסה שמוגדרת כברירת מחדל ל-gunicorn -b :8080 main:app. מידע נוסף זמין במאמר פיתוח אפליקציה ב-Python.

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

  • gunicorn:

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • ‫fastapi ו-uvicorn:

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

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

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

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

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

    • ‫SERVICE: שם השירות שרוצים לפרוס.
    • ‫ENTRYPOINT: נקודת הכניסה שרוצים להשתמש בה כברירת מחדל לקוד המקור.

  • משתמשים ב-Procfile כדי להגדיר נקודת כניסה.

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

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

הגרסה לא קיימת או שהיא נמחקה

הבעיה הבאה מתרחשת כשמעדכנים את תנועת השירות:

Revision REVISION_NAME does not exist or is deleted

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

  • באמצעות ה-CLI: מריצים את gcloud run services update-traffic <var>SERVICE_NAME</var> --to-latest או מקצים מחדש באופן מפורש את תגי התנועה לגרסה קיימת ופעילה.
  • באמצעות מסוף Google Cloud : נכנסים לשירות, עוברים לכרטיסייה Revisions ועורכים את הקצאת התנועה כדי להסיר את התג שמפנה לגרסה שנמחקה.

‫HTTP 404: לא נמצא

הבעיה הבאה מתרחשת במהלך הצגת המודעות:

`HTTP 404`:Not found

יכול להיות שתיתקלו בשגיאות HTTP 404 בתרחישים הבאים:

  1. כתובת URL שגויה של בקשה או קוד אפליקציה שגוי מחזירים שגיאות מסוג 404. כדי לפתור את הבעיה, צריך לבצע את השלבים הבאים:

    1. בודקים אם כתובת ה-URL שביקשתם נכונה. אפשר לאמת את כתובת ה-URL בדף פרטי השירות במסוף Google Cloud או על ידי הפעלת הפקודה הבאה:

      gcloud run services describe SERVICE_NAME | grep URL

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

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

  2. הבקשה לא מגיעה לקונטיינר, ומובילה לשגיאה 404 בתרחישים הבאים:

    בשני התרחישים האלה, אי אפשר למצוא את השגיאה 404 ב-Cloud Logging, גם כשמפעילים את המסנן הבא:

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. עם אותן הגדרות של תעבורת נתונים נכנסת, יכול להיות שהבקשה תיחסם על ידי VPC Service Controls על סמך ההקשר של מבצע הקריאה החוזרת, כולל הפרויקט וכתובת ה-IP. כדי לבדוק אם יש הפרת מדיניות של VPC Service Controls:

    1. פותחים את Logs Explorer במסוף Google Cloud :

      כניסה לדף Logs Explorer

    2. מזינים את הטקסט הבא בשדה השאילתה:

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

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

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

אין מכונות קונטיינר זמינות

השגיאה הבאה מתרחשת במהלך הצגת המודעות:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

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

‫Cloud Run לא הצליח לנהל את קצב התנועה

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

HTTP 500
The request was aborted because there was no available instance

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

  1. כדאי לבדוק את הסיבות האפשריות הבאות לבעיה:

    • עלייה פתאומית עצומה בנפח התנועה.
    • זמן הפעלה ארוך במצב התחלתי (cold start).
    • זמן עיבוד ארוך של בקשות, או עלייה פתאומית בזמן עיבוד הבקשות.
    • השירות הגיע למגבלה המקסימלית של מכונות קונטיינרים (HTTP 429).
    • גורמים זמניים שקשורים לשירות Cloud Run.

  2. הטמיעו השהיה מעריכית לפני ניסיון חוזר (exponential backoff) וניסיונות חוזרים לבקשות שהלקוח לא יכול לוותר עליהן. יכול להיות שעלייה קצרה ופתאומית בתנועה או בזמן עיבוד הבקשות תופיע ב-Cloud Monitoring רק אם תגדילו את התצוגה לרזולוציה של 10 שניות.

  3. אם שורש הבעיה הוא תקופה של שגיאות זמניות מוגברות שניתן לייחס רק ל-Cloud Run, פנו לתמיכה.

מכונה של Cloud Run לא מתחילה לפעול

השגיאה הבאה מתרחשת במהלך הצגת המודעות:

HTTP 500
The request failed because the instance could not start successfully.

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

כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:

  1. אימות הרשאות IAM: ודאו שלחשבון השירות של Cloud Run יש את התפקיד Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) בסוד שאתם מנסים לגשת אליו.

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

  3. בדיקת הגדרות הרשת: אם אתם משתמשים בגבולות הגזרה של VPC Service Controls או בכללי חומת אש, ודאו שאתם מאפשרים תעבורת נתונים יוצאת אל secretmanager.googleapis.com.

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

הפעולה לא הוטמעה

השגיאה הבאה מתקבלת כשמציינים REGION שגוי כשמפעילים את המשימה ב-Cloud Run. למשל, כשפורסים משימה באזור asia-southeast1 ומפעילים אותה באמצעות southeast1-asia או asia-southeast:

HTTP 501
Operation is not implemented, or supported, or enabled.

רשימת האזורים הנתמכים מופיעה במאמר מיקומים של Cloud Run.

השירות מחזיר שגיאות מסוג 5xx, ומשימות ב-Cloud Run ומאגרי Worker לא מתחילים לפעול

אם החשבון לחיוב ב- Google Cloud מגיע לתקרת ההוצאות, יכול להיות שמשאבי Cloud Run יחזירו קודי סטטוס HTTP 5xx.

בנוסף, אם אתם מריצים משימות ב-Cloud Run או מאגרי Worker, יכול להיות שלא תצליחו להפעיל משימות חדשות או מכונות חדשות של מאגרי Worker.

כדי לפתור את הבעיה:

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

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

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

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

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

כדי לפתור את הבעיה:

  1. מתקינים ומפעילים את ה-CLI של gcloud.

  2. מגדירים את Application Default Credentials‏ (ADC) עם פרטי הכניסה שמשויכים למשתמש. מגדירים את ADC באמצעות:

      gcloud auth application-default login

    מסך הכניסה יופיע. אחרי שנכנסים, פרטי הכניסה נשמרים בקובץ פרטי הכניסה המקומי שמשמש את ADC.

  3. אפשר להשתמש במשתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS כדי לספק את המיקום של קובץ ה-JSON שמכיל את פרטי הכניסה בפרויקט Google Cloud .

    מידע נוסף זמין במאמר בנושא הגדרה של Application Default Credentials.

מופעי קונטיינרים חורגים ממגבלות הזיכרון

השגיאה הבאה, HTTP 500 או HTTP 503, מתרחשת במהלך הצגת המודעות ב-Cloud Logging:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

כדי לפתור את הבעיה:

  1. בודקים אם המכונות של הקונטיינר חורגות מהזיכרון הזמין. מחפשים שגיאות קשורות ביומני varlog/system.
  2. אם המכונות חורגות מהזיכרון הזמין, כדאי להגדיל את מגבלת הזיכרון.

ב-Cloud Run, קבצים שנכתבים במערכת הקבצים המקומית נכללים בזיכרון הזמין. זה כולל גם קובצי יומן שנכתבים במיקומים אחרים, חוץ מ-/var/log/* ו-/dev/log.

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

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

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

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

  1. הגדלת המספר המקסימלי של מכונות קונטיינרים בשירות.

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

שגיאות ב-Cloud Logging שקשורות להגבלות על מאגר התגים

כשמריצים במרחבי שמות ברמה הבסיסית (root) שמפרים את האילוצים שמפורטים בחוזה של סביבת זמן הריצה של הקונטיינר, יכול להיות שיופיעו ביומני Cloud Logging שגיאות מליבת Linux, כמו "Operation not permitted" או "Permission denied". השגיאות האלה מופיעות כשקריאות המערכת שמנסות לבצע את הפעולות האלה נדחות. במאמר התאמת קונטיינרים ל-Cloud Run מוסבר איך להתאים את הקונטיינרים לסביבות ההרצה של Cloud Run.

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

  • mount.nfs: Operation not permitted
  • mount.cifs: Operation not permitted

אם האפליקציה מנסה לשנות קבצים ב-/proc או ב-/sys באמצעות כלים כמו sysctl, יכול להיות שהיומנים יכילו שגיאות כמו:

  • sysctl: permission denied on key "vm.max_map_count"

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

  • sudo: The "no new privileges" flag is set

קריאות מערכת אחרות, כמו mlockall, עלולות להיכשל עם שגיאות כמו:

  • msg="mlockall syscall failed" error="cannot allocate memory"

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

שגיאות ב-Cloud Logging שקשורות לביטול בקשות בתור בהמתנה

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

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

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

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

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

  2. בפונקציות או בשירותים שמבוססים על טריגרים של HTTP, הלקוח צריך להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) וניסיונות חוזרים לבקשות שאסור לבטל. אם אתם מפעילים שירותים מ-Workflows, אתם יכולים להשתמש בתחביר try/retry כדי לעשות את זה.

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

  4. כדי לצמצם את מספר ההפעלות במצב התחלתי (cold start) שגורמות לחיובים גבוהים יותר, אפשר להגדיר מספר מינימלי של מכונות.

  5. אם שורש הבעיה הוא תקופה של שגיאות זמניות מוגברות שקשורות רק ל-Cloud Run, או אם אתם צריכים עזרה, פנו לתמיכה.

‫Google מחקה את החתימה של אסימון הזהות

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

SIGNATURE_REMOVED_BY_GOOGLE

השגיאה הזו יכולה להופיע בתרחישים הבאים:

  • המשתמש מתחבר באמצעות Google Cloud CLI או Cloud Shell.

  • המשתמש יוצר טוקן של מזהה באמצעות פקודות gcloud.

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

זוהי פעולת ברירת המחדל הצפויה. ‫Google מסירה את החתימה של האסימון מטעמי אבטחה, כדי למנוע משירות Cloud Run שאינו ציבורי להפעיל מחדש אסימוני מזהה שנוצרו באופן הזה.

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

אזהרת OpenBLAS ביומנים

אם אתם משתמשים בספריות שמבוססות על OpenBLAS, כמו NumPy, עם סביבת זמן הריצה מהדור הראשון, יכול להיות שתראו את האזהרה הבאה ביומנים:

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

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

‫Spark נכשל בקבלת כתובת ה-IP של המכונה שאליה צריך לקשר

אם Spark נכשל בזמן קבלת כתובת ה-IP של המכונה המקשרת, מתרחשת אחת מהשגיאות הבאות:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

כדי לפתור את הבעיה, צריך להגדיר את משתנה הסביבה SPARK_LOCAL_IP לערך 127.0.0.1 בקובץ Docker, לדוגמה ENV SPARK_LOCAL_IP="127.0.0.1". אם לא מגדירים את משתנה הסביבה SPARK_LOCAL_IP, הוא מוגדר כברירת מחדל למקביל שלו ב-IPv6 במקום ל-localhost. בנוסף, Spark לא מזהה את משתנה הסביבה שמוגדר כ-RUN export SPARK_LOCAL_IP="127.0.0.1".

אי אפשר לגשת לקבצים באמצעות NFS

שגיאה הצעה לפתרון
mount.nfs: Protocol not supported בחלק מקובצי האימג' הבסיסיים, כמו debian ו-adoptopenjdk/openjdk11, חסר יחס התלות nfs-kernel-server.
mount.nfs: Connection timed out אם הזמן הקצוב לתפוגה של החיבור נגמר, ודאו שאתם מספקים את כתובת ה-IP הנכונה של המכונה של Filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE אם השרת דחה את הגישה, צריך לוודא ששם הקובץ המשותף נכון.

אי אפשר לגשת לקבצים באמצעות Cloud Storage FUSE

המדריך לפתרון בעיות ב-Cloud Storage FUSE.

זמן אחזור ארוך כשניצול המעבד (CPU) נמוך

יכול להיות שזמן האחזור של הבקשות בשירות יהיה ארוך, או שהשירות לא יצליח להגדיל את קנה המידה בעומס, למרות שב-Cloud Monitoring מוצג שניצול המעבד הממוצע נמוך בהרבה מיעד ההתאמה לעומס הרגיל של 60%.

סיבה אפשרית:

זה יכול לקרות אם האפליקציה היא עם שרשור יחיד למשימות שקשורות למעבד (CPU), אבל היא נפרסת במכונה עם כמה מעבדי vCPU. יכול להיות שהאפליקציה תנצל את המקסימום של ליבת vCPU אחת, בזמן שליבות אחרות יישארו ברובן במצב חוסר פעילות. המידרוג האוטומטי ב-Cloud Run משתמש בניצול הממוצע של המעבד (CPU) בכל ה-vCPUs. הממוצע הזה עשוי להיות נמוך במקרים האלה, מה שמונע התאמה לעומס שמבוססת על המעבד.

פתרונות:

  • באפליקציות עם שרשור יחיד:
    • אם דרישות הזיכרון של השירות מתאימות, עדיף להגדיר אותו עם מעבד וירטואלי אחד (ראו מגבלות זיכרון ודרישות מינימום למעבד). כך מדדי ניצול המעבד (CPU) משקפים את העומס בצורה מדויקת.
    • אם צריך כמה מעבדים וירטואליים בגלל דרישות זיכרון גבוהות שחורגות מהמגבלות של מעבד וירטואלי אחד, סביר להניח שהתאמה לעומס (auto-scaling) שמבוססת על מעבד תהיה פחות יעילה. במקרה כזה, כדאי להקטין את הערך של ההגדרה "מספר מקסימלי של בקשות בו-זמניות" כדי לעודד התאמה מוקדמת יותר של קנה המידה על סמך קצב הבקשות. מידע נוסף זמין במאמר הגדרת בו-זמניות.
  • בהגדרות עם כמה מעבדי vCPU: ודאו שהאפליקציה מתוכננת כך שהיא תשתמש ביעילות בכל מעבדי ה-vCPU שהוקצו (לדוגמה, באמצעות כמה תהליכים או שרשורים של עובדים).

שגיאות קישוריות ואבטחה

בקטע הזה מתוארות שגיאות נפוצות שקשורות לקישוריות ולאבטחה ב-Cloud Run, ושיטות לפתרון הבעיות האלה.

הלקוח לא מאומת כמו שצריך

השגיאה הבאה מתרחשת במהלך הצגת המודעות:

HTTP 401: The request was not authorized to invoke this service

כדי לפתור את הבעיה:

  1. אם חשבון שירות מפעיל את השירות שלכם ב-Cloud Run, צריך להגדיר את טענת הקהל (aud) של טוקן המזהה החתום על ידי Google באופן הבא:

    • אם מגדירים את aud לכתובת ה-URL של השירות המקבל בפורמט https://SERVICE. או https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, השירות חייב לדרוש אימות. מפעילים את שירות Cloud Run באמצעות כתובת ה-URL של Cloud Run או באמצעות כתובת ה-URL של מאזן העומסים. לדוגמאות על שליחת בקשות מאומתות, ראו הפעלה באמצעות בקשת HTTPS.

    • אם מגדירים את aud למזהה הלקוח של מזהה לקוח OAuth 2.0 עם הסוג אפליקציית אינטרנט, בפורמט nnn-xyz.apps.googleusercontent.com, אפשר להפעיל את שירות Cloud Run באמצעות מאזן עומסים מסוג HTTPS שמאובטח על ידי IAP. אנחנו ממליצים על הגישה הזו למאזן עומסים של אפליקציות שמגובה על ידי כמה שירותי Cloud Run באזורים שונים.

    • אם מגדירים את הפרמטר aud לקהל בהתאמה אישית, צריך להשתמש בערכים המדויקים שסופקו. לדוגמה, אם הקהל בהתאמה אישית הוא https://service.example.com, ערך טענת הנכונות של הקהל חייב להיות גם https://service.example.com.

  2. חשוב לוודא שהבקשות כוללות כותרת Authorization: Bearer ID_TOKEN, או כותרת X-Serverless-Authorization: Bearer ID_TOKEN להרשאה בהתאמה אישית, ושהטוקן הוא טוקן של מזהה ולא טוקן גישה או טוקן רענון. יכול להיות שתופיע שגיאת 401 בתרחישים הבאים, בגלל פורמט הרשאה שגוי:

    • הפורמט של טוקן ההרשאה לא תקין.

    • כותרת ההרשאה היא לא JSON Web Token (JWT) עם חתימה תקינה.

    • כותרת ההרשאה מכילה כמה אסימוני JWT.

    • בבקשה יש כמה כותרות הרשאה.

    כדי לבדוק הצהרות ב-JWT, אפשר להשתמש בכלי jwt.io.

  3. אם אתם מקבלים אסימונים לא חוקיים כשאתם משתמשים בשרת המטא-נתונים כדי לאחזר מזהים וטוקני גישה לאימות בקשות באמצעות שירות Cloud Run או זהות של משימה עם Proxy ל-HTTP לניתוב תעבורת נתונים יוצאת, הוסיפו את המארחים הבאים לחריגים של Proxy ל-HTTP:

    • 169.254.* או 169.254.0.0/16

    • *.google.internal

  4. שגיאת 401 מתרחשת בדרך כלל כשספריות הלקוח של Cloud משתמשות בשרת המטא-נתונים כדי לאחזר את Application Default Credentials, במטרה לאמת קריאות ל-REST או ל-gRPC. אם לא מגדירים את החריגים לשרת ה-Proxy ל-HTTP, התוצאה היא:

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

    • אם ה-Proxy ל-HTTP לא מתארח ב- Google Cloud, ואתם מנתבים בקשות לשרת המטא-נתונים באמצעות ה-Proxy, הבקשות לאסימונים נכשלות והפעולות של ממשקי ה-API שלGoogle Cloud לא מאומתות.

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

ללקוח אין הרשאה להפעיל את השירות

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

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

שגיאת 403 יכולה להתרחש אם לחבר ב-IAM שמשמש ליצירת טוקן ההרשאה חסרה ההרשאה run.routes.invoke. צריך להעניק את ההרשאה הזו למשתמש שיוצר את הטוקן.

בנוסף, אם יש רשומה של השגיאה בפורמט resource.type = "cloud_run_revision" ב-Cloud Logging, צריך לפעול לפי השלבים הבאים כדי לפתור את השגיאה:

  1. כדי שכל אחד יוכל להפעיל את השירות, מעדכנים את הגדרות ה-IAM והופכים את השירות לציבורי.

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

    • אם מפתח או משתמש קצה מפעילים את השירות, צריך לתת את ההרשאה run.routes.invoke. אפשר לתת את ההרשאה הזו באמצעות התפקידים "אדמין ב-Cloud Run"‏ (roles/run.admin) ו"מפעיל ב-Cloud Run"‏ (roles/run.invoker).

    • אם חשבון שירות מפעיל את השירות, ודאו שחשבון השירות הוא חבר בשירות Cloud Run, והקצו את התפקיד "מפעיל Cloud Run"‏ (roles/run.invoker).

    • קריאות שחסר בהן טוקן אימות עלולות לגרום לשגיאה 403. אם קריאות עם אסימון אימות תקין עדיין מובילות לשגיאה 403, צריך לתת לחבר ב-IAM שיוצר את האסימון את ההרשאה run.routes.invoke.

אם נתקלתם בשגיאה 403 ולא מצאתם את הרשומה ביומן resource.type = "cloud_run_revision", יכול להיות שהסיבה לכך היא ש-VPC Service Controls חוסם שירות Cloud Run שהגדרות תעבורת הנתונים הנכנסת שלו מוגדרות ל-All. מידע נוסף על פתרון בעיות של דחיות ב-VPC Service Controls זמין במאמר שגיאות 404.

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

הבעיה הבאה מתרחשת כשניגשים לשירות Cloud Run מדפדפן אינטרנט:

403 Forbidden
Your client does not have permission to get URL from this server.

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

  1. שימוש בשרת proxy לאימות זהויות (IAP) עם Cloud Run. באמצעות IAP אתם יכולים ליצור שכבת הרשאה מרכזית לאפליקציות שהגישה אליהן מתבצעת דרך HTTPS. באמצעות IAP, אתם יכולים להשתמש במודל בקרת גישה ברמת האפליקציה במקום בחומות אש ברמת הרשת. לפרטים נוספים על הגדרת Cloud Run באמצעות IAP, קראו את המאמר הפעלת שרת proxy לאימות זהויות (IAP) ב-Cloud Run.

  2. כדי לעקוף את הבעיה באופן זמני, אתם יכולים לגשת לשירות דרך דפדפן אינטרנט באמצעות שרת ה-proxy של Cloud Run ב-Google Cloud CLI. כדי להגדיר שירות כשרת proxy באופן מקומי, מריצים את הפקודה הבאה:

    gcloud run services proxy SERVICE --project PROJECT-ID

    ‫Cloud Run מעביר את השירות הפרטי ל-http://localhost:8080 (או ליציאה שציינתם באמצעות --port), ומספק את האסימון של החשבון הפעיל או אסימון אחר שציינתם. זו הדרך המומלצת לבדוק באופן פרטי אתר או API בדפדפן. מידע נוסף זמין במאמר בדיקת שירותים פרטיים.

  3. מאפשרים גישה ציבורית לשירות. האפשרות הזו שימושית לבדיקות, או כשהשירות הוא API או אתר שגלויים לכולם.

החיבור אופס על ידי עמית

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

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

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

  • אם אתם מנסים לבצע עבודה ברקע עם ויסות נתונים במעבד (CPU), השתמשו בהגדרה חיוב מבוסס-מכונה.

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

  • כברירת מחדל, האפשרות keepalive של שקע TCP מושבתת ב-Cloud Run. אין דרך ישירה להגדיר את האפשרות keepalive ברמת השירות. כדי להפעיל את האפשרות keepalive לכל חיבור שקע, צריך לספק את אפשרויות השקע הנדרשות כשפותחים חיבור שקע TCP חדש, בהתאם לספריית הלקוח שבה משתמשים לחיבור הזה באפליקציה.

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

  • אם אתם משתמשים בשרת proxy ל-HTTP כדי לנתב את תנועת הנתונים היוצאת של שירותים או משימות ב-Cloud Run, ושרת ה-proxy אוכף משך חיבור מקסימלי, יכול להיות ששרת ה-proxy יבטל חיבורי TCP ארוכים בלי להודיע, כמו אלה שנוצרו באמצעות מאגר חיבורים. כתוצאה מכך, צד הלקוח ב-HTTP נכשל כשמנסים להשתמש שוב בחיבור שכבר נסגר. אם אתם מתכוונים לנתב תעבורת נתונים יוצאת (egress) דרך Proxy ל-HTTP, עליכם להטמיע אימות חיבור, ניסיונות חוזרים והשהיה מעריכית לפני ניסיון חוזר (exponential backoff). במאגרי חיבורים, מגדירים ערכים מקסימליים לגיל החיבור, לחיבורים ללא פעילות ולזמן הקצוב לתפוגה של חיבורים ללא פעילות.

הזמן הקצוב לתפוגה של החיבור

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

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

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

  1. אם אתם מנתבים את כל תעבורת הנתונים היוצאת דרך רשת VPC, באמצעות מחברי VPC או Direct VPC egress, בצעו את הפעולות הבאות:

    • מגדירים את כל הכללים הנדרשים של חומת האש כדי לאפשר תעבורת נתונים נכנסת (ingress) למחברי ה-VPC.

    • כללי חומת האש של ה-VPC חייבים לאפשר תעבורת נתונים נכנסת (ingress) ממחברי ה-VPC או מתת-הרשת של תעבורת הנתונים היוצאת (egress) של Direct VPC, כדי להגיע למארח או לתת-הרשת של היעד.

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

  2. אם אתם משתמשים בשרת proxy ל-HTTP כדי לנתב את כל תעבורת הנתונים היוצאת מהשירותים או מהמשימות של Cloud Run, המארחים המרוחקים צריכים להיות נגישים באמצעות שרת ה-proxy.

    יכול להיות שתנועה שמועברת דרך שרת proxy ל-HTTP תתעכב, בהתאם לניצול המשאבים של שרת ה-proxy. אם אתם מנתבים תעבורת נתונים יוצאת (egress) של HTTP באמצעות שרת proxy, הטמיעו ניסיונות חוזרים, השהיה מעריכית לפני ניסיון חוזר (exponential backoff) או מפסקי זרם.

הגדרת חריגים ל-Proxy ל-HTTP

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

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

  • 127.0.0.1
  • 169.254.* או 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

מארחים ללא שרת proxy יכולים לכלול:

  • *.appspot.com
  • *.
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

כדי להגדיר חריגים ל-Proxy ל-HTTP בתעבורת נתונים יוצאת (egress), צריך להגדיר את הפרטים הבאים:

  • משתני סביבה: NO_PROXY או no_proxy.

    • ספריות HTTP רגילות של Python, כמו urllib ו-requests, לא תומכות בתווים כלליים לחיפוש עם כוכבית * במשתני הסביבה NO_PROXY או no_proxy. כדי להתאים לתת-דומיינים, צריך להשתמש בנקודה בתחילת המחרוזת במקום ב-*, לדוגמה, .googleapis.com או .google.internal.

  • דגל http.nonProxyHosts של מכונה וירטואלית של Java:

    • מאפיין המערכת https.nonProxyHosts לא מוגדר. מאפיין המערכת הזה חל גם על HTTP וגם על HTTPS.

    • מאפיין המערכת http.nonProxyHosts לא תומך בסימון CIDR. צריך להשתמש בביטויים להתאמה לדפוסים.

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

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

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

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

  1. בודקים אם השגיאות הבאות מופיעות ב-Cloud Logging:

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

    • כשלים בבדיקת החיוניות עם השגיאה הבאה ביומנים:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

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

  2. אם הבקשות מסתיימות עם קוד השגיאה 503 לפני שהן מגיעות לזמן הקצוב לתפוגה של הבקשה שמוגדר ב-Cloud Run, צריך לעדכן את הגדרת הזמן הקצוב לתפוגה של הבקשה במסגרת השפה:

  3. במקרים מסוימים, קוד השגיאה 503 יכול להופיע בגלל צוואר בקבוק ברשת במורד הזרם, למשל במהלך בדיקת עומסים. לדוגמה, אם השירות מנתב תנועה דרך מחבר Serverless VPC Access, צריך לוודא שהמחבר לא חורג מסף התפוקה שלו. כדי לעשות את זה:

    1. פותחים את הדף Serverless VPC Access במסוף Google Cloud :

      כניסה לדף Serverless VPC Access

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

  4. אם מכונה של קונטיינר מקבלת יותר מ-800 בקשות לשנייה, יכול להיות ששקעי ה-TCP הזמינים ינוצלו עד תום. כדי לפתור את הבעיה, מפעילים את HTTP/2 בשירות ומבצעים את השינויים הנדרשים בשירות כדי לתמוך ב-HTTP/2.

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

השגיאה הבאה מתרחשת כשהשירות לא מחזיר תשובה תוך פרק זמן מסוים, והבקשה מסתיימת:

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

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

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

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

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

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

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

  • שגיאות של אין זיכרון פנוי (OOM) שמתרחשות בתוך הקוד של האפליקציה, לדוגמה java.lang.OutOfMemoryError, לא בהכרח מסיימות את המכונה של קונטיינר. אם השימוש בזיכרון לא חורג ממגבלת הזיכרון של הקונטיינר, המכונה לא תופסק על ידי Cloud Run. בהתאם לאופן שבו האפליקציה מטפלת בשגיאות של אין זיכרון פנוי (OOM) ברמת האפליקציה, יכול להיות שהבקשות לא יועברו עד שהן יחרגו מהזמן הקצוב לתפוגה שהגדרתם לבקשות.

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

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

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

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

אחת מהשגיאות הבאות מתרחשת כשממפים דומיין מותאם אישית:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

כדי לפתור את הבעיה:

  1. ממתינים לפחות 24 שעות. הקצאת אישור ה-SSL נמשכת בדרך כלל כ-15 דקות, אבל יכולה להימשך עד 24 שעות.

  2. מוודאים שרשומות ה-DNS עודכנו כמו שצריך אצל רשם הדומיינים באמצעות הכלי Dig בארגז הכלים של Google Admin. רשומות ה-DNS ברשם הדומיינים שלכם צריכות להתאים למה שGoogle Cloud מופיע במסוף.

  3. מאמתים את שורש הדומיין בחשבון באחת מהשיטות הבאות:

  4. מוודאים שהתוקף של האישור לדומיין לא פג. כדי למצוא את גבולות התפוגה, משתמשים בפקודה הבאה:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

התנתקות של לקוח לא מועברת ל-Cloud Run

כשמשתמשים ב-HTTP/1.1 ב-Cloud Run, אירועי ניתוק של לקוחות לא מופצים לקונטיינר של Cloud Run.

כדי לפתור את הבעיה, צריך להשתמש ב-Websockets או ב-HTTP/2.0, שמפיצים את הניתוקים של הלקוחות.