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

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

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

בדוגמאות הבאות מוסבר איך להוסיף הפניות לשלב ההשקה כשמשתמשים ב-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.s3ns-system.iam.gserviceaccount.com (or it may not exist).

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

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

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

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

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

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

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

    עוברים להרשאות

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

  3. ברשימה Principals, מאתרים את המזהה של סוכן השירות של Compute Engine, בפורמט PROJECT_NUMBER-compute@developer.s3ns-system.iam.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.

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

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

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

    1. פותחים את Logs Explorer במסוף Cloud de Confiance . (אל תשתמשו בדף 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.s3ns-system.iam.gserviceaccount.com"

    3. אם מופיעות רשומות ביומן אחרי השימוש בשאילתה הזו, צריך לבדוק את הרשומות ביומן כדי לקבוע אם צריך לעדכן את כללי המדיניות של VPC Service Controls. יכול להיות שהם יציינו שצריך להוסיף את service-PROJECT_NUMBER@serverless-robot-prod.s3ns-system.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.s3ns-system.iam.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 מפרויקטים אחרים של Cloud de Confiance by S3NS

השגיאה הבאה מתרחשת כשפורסים שירות 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.s3ns-system.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. בגרסה 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 או מקצים מחדש באופן מפורש את תגי התנועה לגרסה קיימת ופעילה.
  • באמצעות מסוף Cloud de Confiance : עוברים לשירות, לכרטיסייה Revisions ועורכים את הקצאת התנועה כדי להסיר את התג שמפנה לגרסה שנמחקה.

HTTP 404: לא נמצא

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

`HTTP 404`:Not found

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

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

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

      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 במסוף Cloud de Confiance :

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

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

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

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

  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 שמכיל את פרטי הכניסה בפרויקט Cloud de Confiance by S3NS .

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

  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).

פתרונות:

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

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

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

  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"‏ (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 לשירות. עם זאת, הבקשה לא מכילה את טוקן ההרשאה של המשתמש שקורא ל-API. כדי לפתור את הבעיה, צריך לבצע את השלבים הבאים:

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

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

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

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

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

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

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

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

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

  • *.appspot.com
  • *.s3nsrun.fr
  • *.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.

  • הדגל של Java Virtual Machine‏ 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 אם יש שגיאות מהסוגים הבאים:

    • שגיאות אין זיכרון פנוי (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 במסוף Cloud de Confiance :

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

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