פתרון בעיות ב-Distributed Cloud במודל מחובר

‫Google עוקבת מרחוק אחרי החומרה של Google Distributed Cloud במודל מחובר ומבצעת בה תחזוקה. לצורך הזה, למהנדסי Google יש גישה Secure Shell ‏ (SSH) לחומרה של Distributed Cloud במודל מחובר. אם Google מזהה בעיה, מהנדס של Google יפנה אליכם כדי לפתור אותה. אם זיהיתם בעיה בעצמכם, פנו מיד לתמיכה של Google כדי לאבחן אותה ולפתור אותה.

קישוריות של מכונות שמחוברות ל-Distributed Cloud

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

בנוהל הזה נעשה שימוש במדדי Monitoring הבאים:

  • ‫Machine Connected (/machine/connected): מציין אם המכונה מחוברת ל- Google Cloud.

  • קישוריות רשת (/machine/network/connectivity): מציין אם לממשק הרשת הראשי של המחשב יש קישוריות לאינטרנט.

כדי להשלים את השלבים בקטע הזה, אתם צריכים לעמוד בדרישות המוקדמות הבאות:

  1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
  2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדים של Monitoring.
  3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לאמת את הקישוריות של המכונה

  1. עוברים אל Metrics Explorer:

    1. במסוף Google Cloud , עוברים לקטע Monitoring.

    2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

  2. בוחרים את סוג משאב היעד:

    1. בדף Metrics Explorer, עוברים לדף Queries.

    2. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Machine. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Machine.

    3. בתוצאות שמוחזרות, לוחצים על סוג המשאב Machine.

  3. מאמתים את החיבור של המחשב אל Google Cloud:

    1. בקטע Metric, מחפשים את הערך connected.

    2. בוחרים במדד Machine Connected (מכונה מחוברת). הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/connected.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

    4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% או Unhealthy, המחשב איבד את הקישוריות ל- Google Cloud בזמן שצוין.

  4. מאמתים את החיבור של המכונה לאינטרנט:

    1. בקטע Metric, מחפשים את הערך connectivity.

    2. בוחרים במדד קישוריות לרשת. הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/network/connectivity.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

    4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% לא תקין, המשמעות היא שהמחשב איבד את הקישוריות לאינטרנט בזמן שצוין.

הסבר על תוצאות האימות

בטבלה הבאה מוסברות התוצאות שמוחזרות ב-Metrics Explorer.

מצב המכונה אבחון רזולוציה
תקין
הערך של המדד 'המחשב מחובר' הוא 1
הערך של המדד 'קישוריות לרשת' הוא 1
 פעולה רגילה. אין.
מנותק
הערך של המדד 'המחשב מחובר' הוא 0
הערך של המדד 'קישוריות לרשת' הוא 1
 למחשב יש חיבור לאינטרנט, אבל הוא לא יכול להתחבר אל Google Cloud. בודקים את [כללי חומת האש](distributed-cloud/connected/1.11.0/docs/requirements#connected_management_and_monitoring_traffic) עבור שירותי Google ונקודות קצה של API. מוודאים שהסוכנים המחוברים של Distributed Cloud פועלים במחשב.
מבודד
הערך של המדד 'המחשב מחובר' הוא 0
הערך של המדד 'קישוריות לרשת' הוא 0
 למכונה אין קישוריות לאינטרנט. בודקים את כבל החשמל ואת כבל הרשת, את ההגדרה של הרשת המקומית ואת סטטוס ה-LED של המכונה. מאמתים את ההגדרות של ה-VLAN והניתוב.
לסירוגין
הערך של המדד 'המכונה מחוברת' משתנה לסירוגין בין 0 ל-1
הערך של המדד 'קישוריות לרשת' משתנה לסירוגין בין 0 ל-1
 חיבור לא יציב לרשת, אובדן מנות או זמן אחזור מוגזם. בודקים אם יש עומס ברשת המקומית או חומרה פגומה.

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

פגיעה בסשנים של BGP במשאבי Cloud Router שמשמשים לחיבורי VPN

חיבורי VPN ב-Distributed Cloud מסתמכים על סשנים של BGP שנוצרו ומנוהלים על ידי משאבי Cloud Router המתאימים, כדי לפרסם מסלולים בין אשכול מחובר ב-Distributed Cloud לבין Google Cloud. אם משנים את ההגדרה של משאב Cloud Router שמשויך לחיבור VPN של Distributed Cloud, יכול להיות שהחיבור יפסיק לפעול.

כדי לשחזר את ההגדרה הפגומה של סשן BGP ב-Cloud Router המושפע, מבצעים את השלבים הבאים:

  1. במסוף Google Cloud , מאתרים את השם של סשן ה-BGP הפגום. לדוגמה:

    INTERFACE=anthos-mcc-34987234

  2. מקבלים את כתובות ה-IP של BGP של ה-Cloud Router ושל BGP של הנתב השכן עבור סשן BGP פגום, וגם את ה-ASN של הנתב השכן שמשמש לחיבור VPN ב-Distributed Cloud שמושפע מהבעיה. לדוגמה:

    GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506

    אם מחקתם את סשן ה-BGP, תוכלו לקבל את המידע הזה מאשכול מחובר של Distributed Cloud:

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

      gcloud edge-cloud container clusters get-credentials CLUSTER_ID \
  --location REGION \
  --project PROJECT_ID

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫CLUSTER_ID: השם של אשכול היעד.
      • ‫REGION: Google Cloud האזור שבו נוצר אשכול היעד.
      • ‫PROJECT_ID: המזהה של Google Cloud פרויקט היעד.

    2. אחזור ההגדרה של משאב MultiClusterConnectivityConfig:

      kubectl get multiclusterconnectivityconfig -A

      הפקודה מחזירה פלט שדומה לזה:

       NAMESPACE     NAME                   LOCAL ASN              PEER ASN
 kube-system   MultiClusterConfig1    65505                   65506
 ```

    3. מקבלים את כתובת ה-IP של ה-BGP של הרשת השכנה, את כתובת ה-IP של Cloud Router ואת מספר ה-ASN של סשן ה-BGP:

      kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME

      מחליפים את MCC_CONFIG_NAME בשם של MultiClusterConfigResource שהתקבל בשלב הקודם.

      הפקודה מחזירה פלט שדומה לזה:

       ​​Spec:
 Asns:
   Peer:  65505
   Self:  65506 # GDCE ASN
 Tunnels:
   Ike Key:
     Name:       MCC_CONFIG_NAME-0
     Namespace:  kube-system
   Peer:
     Bgp IP:      169.254.208.73 # Cloud Router BGP IP
     Private IP:  34.157.98.148
     Public IP:   34.157.98.148
   Self:
     Bgp IP:      169.254.208.74 # GDCE BGP IP
     Private IP:  10.100.29.49
     Public IP:   208.117.254.68
 ```

  3. במסוף Google Cloud , מאתרים את השם, האזור וGoogle Cloud שם הפרויקט של מנהרת ה-VPN הפגומה. לדוגמה:

    VPN_TUNNEL=VPNTunnel1
REGION=US-East1
VPC_PROJECT_ID=VPC-Project-1

  4. מוחקים את סשן ה-BGP הפגום מההגדרה של Cloud Router.

  5. יוצרים ממשק חדש של Cloud Router:

    gcloud compute routers add-interface --interface-name=INTERFACE_NAME \
   --vpn-tunnel=TUNNEL_NAME \ 
   --ip-address=ROUTER_BGP_IP \
   --project=VPC_PROJECT_ID \
   --region=REGION \
   --mask-length=30

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INTERFACE_NAME: שם תיאורי שמזהה באופן ייחודי את הממשק הזה.
    • ‫TUNNEL_NAME: השם של מנהרת ה-VPN שקיבלתם בשלב הקודם.
    • ‫ROUTER_BGP_IP: כתובת ה-IP של BGP של Cloud Router שקיבלתם קודם בהליך הזה.
    • ‫VPC_PROJECT_ID: מזהה הפרויקט של ה-VPCGoogle Cloud שמשמש כיעד.
    • ‫REGION: האזור שבו נוצר פרויקט ה-VPC Google Cloud של היעד. Google Cloud

  6. יוצרים את הקישור בין רשתות שכנות באמצעות BGP:

    gcloud compute routers add-bgp-peer --interface=INTERFACE_NAME \
   --peer-name=TUNNEL_NAME \
   --region REGION \
   --project=VPC_PROJECT_ID \
   --peer-ip-address=GDCE_BGP_IP \
   --peer-asn=GDCE_BGP_ASN \
   --advertised-route-priority=100 \
   --advertisement-mode=DEFAULT

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INTERFACE_NAME: השם של הממשק שיצרתם בשלב הקודם.
    • ‫TUNNEL_NAME: השם של מנהרת ה-VPN שבה השתמשתם כדי ליצור את הממשק בשלב הקודם.
    • ‫REGION: האזור שבו נוצר פרויקט ה-VPC Google Cloud של היעד. Google Cloud
    • ‫VPC_PROJECT_ID: מזהה הפרויקט של ה-VPCGoogle Cloud שמשמש כיעד.
    • ‫GDCE_BGP_IP: כתובת ה-IP של BGP עמית ב-Distributed Cloud שקיבלתם קודם בהליך הזה.
    • ‫GDCE_BGP_ASN: מספר מערכת אוטונומית (ASN) של BGP עמית ב-Distributed Cloud, שקיבלתם קודם בהליך הזה.

בשלב הזה, סשן ה-BGP חוזר להיות פעיל.

מכונות וירטואליות תקועות במצב Pending

עומס עבודה של מכונה וירטואלית יכול להיתקע במצב Pending ולא להתווסף לתזמון בצומת אם קורה אחד מהדברים הבאים:

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

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

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

  2. קבלת מידע על המכונה הווירטואלית שהושפעה:

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫VM_NAME: השם של המכונה הווירטואלית של היעד.
    • ‫NAMESPACE: מרחב השמות של המכונה הווירטואלית של היעד.

    הפקודה מחזירה פלט שדומה לזה:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

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

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

אין מספיק משאבים

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

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

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

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

צמתים עם כתמים

יכול להיות שתופיע הודעה שמציינת שהצומת של היעד מוכתם. לדוגמה:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

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

  1. משתמשים בפקודה הבאה כדי לבדוק אם יש כתמים בצומת:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    הפקודה מחזירה פלט שדומה לזה:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. מבצעים אחת מהפעולות הבאות:

    • אם יש כתמים לא צפויים, צריך להסיר אותם כמו שמתואר במאמר Taints and Tolerations.
    • אם יש taints צפויים, מוסיפים את ה-tolerations המתאימים להגדרות של המכונה הווירטואלית, כמו שמתואר במאמר Taints and Tolerations.

תקלות באחסון

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

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

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

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

  1. כדי לקבל את הסטטוס של התביעות לנפח אחסון מתמשך (PVC) במרחב השמות של המכונה הווירטואלית המושפעת, משתמשים בפקודה הבאה:

    kubectl get pvc -n NAMESPACE

    מחליפים את NAMESPACE בשם של מרחב השמות של היעד.

    הפקודה מחזירה פלט שדומה לזה:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. מוודאים של-PVC המתאים יש סטטוס Bound. אם הסטטוס הוא Pending, מערכת המשנה של האחסון לא הצליחה להקצות את נפח האחסון. במקרים כאלה, צריך לפתור את הבעיה בהגדרת מערכת המשנה של האחסון ולוודא שזמין StorageClass מתאים.