פתרון בעיות בפריסות של Envoy

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

קביעת הגרסה של Envoy שמותקנת במכונה וירטואלית

כדי לבדוק איזו גרסה של Envoy פועלת במכונה וירטואלית (VM), צריך לפעול לפי ההוראות הבאות.

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

בודקים את מאפייני האורח של המכונה הווירטואלית בנתיב gce-service-proxy/proxy-version:

  gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME 

      --zone ZONEc --query-path=gce-service-proxy/proxy-version



NAMESPACE          KEY            VALUE
  gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

בודקים את יומני המופעים של Cloud Logging מפרטי מכונת ה-VM בדף Logging במסוף Google Cloud באמצעות שאילתה כמו זו:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

מקבלים תגובה כמו זו:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

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

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version



/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

משתמשים ב-SSH כדי להתחבר למכונה הווירטואלית ולממשק האדמין כמשתמש root:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

מיקומי היומנים של Envoy

כדי לפתור בעיות מסוימות, צריך לבדוק את יומני ה-proxy של Envoy.

אפשר להשתמש ב-SSH כדי להתחבר למכונה הווירטואלית ולקבל את קובץ היומן. הנתיב צפוי להיות כזה.

  /var/log/envoy/envoy.err.log

שרתי Proxy לא מתחברים ל-Cloud Service Mesh

אם שרתי ה-proxy שלכם לא מתחברים ל-Cloud Service Mesh, צריך לבצע את הפעולות הבאות:

  • בודקים את היומנים של Envoy proxy כדי לראות אם יש שגיאות בחיבור אל trafficdirector.googleapis.com.

  • אם הגדרתם את netfilter (באמצעות iptables) להפניית כל התנועה לשרת ה-Proxy של Envoy, ודאו שהמשתמש (UID) שדרכו אתם מריצים את ה-Proxy לא נכלל בהפניה. אחרת, התנועה תמשיך לחזור לשרת ה-proxy.

  • מוודאים שהפעלתם את API של Cloud Service Mesh בפרויקט. בקטע APIs & services של הפרויקט, מחפשים שגיאות ב-Cloud Service Mesh API.

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

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

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

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

  • אם אתם משתמשים ב-Envoy בשביל פרוקסי sidecar, אתם צריכים לוודא שגרסת Envoy היא 1.24.9 ואילך.

אי אפשר להגיע לשירות שהוגדר באמצעות Cloud Service Mesh

אם לא ניתן להגיע לשירות שהוגדר באמצעות Cloud Service Mesh, צריך לוודא ששרת ה-proxy מסוג sidecar פועל ויכול להתחבר ל-Cloud Service Mesh.

אם אתם משתמשים ב-Envoy כשרת Proxy מסוג sidecar, תוכלו להריץ את הפקודות הבאות כדי לוודא זאת:

  1. משורת הפקודה, מוודאים שתהליך Envoy פועל:

    ps aux | grep envoy

  2. בודקים את הגדרות זמן הריצה של Envoy כדי לוודא ש-Cloud Service Mesh הגדיר משאבים דינמיים. כדי לראות את ההגדרה, מריצים את הפקודה הבאה:

    curl http://localhost:15000/config_dump

  3. מוודאים שהגדרתם נכון את חסימת התנועה עבור שרת ה-proxy של sidecar. כדי להגדיר את ההפניה האוטומטית באמצעות iptables, מריצים את הפקודה iptables ואז grep את הפלט כדי לוודא שהכללים מופיעים:

    sudo iptables -t nat -S | grep ISTIO

    הדוגמה הבאה היא של הפלט של iptables שחוצה את כתובת ה-IP הווירטואלית (VIP) 10.0.0.1/32 ומעביר אותה לפרוקסי של Envoy שפועל ביציאה 15001 כמזהה משתמש 1006:

    -N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN

אם מופע המכונה הווירטואלית נוצר דרך Google Cloud המסוף, חלק מהמודולים שקשורים ל-IPv6 לא מותקנים ולא זמינים לפני הפעלה מחדש. כתוצאה מכך, הפעולה של iptables נכשלת בגלל תלויות חסרות. במקרה כזה, מפעילים מחדש את ה-VM ומריצים מחדש את תהליך ההגדרה. הבעיה אמורה להיפתר. לא אמורה להיות בעיה כזו במכונה וירטואלית ב-Compute Engine שנוצרה באמצעות Google Cloud CLI.

השירות לא נגיש יותר כשמגדירים רישום ביומן של הגישה ל-Envoy

אם השתמשתם ב-TRAFFICDIRECTOR_ACCESS_LOG_PATH כדי להגדיר יומן גישה של Envoy כמו שמתואר במאמר הגדרת מאפייני bootstrap של Envoy ל-Cloud Service Mesh, ודאו שלמשתמש המערכת שמריץ את Envoy proxy יש הרשאות כתיבה למיקום של יומן הגישה שצוין.

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

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

כדי לפתור את הבעיה, צריך לשנות את ההרשאות של הקובץ שנבחר כך שמשתמש Envoy יוכל לכתוב בו.

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

הסעיף הזה רלוונטי לפריסות שנעשה בהן שימוש בממשקי ה-API של איזון העומסים.

אם נתקלתם בבעיות בהגדרת Cloud Service Mesh, יכול להיות שיופיעו ביומני Envoy אחת מהודעות השגיאה הבאות:

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.
  • Cloud Service Mesh configuration was not found.

הודעת השגיאה האחרונה (Traffic Director configuration was not found) מציינת בדרך כלל ש-Envoy מבקש הגדרה מ-Cloud Service Mesh, אבל לא נמצאה הגדרה תואמת. כש-Envoy מתחבר ל-Cloud Service Mesh, הוא מציג שם של רשת VPC (לדוגמה, my-network). לאחר מכן, Cloud Service Mesh מחפש כללי העברה עם סכימת איזון העומסים INTERNAL_SELF_MANAGED שמפנים לאותו שם של רשת VPC.

כדי לפתור את השגיאה:

  1. מוודאים שיש כלל העברה ברשת עם תוכנית איזון העומסים INTERNAL_SELF_MANAGED. שימו לב לשם רשת ה-VPC של כלל ההעברה.

  2. אם אתם משתמשים ב-Cloud Service Mesh עם פריסות אוטומטיות של Envoy ב-Compute Engine, ודאו שהערך שצוין בדגל --service-proxy:network תואם לשם של רשת ה-VPC של כלל ההעברה.

  3. אם אתם משתמשים ב-Cloud Service Mesh עם פריסות ידניות של Envoy ב-Compute Engine, אתם צריכים לבדוק את קובץ האתחול של Envoy כדי לוודא שהוא כולל את הפרטים הבאים:

    1. מוודאים שהערך של המשתנה TRAFFICDIRECTOR_NETWORK_NAME תואם לשם רשת ה-VPC של כלל ההעברה.
    2. מוודאים שמספר הפרויקט מוגדר במשתנה TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.

  4. אם אתם פורסים ב-GKE ומשתמשים ב-auto-injector, ודאו שמספר הפרויקט ושם רשת ה-VPC מוגדרים בצורה נכונה, בהתאם להוראות במאמר הגדרה של Cloud Service Mesh עבור פודים של GKE עם הזרקה אוטומטית של Envoy.

פתרון בעיות ב-Compute Engine

בקטע הזה מוסבר איך לפתור בעיות בהטמעה של Envoy ב-Compute Engine.

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

ערוצי תקשורת לפתרון בעיות

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

רישום ביומן של פלט מיציאה טורית וירטואלית

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

סוכני האתחול של Compute Engine מתעדים את כל הפעולות שבוצעו ביציאה טורית 1. הנתונים האלה כוללים אירועים במערכת, החל מהתקנה בסיסית של חבילה ועד לקבלת נתונים משרת המטא-נתונים של מכונה, iptablesההגדרה ומצב ההתקנה של Envoy.

סוכנים ב-VM מתעדים את סטטוס התקינות של תהליך Envoy, שירותים חדשים של Cloud Service Mesh שהתגלו וכל מידע אחר שעשוי להיות שימושי כשבודקים בעיות ב-VM.

רישום ביומן ב-Cloud Monitoring

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

מאפייני אורח של מכונה וירטואלית

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

סקריפטים של Compute Engine Envoy bootstrap וסוכנים במכונות וירטואליות חושפים מאפיינים עם מידע על תהליך ה-bootstrap והסטטוס הנוכחי של Envoy. כל מאפייני האורחים נחשפים במרחב השמות gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

אם מצאתם בעיות, מומלץ לבדוק את הערך של מאפייני האורח bootstrap-status ו-bootstrap-last-failure. כל ערך אחר מלבד FINISHED מציין שסביבת Envoy עדיין לא הוגדרה.bootstrap-status הערך של bookstrap-last-failure עשוי להצביע על הבעיה.

אי אפשר להגיע לשירות Cloud Service Mesh ממכונה וירטואלית שנוצרה באמצעות תבנית של הגדרות מכונה עם הפעלת Service Proxy

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

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

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

    המאפיין bootstrap-status guest מוגדר לאחד מהערכים הבאים:

    • ‫[none] מציין שההתקנה עדיין לא התחילה. יכול להיות שהמכונה הווירטואלית עדיין נמצאת בתהליך אתחול. כדאי לבדוק שוב את הסטטוס בעוד כמה דקות.
    • ‫IN PROGRESS מציין שההתקנה וההגדרה של רכיבי שרת ה-proxy של השירות עדיין לא הושלמו. חוזרים על בדיקת הסטטוס כדי לראות עדכונים לגבי התהליך.
    • ‫FAILED מציין שההתקנה או ההגדרה של רכיב נכשלו. בודקים את הודעת השגיאה על ידי שליחת שאילתה למאפיין gce-service-proxy/bootstrap-last-failure1.
    • ‫FINISHED מציין שתהליכי ההתקנה וההגדרה הסתיימו ללא שגיאות. כדי לוודא שהגדרתם נכון את חסימת התנועה ואת שרת ה-Proxy של Envoy, פועלים לפי ההוראות הבאות.

  2. הגדרת חסימת התעבורה במכונה הווירטואלית לא מתבצעת בצורה נכונה בשירותים שמבוססים על Cloud Service Mesh. נכנסים ל-VM ובודקים את ההגדרה:iptables 

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat

    בודקים את השרשרת SERVICE_PROXY_SERVICE_CIDRS כדי למצוא רשומות של SERVICE_PROXY_REDIRECT, כמו אלה:

    Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20

    לכל שירות צריכה להיות כתובת IP או CIDR תואמת בעמודה destination. אם אין רשומה לכתובת ה-IP הווירטואלית (VIP), יש בעיה באכלוס ההגדרות של Envoy proxy מ-Cloud Service Mesh, או שהסוכן במכונה הווירטואלית נכשל.

  3. ה-proxies של Envoy עדיין לא קיבלו את ההגדרה שלהם מ-Cloud Service Mesh. כדי לבדוק את ההגדרה של שרת ה-proxy של Envoy, נכנסים למכונה הווירטואלית:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump

    בודקים את הגדרות ה-listener שהתקבלו מ-Cloud Service Mesh. לדוגמה:

    "dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]

    ‫address_prefix היא כתובת ה-IP הווירטואלית (VIP) של שירות Cloud Service Mesh. הוא מפנה למפת URL שנקרא td-routing-rule-1. בודקים אם השירות שאליו רוצים להתחבר כבר כלול בהגדרות של המאזין.

  4. הסוכן במכונה הווירטואלית לא פועל. הסוכן במכונה הווירטואלית מגדיר אוטומטית את חסימת התנועה כשנוצרים שירותים חדשים של Cloud Service Mesh. אם הסוכן לא פועל, כל התנועה לשירותים חדשים עוברת ישירות לכתובות ה-VIP, מדלגת על שרת ה-proxy של Envoy ומגיעה לזמן קצוב לתפוגה.

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

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE

    2. בודקים את המאפיינים של הסוכן ב-VM. הערך של מאפיין agent-heartbeat הוא השעה שבה הסוכן ביצע לאחרונה פעולה או בדיקה. אם הערך ישן יותר מחמש דקות, הסוכן תקוע וצריך ליצור מחדש את ה-VM באמצעות הפקודה הבאה:

      gcloud compute instance-groups managed recreate-instance

    3. המאפיין agent-last-failure חושף את השגיאה האחרונה שהתרחשה בסוכן. יכול להיות שמדובר בבעיה זמנית שתיפתר בפעם הבאה שהסוכן יבדוק – למשל, אם השגיאה היא Cannot reach the Cloud Service Mesh API server – או שזו יכולה להיות שגיאה קבועה. מחכים כמה דקות ואז בודקים שוב את השגיאה.

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

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

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

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

    המאפיין bootstrap-status guest מוגדר לאחד מהערכים הבאים:

    • ‫[none] מציין שההתקנה עדיין לא התחילה. יכול להיות שהמכונה הווירטואלית עדיין נמצאת בתהליך אתחול. כדאי לבדוק שוב את הסטטוס בעוד כמה דקות.
    • ‫IN PROGRESS מציין שההתקנה וההגדרה של רכיבי שרת ה-proxy של השירות עדיין לא הושלמו. חוזרים על בדיקת הסטטוס כדי לראות עדכונים לגבי התהליך.
    • ‫FAILED מציין שההתקנה או ההגדרה של רכיב נכשלו. בודקים את הודעת השגיאה על ידי שליחת שאילתה למאפיין gce-service-proxy/bootstrap-last-failure1.
    • ‫FINISHED מציין שתהליכי ההתקנה וההגדרה הסתיימו ללא שגיאות. כדי לוודא שהגדרתם נכון את חסימת התנועה ואת שרת ה-Proxy של Envoy, פועלים לפי ההוראות הבאות.

  2. ההגדרה של חסימת תנועה במכונה הווירטואלית לא תקינה עבור תנועה נכנסת. נכנסים ל-VM ובודקים את ההגדרה של iptables:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat

    בודקים את השרשרת SERVICE_PROXY_INBOUND כדי למצוא רשומות של SERVICE_PROXY_IN_REDIRECT, כמו אלה:

    Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql

    לכל יציאה שמוגדרת ב-service-proxy:serving-ports, צריכה להיות יציאה תואמת בעמודה destination. אם אין רשומה של היציאה, כל התעבורה הנכנסת מועברת ישירות ליציאה הזו, בלי לעבור דרך שרת ה-proxy של Envoy.

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

  3. ה-proxies של Envoy עדיין לא קיבלו את ההגדרה שלהם ליציאה הנכנסת מ-Cloud Service Mesh. נכנסים למכונה הווירטואלית כדי לבדוק את ההגדרה של שרת ה-proxy של Envoy:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump

    מחפשים את הגדרות מאזין לדואר נכנס שהתקבלו מ-Cloud Service Mesh:

    "dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]

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

בעיות כשחיבורים משתמשים בפרוטוקולים של שרת-קודם

באפליקציות מסוימות, כמו MySQL, נעשה שימוש בפרוטוקולים שבהם השרת שולח את המנה הראשונה. המשמעות היא שבחיבור הראשוני השרת שולח את הבייטים הראשונים. פרוטוקולים ואפליקציות כאלה לא נתמכים על ידי Cloud Service Mesh.

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

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

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

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

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

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

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