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

‫Google Distributed Cloud nettest מזהה בעיות בקישוריות באובייקטים של Kubernetes באשכולות, כמו Pods,‏ Nodes,‏ Services וחלק מהיעדים החיצוניים. ‫nettest לא בודק חיבורים מיעדים חיצוניים ל-Pods, ל-Nodes או לשירותים. במאמר הזה נסביר איך לפרוס ולהפעיל את nettest באמצעות אחד מהמניפסטים, nettest.yaml או nettest_rhel.yaml, במאגר anthos-samples ב-GitHub. משתמשים בפקודה nettest_rhel.yaml אם מריצים את Google Distributed Cloud ב-Red Hat Enterprise Linux‏ (RHEL). משתמשים ב-nettest.yaml אם מפעילים את Google Distributed Cloud ב-Ubuntu.

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

מידע על 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 מרחב שמות וחשבון שירות ייעודי (יחד עם ClusterRole ו-ClusterRoleBinding) כדי לבודד את nettest ממשאבי אשכול אחרים.

הרצת בדיקת רשת

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

ב-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 כתובת ה-IP של ה-Pod: החיבור אל או מ-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-service-clusterip).

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

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

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

לדוגמה, כדי להריץ מחדש את 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

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

אם אתם צריכים עזרה נוספת, אתם יכולים לפנות אל