פתרון בעיות בפריסות של gRPC ללא שרת proxy

במסמך הזה מוסבר איך לפתור בעיות בהגדרות כשפורסים שירותי gRPC בלי שרת Proxy באמצעות Cloud Service Mesh. במאמר הסבר על סטטוס הלקוח של Cloud Service Mesh מוסבר איך משתמשים ב-Client Status Discovery Service (CSDS) API כדי לחקור בעיות ב-Cloud Service Mesh.

פתרון בעיות של כשלים ב-RPC באפליקציית gRPC

יש שתי דרכים נפוצות לפתרון בעיות שקשורות לכשלים בקריאה לשירות מרוחק (RPC) באפליקציית gRPC:

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

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

    הטמעות שונות של gRPC בשפות שונות מאפשרות הפעלה של רישום ביומן בזמן הריצה של gRPC בדרכים שונות:

    • ‫gRPC ב-Java: gRPC משתמש ב-java.util.logging לרישום ביומן. מגדירים את io.grpc.level לרמה FINE כדי להפעיל רישום מפורט ביומן בזמן הריצה של gRPC. דרך נפוצה להפעלת רישום ב-Java היא טעינת הגדרות הרישום מקובץ וציון מיקום הקובץ ל-JVM באמצעות דגל בשורת הפקודה. לדוגמה:

      # Create a file called logging.properties with the following contents:
handlers=java.util.logging.ConsoleHandler
io.grpc.level=FINE
io.grpc.xds.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# Pass the location of the file to JVM by using this command-line flag:
-Djava.util.logging.config.file=logging.properties

      כדי להפעיל רישום ביומן שספציפי למודולי xDS, מגדירים את io.grpc.xds.level לערך FINE. כדי לראות רישום מפורט יותר ביומן, מגדירים את הרמה ל-FINER או ל-FINEST.

    • ‫gRPC ב-Go: כדי להפעיל את הרישום ביומן צריך להגדיר משתני סביבה.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • ‫gRPC ב-C++‎: כדי להפעיל רישום ביומן באמצעות gRPC ב-C++‎, אפשר לעיין בהוראות במאמר פתרון בעיות ב-gRPC. כדי להפעיל רישום ביומן שספציפי למודולי xDS, צריך להפעיל את כלי המעקב הבאים באמצעות GRPC_TRACE משתנה הסביבה עבור xds_client,‏ xds_resolver,‏ cds_lb,‏ eds_lb,‏ priority_lb,‏ weighted_target_lb ו-lrs_lb.

    • ‫gRPC ב-Node.js: כדי להפעיל רישום ביומן באמצעות gRPC ב-Node.js, אפשר לעיין בהוראות במאמר פתרון בעיות ב-gRPC-JS. כדי להפעיל רישום ביומן שספציפי למודולי xDS, צריך להפעיל את אמצעי המעקב הבאים באמצעות GRPC_TRACE משתנה הסביבה עבור xds_client,‏ xds_resolver,‏ cds_balancer,‏ eds_balancer,‏ priority ו-weighted_target.

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

אי אפשר להתחבר ל-Cloud Service Mesh

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

  • בודקים שהערך של server_uri בקובץ האתחול הוא trafficdirector.googleapis.com:443.
  • מוודאים שמשתנה הסביבה GRPC_XDS_BOOTSTRAP מוגדר ומצביע על קובץ האתחול.
  • כשיוצרים ערוץ gRPC, צריך לוודא שמשתמשים בסכימת xds ב-URI.
  • חשוב לוודא שהענקתם את הרשאות ה-IAM הנדרשות ליצירת מכונות וירטואליות ולשינוי רשת בפרויקט.
  • חשוב לוודא שהפעלתם את חשבון השירות כדי לגשת אל Traffic Director API. בקטע Google Cloud console APIs & services (ממשקי API ושירותים במסוף) של הפרויקט, מחפשים שגיאות ב-Traffic Director API.
  • מוודאים שלחשבון השירות יש את ההרשאות הנכונות. אפליקציות gRPC שפועלות במכונה הווירטואלית או ב-Pod משתמשות בחשבון השירות של המארח של המכונה הווירטואלית ב-Compute Engine או במופע של הצומת ב-Google Kubernetes Engine‏ (GKE).

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

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • מוודאים שאפשר לגשת אל trafficdirector.googleapis.com:443 מהמכונה הווירטואלית. אם יש בעיות בגישה, יכול להיות שחומת אש מונעת גישה ל-trafficdirector.googleapis.com דרך יציאת TCP‏ 443 או שיש בעיות בפענוח DNS עבור שם המארח trafficdirector.googleapis.com.

לא ניתן לזהות את שם המארח שצוין ב-URI

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

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

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

  • מוודאים שאתם משתמשים בגרסה ושפה נתמכות של gRPC.
  • מוודאים שהיציאה שמשמשת ב-URI ליצירת ערוץ gRPC זהה לערך היציאה בכלל ההעברה שמשמש בהגדרה. אם לא מציינים יציאה ב-URI, המערכת משתמשת בערך 80 כדי להתאים כלל העברה.
  • מוודאים ששם המארח והיציאה שמשמשים ב-URI ליצירת ערוץ gRPC זהים בדיוק לכלל מארח במפת ה-URL שמשמשת בהגדרה.
  • מוודאים שאותו כלל מארח לא מוגדר ביותר ממפת URL אחת.
  • מוודאים שלא נעשה שימוש בתווים כלליים לחיפוש (כמו כוכבית). המערכת מתעלמת מכללי מארח שמכילים *תו כללי לחיפוש.

ה-RPC נכשל כי השירות לא זמין

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

  • בודקים את הסטטוס הכולל של Cloud Service Mesh ואת הסטטוס של שירותי הקצה העורפי במסוףGoogle Cloud :

    • בעמודה Associated routing rule maps, מוודאים שכתובות ה-URL הנכונות של מיפוי כללי הניתוב מפנות לשירותי הקצה העורפי. לוחצים על העמודה כדי לוודא ששירותי ה-Backend שצוינו בכללי התאמת המארחים נכונים.
    • בעמודה Backends, בודקים שהעורפים שמשויכים לשירותי העורף תקינים.
    • אם השרתים העורפיים לא תקינים, לוחצים על שירות השרת העורפי המתאים ומוודאים שבדיקת התקינות הנכונה מוגדרת. בדיקות התקינות נכשלות בדרך כלל בגלל כללים שגויים או חסרים של חומת האש, או בגלל חוסר התאמה בתגים שצוינו במכונה הווירטואלית ובכללים של חומת האש. מידע נוסף זמין במאמר יצירת בדיקות תקינות.

  • כדי שבודקי תקינות של gRPC יפעלו בצורה תקינה, עורפי ה-gRPC צריכים להטמיע את פרוטוקול בדיקת התקינות של gRPC. אם הפרוטוקול הזה לא מיושם, אפשר להשתמש במקום זאת בבדיקת תקינות של TCP. אל תשתמשו בבדיקת תקינות של HTTP,‏ HTTPS או HTTP/2 עם שירותי gRPC.

  • כשמשתמשים בקבוצות של מופעים, צריך לוודא שהיציאה עם השם שצוינה בקבוצת המופעים זהה ליציאה שמשמשת בבדיקת תקינות. כשמשתמשים בקבוצות של נקודות קצה ברשת (NEGs), צריך לוודא שבמפרט השירות של GKE יש את הערת ה-NEG הנכונה, ובדיקת התקינות מוגדרת לשימוש ביציאת ה-NEG.

  • בודקים שפרוטוקול נקודת הקצה מוגדר כ-GRPC.

ה-RPC נכשל כי מדיניות איזון העומסים לא נתמכת

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

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

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

תצורת האבטחה לא נוצרת כמצופה

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

‫Cloud Service Mesh לא תומך בתרחישים שבהם יש שני משאבי מדיניות של נקודות קצה או יותר שתואמים באופן שווה לנקודת קצה. לדוגמה, שתי מדיניות עם אותן תוויות ואותם פורטים, או שתי מדיניות או יותר עם תוויות שונות שתואמות באופן שווה לתוויות של נקודת קצה. מידע נוסף על האופן שבו מתבצעת התאמה בין מדיניות נקודות קצה לתוויות של נקודת קצה זמין במאמר בנושא ממשקי API של EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. במקרים כאלה, Cloud Service Mesh לא יוצר הגדרת אבטחה מאף אחת ממדיניות ההרשאה שמתנגשות.

פתרון בעיות בתקינות של Service mesh

במדריך הזה מוסבר איך לפתור בעיות בהגדרת Cloud Service Mesh.

התנהגות של Cloud Service Mesh כשרוב נקודות הקצה לא תקינות

כדי לשפר את המהימנות, אם 99% מנקודות הקצה לא תקינות, Cloud Service Mesh מגדיר את מישור הנתונים כך שיתעלם ממצב התקינות של נקודות הקצה. במקום זאת, מישור הנתונים מאזן את התעבורה בין כל נקודות הקצה, כי יכול להיות שהיציאה של השרת עדיין פועלת.

קצוות עורפיים לא תקינים גורמים להפצה לא אופטימלית של תנועת הגולשים

‫Cloud Service Mesh משתמש במידע במשאב HealthCheck שמצורף לשירות קצה עורפי כדי להעריך את תקינות שירותי הקצה העורפיים. ‫Cloud Service Mesh משתמש בסטטוס התקינות הזה כדי לנתב את תעבורת הנתונים לקצה העורפי הקרוב ביותר שפועל בצורה תקינה. אם חלק מהעורפים לא תקינים, יכול להיות שהתנועה תמשיך להיות מעובדת, אבל עם חלוקה לא אופטימלית. לדוגמה, יכול להיות שתעבורת הנתונים תזרום לאזור שבו עדיין יש שרתי בק-אנד תקינים, אבל האזור הזה מרוחק יותר מהלקוח, ולכן ייווצר זמן אחזור. כדי לזהות ולעקוב אחרי סטטוס התקינות של השרתים העורפיים, אפשר לנסות את השלבים הבאים:

המאמרים הבאים