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

בדף הזה מוסבר איך לפתור בעיות שאתם עלולים להיתקל בהן במהלך השימוש ב-Cloud Run. ב-Service Health בהתאמה אישית מתפרסמים כל האירועים ב-Cloud Run שנובעים מהתשתית הבסיסית של Google Cloud , כדי שתוכלו לזהות שיבושים בשירות של Google Cloud שמשפיעים על הפרויקטים שלכם. מומלץ גם להגדיר התראות על אירועים במרכז האישי ב-Service Health. מידע על אירועים שמשפיעים על כל שירותי Google Cloud 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 daemon.

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

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

The feature is not supported in the declared launch stage

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

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

בדוגמאות הבאות מוסבר איך להוסיף הפניות לשלב ההשקה כשמשתמשים ב-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@developer.gserviceaccount.com (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 (הרשאות) בקטע Identity and Access Management (ניהול זהויות והרשאות גישה) במסוף Google Cloud :

    מעבר להרשאות

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

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

בעיות בחשבון השירות ב-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 perimeter עם הגבלה על 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.iam.gserviceaccount.com"

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

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

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

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@developer.gserviceaccount.com) או חשבון שירות בניהול המשתמשים.

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

כדי לפתור את הבעיה הזו, צריך להקצות לחשבון הפריסה את התפקיד משתמש בחשבון שירות (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.

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

שגיאה בפריסת שירות 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.iam.gserviceaccount.com) כגורם הראשי מפרויקט המקור.

  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. ב-Python מגרסה 3.13 ואילך, ה-buildpack של Python מגדיר את נקודת הכניסה על סמך הגדרת שירות האינטרנט בקובץ requirements.txt. אם לא מציינים שרת אינטרנט או framework בקובץ requirements.txt, או אם משתמשים ב-Python בגרסה 3.12 ומטה, ה-buildpack של Python מגדיר את נקודת הכניסה (entrypoint) כברירת מחדל ל-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 כדי להגדיר נקודת כניסה.

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

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

‫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 או בכללי חומת אש, ודאו שאפשרתם תעבורת נתונים יוצאת (egress) אל secretmanager.googleapis.com.

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

הפעולה לא יושמה

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

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

רשימת האזורים הנתמכים מופיעה במאמר מיקומים של 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.

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

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

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 שמכילים שגיאות מליבת לינוקס, כמו 'הפעולה לא מורשית' או 'ההרשאה נדחתה'. השגיאות האלה מופיעות כשהמערכת דוחה את השיחות שמנסות לבצע את הפעולות האלה. במאמר התאמת קונטיינרים ל-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, הלקוח צריך להטמיע נסיגה אקספוננציאלית וניסיונות חוזרים לבקשות שאסור להפסיק. אם אתם מפעילים שירותים מתוך 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 בקובץ Dockerfile, לדוגמה, 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.

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

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

סיבה אפשרית:

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

פתרונות:

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

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

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

הלקוח לא מאומת בצורה תקינה

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

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

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

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

    • אם מגדירים את aud לכתובת ה-URL של השירות המקבל באמצעות הפורמט https://SERVICE.run.app או 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 עשויה להתרחש בתרחישים הבאים בגלל פורמט הרשאה שגוי:

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

  3. אם אתם מקבלים אסימונים לא תקינים כשאתם משתמשים בשרת המטא-נתונים כדי לאחזר אסימונים מזהים וטוקני גישה לאימות בקשות באמצעות זהות המשימה או שירות Cloud Run עם Proxy ל-HTTP לניתוב תעבורת נתונים יוצאת (egress), עליכם להוסיף את המארחים הבאים לחריגים של 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, בקשות האסימון ייכשלו והפעולות של Google Cloud APIs לא יעברו אימות.

  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 Admin‏ (roles/run.admin) ו-Cloud Run Invoker‏ (roles/run.invoker).

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

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

אם נתקלתם בשגיאה 403 ולא מצאתם את רשומה ביומן resource.type = "cloud_run_revision", יכול להיות שהסיבה לכך היא ש-VPC Service Controls חוסם שירות Cloud Run עם הגדרות Ingress שהוגדרו לערך 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. כדי להפעיל פרוקסי לשירות באופן מקומי, מריצים את הפקודה הבאה:

    gcloud run services proxy SERVICE --project PROJECT-ID

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

  3. Allow public access לשירות. האפשרות הזו שימושית לבדיקות, או כשהשירות שלכם הוא 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 לכל חיבור socket, צריך לספק את אפשרויות ה-socket הנדרשות כשפותחים חיבור TCP socket חדש, בהתאם לספריית הלקוח שבה משתמשים לחיבור הזה באפליקציה.

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

  • אם אתם משתמשים ב-Proxy ל-HTTP כדי לנתב את תעבורת הנתונים היוצאת (egress) של שירותים או משימות ב-Cloud Run, וה-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. אם אתם מנתבים את כל תעבורת הנתונים היוצאת (egress) דרך רשת VPC, באמצעות מחברי VPC או יציאה ישירה מ-VPC, אתם צריכים לבצע את השלבים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

  • הדגל של Java Virtual Machine‏ (JVM) ‏http.nonProxyHosts:

    • מאפיין המערכת 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 אם יש את השגיאות הבאות:

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

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

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

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

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

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

    1. פותחים את הכלי 'חיבור לרשת (VPC) מאפליקציית serverless' במסוף 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 יכולה להיות סימן לכך שהאפליקציה מנסה לעשות שימוש חוזר בחיבור לא פעיל, והבקשה נחסמת עד שתגיע לזמן הקצוב לתפוגה שהוגדר לבקשה. אפשר להשתמש בבדיקת פעילות כדי לסיים מופע שמחזיר שגיאות קבועות.

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

    כדי לסיים את מופע מאגר התגים:

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

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

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

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

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, שמעבירים את הניתוקים של הלקוח.