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

‫Google Distributed Cloud nettest מזהה בעיות בקישוריות באובייקטים של Kubernetes באשכולות, כמו Pods,‏ Nodes,‏ Services וחלק מהיעדים החיצוניים. ‫nettest לא בודק חיבורים מיעדים חיצוניים ל-Pods, לצמתים או לשירותים. במאמר הזה מוסבר איך לפרוס ולהפעיל את nettest באמצעות אחד מהמניפסטים, nettest.yaml או nettest_rhel.yaml, במאגר anthos-samples ב-GitHub. משתמשים בפקודה nettest_rhel.yaml אם מריצים את Google Distributed Cloud ב-Red HatEnterprise 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 על ידי הרצת הפקודה הבאה למערכת ההפעלה שלכם. כשמפעילים את 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 של השירות מופיעים ברשומות של בקשות לבדיקת תקינות (probe) ביומן בפורמט 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 המניפסט כדי להריץ מחדש את בדיקות הקישוריות.

לדוגמה, כדי להריץ מחדש את 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. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל:

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