בדיקת הקישוריות של האשכול באמצעות nettest

ב-Google Distributed Cloud nettest אתם יכולים לזהות בעיות קישוריות בין אובייקטים של Kubernetes באשכולות שלכם, כולל פודים, צמתים, שירותים ויעדים חיצוניים. nettest לא בודק חיבורים נכנסים מיעדים חיצוניים לאובייקטים פנימיים באשכול.

אתם יכולים לפרוס ולהריץ את nettest באמצעות מניפסטים ממאגר ה-GitHub‏ anthos-samples, ואז לפרש את היומנים שנוצרו כדי לאבחן כשלים בתקשורת של האשכול.

מידע על nettest

כלי האבחון של nettest מורכב מהאובייקטים הבאים של Kubernetes. כל אובייקט מצוין בקובצי המניפסט של nettest ב-YAML.

  • ‫cloudprober: ‏DaemonSet ושירות שאחראים לאיסוף סטטוס החיבור לרשת, כמו שיעור השגיאות וזמן האחזור.
  • ‫echoserver: ‏DaemonSet ושירות שאחראים להגיב ל-cloudprober, ולספק לו את המדדים לקישוריות לרשת.
  • ‫nettest: Pod שמכיל את הקונטיינרים prometheus ו-nettest.
    • ‫prometheus אוסף מדדים מ-cloudprober.
    • nettest שולח שאילתות ל-prometheus ומציג את תוצאות בדיקת הרשת ביומן.
  • ‫nettest-engine: ConfigMap להגדרת הקונטיינר nettest ב-Pod של nettest.

במניפסט מצוין גם מרחב השמות של nettest ו-ServiceAccount ייעודי (יחד עם ClusterRole ו-ClusterRoleBinding) כדי לבודד את nettest ממשאבי אשכול אחרים.

הרצת nettest

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

ב-Ubuntu:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml

ל-RHEL:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest_rhel.yaml

איך מקבלים את תוצאות הבדיקה

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

kubectl -n nettest logs nettest -c nettest

בזמן ש-nettest פועל, הוא שולח הודעות כמו אלה אל stdout:

I0413 03:33:04.879141       1 collectorui.go:130] Listening on ":8999"
I0413 03:33:04.879258       1 prometheus.go:172] Running prometheus controller
E0413 03:33:04.879628       1 prometheus.go:178] Prometheus controller: failed to
retries probers: Get "http://127.0.0.1:9090/api/v1/targets": dial tcp 127.0.0.1:9090:
connect: connection refused

אם nettest פועל בהצלחה בלי לזהות כשלים בקישוריות, מופיעה רשומת היומן הבאה:

I0211 21:58:34.689290       1 validate_metrics.go:78] Metric validation passed!

אם nettest מצא בעיות בחיבור, הוא כותב רשומות ביומן כמו אלה:

E0211 06:40:11.948634       1 collector.go:65] Engine error: step validateMetrics failed:
"Error rate in percentage": probe from "10.200.0.3" to "172.26.115.210:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "10.200.0.3" to "172.26.27.229:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "192.168.3.248" to "echoserver-hostnetwork_10.200.0.2_8080"
has value 2.007046, threshold is 1.000000

למרות שסף ברירת המחדל הוא אחוז אחד (1.000000), אפשר להתעלם משיעורי שגיאות של עד חמישה אחוזים. לדוגמה, שיעור השגיאות בקישוריות מכתובת ה-IP‏ 192.168.3.248 ל-echoserver-hostnetwork_10.200.0.2_8080 בדוגמה הקודמת הוא בערך שני אחוזים (2.007046). זו דוגמה לדיווח על בעיית קישוריות שאפשר להתעלם ממנה.

פירוש תוצאות הבדיקה

כשההרצה של nettest מסתיימת ונמצאת בעיית קישוריות, הרשומה הבאה מופיעה ביומני ה-Pod של nettest:

"Error rate in percentage": probe from {src} to {dst} has value 100.000000, threshold is 1.000000

כאן, {src} ו-{dst} יכולים להיות:

  • ‫echoserver Pod IP: החיבור אל Pod בצומת או ממנו.
  • כתובת ה-IP של הצומת: החיבור אל הצומת או ממנו.
  • כתובת ה-IP של השירות (פרטים בהמשך)

בנוסף, {dst} יכול להיות גם:

  • ‫google.com: חיבור חיצוני.
  • ‫dns: החיבור לשירות שאינו של hostNetwork באמצעות DNS, כלומר echoserver-non-hostnetwork.nettest.svc.cluster.local.

    הפרטים של כתובת ה-IP של השירות נמצאים ברשומות בדיקה בפורמט JSON ביומן, כמו בדוגמה הבאה. בדוגמה הבאה של בדיקה, 172.26.27.229:80 היא הכתובת של service-clusterip. יש שתי בדיקות עם הערך הזה של targets, אחת ל-Pod‏ (pod-service-clusterip) ואחת ל-Node‏ (node-service-clusterip).

    probe {
      name: "node-service-clusterip"
      …
      targets {
        host_names: "172.26.27.229:80"
      }
    

אימות התיקונים

אחרי שטיפלתם בכל בעיות הקישוריות שדווחו, הסירו את ה-Pod של nettest והפעילו מחדש את המניפסט של nettest כדי להריץ שוב את בדיקות הקישוריות.

לדוגמה, כדי להריץ מחדש את nettest ב-Ubuntu, מריצים את הפקודות הבאות:

kubectl -n nettest delete pod nettest
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml

פינוי נפח של nettest

כשמסיימים את הבדיקה, מריצים את הפקודות הבאות כדי להסיר את כל המשאבים של nettest:

kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest

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

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

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