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