פתרון בעיות בחיבור ל-Google

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

Network Connectivity Gateway

בקטע הזה מופיעים טיפים לפתרון בעיות שקשורות ל-Network Connectivity Gateway.

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל המקורות הבאים:
  • דרישות לפתיחת בקשת תמיכה.
  • כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, היומנים והמדדים.
  • רכיבים נתמכים.

מוודאים ש-Pods של בקר ושער פועלים

  • מציגים את רשימת ה-Pods של Network Connectivity Gateway:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get pods \
    --namespace kube-system | grep ncg

    מחליפים את CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של האשכול.

    בפלט, מוודאים שמופיעים Pod של בקר ו-Pod של שער. השם של ה-Pod של בקר התנועה מתחיל ב-ncg-controller, והשם של ה-Pod של שער הכניסה מתחיל ב-ncgd. לדוגמה:

    ncg-controller-5f5d489b68-r87pp     1/1     Running
ncgd-gvl76                          1/1     Running

    רושמים בצד את השם של ה-Pod של השער. תצטרכו אותו לפקודות שונות לפתרון בעיות.

בדיקת היומנים של ה-Pod של השער

  • בודקים אם יש שגיאות ביומנים של Gateway Pod:

    kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD \
    --namespace kube-system

    מחליפים את GATEWAY_POD בשם של ה-Pod של השער.

הפעלת ncgcli בתוך ה-Pod של שער

ל-Pod של השער יש כלי שורת פקודה בשם ncgcli שבעזרתו אפשר לקבל מידע על השער ועל תעבורת הנתונים במנהרות.

  • משתמשים בפקודה הבאה כדי להריץ את ncgcli ב-Pod של שער:

    kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it GATEWAY_POD \
    --namespace kube-system -- ncgCLI_COMMAND

    מחליפים את ncgCLI_COMMAND בפקודה ncgcli.

    לדוגמה:

    kubectl --kubeconfig my-kubeconfig exec ncgd-6hkk2 --namespace kube-system \
    -- ncgcli --help

בקטעים הבאים מופיעות עוד דוגמאות לפקודות ncgcli.

מנהרת IPsec לא הופעלה

  • בודקים את הסטטוס של המשאב המותאם אישית NetworkConnectivityGateway:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get NetworkConnectivityGateway \
    --namespace kube-system --output yaml

    בודקים בפלט אם מופיע Status: Healthy. לדוגמה:

    apiVersion: networking.gke.io/v1alpha1
kind: NetworkConnectivityGateway
metadata:
  namespace: kube-system
  name: default
spec:
status:
  CurrNode: worker1-node
  CreatedTime: 2021-09-07T03:18:15Z
  LastReportTime: 2021-09-21T23:57:54Z
  Status:  Healthy

  • בודקים את הסטטוס של OverlayVPNTunnel המשאבים המותאמים אישית:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \
    --namespace kube-system --output yaml

  • בודקים את סטטוס המנהרות מתוך ה-Pod של השער:

    ncgcli overlay peers show

מידע נוסף זמין במאמר בנושא פתרון בעיות ב-Cloud VPN.

יצירת סשן BGP נכשלה

מוודאים שהשתמשתם בכתובות IP מקומיות, כמו 169.254.1.2 ו-169.254.2.2, עבור סשנים של BGP בין Cloud Router לבין gateway Pod באשכול.

  • בדיקת הסטטוס של סשנים של BGP:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayBGPPeer \
    --namespace kube-system --output yaml

  • בודקים את הסטטוס של סשני ה-BGP מתוך ה-Pod של השער:

    ncgcli overlay routes show

מידע נוסף על פתרון בעיות בסשנים של BGP זמין במאמרים הבאים:

בעיות בהעברת תנועה גם אם המנהרה פעילה

אם העברת התעבורה נכשלת, מריצים את הפקודה ncgcli inside the gateway Pod כדי לבדוק את הסטטוס של המנהרות, הניתוב ותכנות מישור הנתונים.

  • מוודאים שמנהרת IPsec ל-peer נוצרה:

    ncgcli overlay peers show

  • מוודאים שהמסלולים של שכבת העל הוחלפו באמצעות BGP ושהם הופנו למנהרת ה-IPsec המתאימה:

    ncgcli overlay routes show

  • הצגת מסלולים שתוכנתו במישור הנתונים, והפלט צריך לכלול מסלולי שכבת-על:

    ncgcli fast-path routes show

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

יחידת השידור המקסימלית (MTU) היא הגודל, בבייטים, של החבילה הגדולה ביותר שפרוטוקול של שכבת רשת תומך בה, כולל כותרות ונתונים. אם יש בעיות בתעבורה שנובעות ממגבלות MTU של רשת הבסיס, אפשר להגדיר את ה-MTU במשאב המותאם אישית OverlayVPNTunnel. ה-MTU שמוגדר כברירת מחדל למנהרות הוא 1,380 בייטים.

כדי לשנות את ה-MTU של המנהרות:

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

    kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \
    --namespace kube-system --output yaml

    המקטע status צריך להיראות כמו בדוגמה הבאה:

    status:
  IfName: ipsec2
  LastTransition: "2022-06-16T07:13:28Z"
  SLA:
    DiscoveredMTU: 1300
    Jitter(ms): 1
    Latency(ms): 26
    Loss(%): "0.00"

    אם הערך של status.SLA.DiscoveredMTU קטן מערך ברירת המחדל 1380, צריך לפעול לפי השלבים הבאים כדי לשנות את הערך של Spec.mtu במשאבים המותאמים אישית OverlayVPNTunel כך שיתאים לו.

  2. פותחים את המשאבים המותאמים אישית OverlayVPNTunnel לעריכה באמצעות הפקודה kubectl edit:

    kubectl --kubeconfig CLUSTER_KUBECONFIG edit OVERLAY_VPN_TUNNEL_NAME
    --namespace kube-system --output yaml

    כדי למנוע אובדן מנות, צריך להגדיר את אותו MTU לשני המשאבים המותאמים אישית OverlayVPNTunnel שבהם נעשה שימוש ב-Network Connectivity Gateway.

  3. מגדירים את הערך mtu כך שיתאים לערך DiscoveredMTU מהשלב הראשון:

    apiVersion: networking.gke.io/v1alpha1
  kind: OverlayVPNTunnel
  metadata:
    name: vpc2
    namespace: kube-system
  Spec:
    mtu: 1300
    ikeKey:
      name: ike-key
      namespace: kube-system
    localTunnelIP: 169.254.0.2
    peer:
      publicIP: 34.100.10.10
    self:
      publicIP: 70.32.151.5

  4. כדי להחיל את השינויים, שומרים את העריכה וסוגרים את הכלי לעריכה.

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

צפייה בזרימת התנועה ובנתונים סטטיסטיים ברמת האפליקציה

כדי לראות את זרימת התנועה ואת הנתונים הסטטיסטיים, מריצים את הפקודה ncgcli inside the gateway Pod.

  • כדי לראות באופן מיידי את הזרימות ואת התנועה באפליקציות:

    ncgcli forwarding flows top

  • לנתונים סטטיסטיים מצטברים ברמת התהליך:

    ncgcli forwarding flows aggregates show

  • לנתונים סטטיסטיים מצטברים ברמת הממשק:

    ncgcli interfaces statistics show

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל המקורות הבאים:
  • דרישות לפתיחת בקשת תמיכה.
  • כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, היומנים והמדדים.
  • רכיבים נתמכים.