פתרון בעיות ב-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 ב-Dockerfile.

חשבון השירות של 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 מגדיר את נקודת הכניסה (entrypoint) שמשמשת כברירת מחדל לפריסות של מקורות ב-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 כדי להגדיר נקודת כניסה.

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

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

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

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

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. גישה לנקודת הקצה (endpoint) של השירות באמצעות מאזן עומסים באמצעות זמן הריצה של 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.

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

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

  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.

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

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

סיבה אפשרית:

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

פתרונות:

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

    gcloud run services proxy SERVICE --project PROJECT-ID

    ‫Cloud Run מעביר את שירות ה-Private באמצעות פרוקסי אל 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 לכל חיבור שקע, צריך לספק את אפשרויות השקע הנדרשות כשפותחים חיבור שקע TCP חדש, בהתאם לספריית הלקוח שבה משתמשים לחיבור הזה באפליקציה.

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

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

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

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

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

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

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

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

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

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

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

אפשר גם לכלול מארחים שלא מוגדר להם שרת proxy, כמו:

  • *.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 :

      מעבר אל חיבור לרשת (VPC) מאפליקציית serverless

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

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

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

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

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

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

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