פתרון בעיות ברשת ב-Google Distributed Cloud

בדף הזה מוסבר איך לפתור בעיות ברשת ב-Google Distributed Cloud. בנוסף, מוצג מידע כללי והנחיות לפתרון בעיות, וגם כלים מומלצים. בנוסף, יש כאן מידע על פתרון בעיות ב-DNS וכמה בעיות נפוצות ב-Calico, ב-Seesaw וב-MetalLB.

פתרון בעיות בחיבור לרשת

התשתית של רשתות GKE Enterprise מתבססת על תשתית הרשת הפיזית שלכם. לדוגמה, Seesaw או MetalLB מסתמכים על המתגים שלכם שמכבדים ARP ללא תמורה, איזון עומסים בחבילה עם פרוטוקול Border Gateway ‏ (BGP) מסתמך על הנתבים שלכם, וכל הצמתים צריכים להיות מסוגלים לתקשר זה עם זה. אם נתקלתם בבעיה ברשת באשכולות GKE, אתם צריכים לזהות אם הבעיה היא ברכיבי GKE Enterprise או בתשתית שלכם.

קודם צריך לקבוע את היקף הבעיה, ואז לנסות לזהות את הרכיבים המושפעים. היקף הבעיה יכול להיות אחת משלוש קטגוריות: הנושא (מאיפה), היעד (לאן) ושכבת הרשת.

הערך של scope of subject יכול להיות אחד מהערכים הבאים:

  • כל הצמתים (או hostNetwork Pod) ברמת האשכול.
  • כל ה-Pods באשכול.
  • כל ה-Pods בצומת יחיד או בקבוצת צמתים.
  • כל ה-Pods מאותו Deployment או DaemonSet.
  • לקוח מחוץ לאשכול.

הערך של scope of target יכול להיות אחד או יותר מהערכים הבאים:

  • כל שאר כתובות ה-IP של ה-Pod מאותו אשכול.
  • כל כתובות ה-IP האחרות של ה-Pod מאותו צומת.
  • כתובת ה-VIP של שירות ClusterIP מאותו אשכול.
  • כתובת ה-VIP של שירות LoadBalancer מאותו אשכול.
  • מאזן עומסים של שכבת כניסה 7 (Istio).
  • צמתים אחרים באותו אשכול.
  • שם DNS פנימי (לדוגמה, *.svc.cluster.local).
  • שם DNS חיצוני (לדוגמה, google.com).
  • יחידות מחוץ לאשכול.
  • ישויות באינטרנט.

שכבת הרשת יכולה להיות אחת או יותר מהאפשרויות הבאות:

  • בעיות בשכבת הקישור בשכבה 2, כמו מערכת שכנה, ARP או NDP.
  • בעיות בניתוב של כתובות IP בשכבה 3.
  • בעיות בנקודת קצה (endpoint) של TCP או UDP בשכבה 4.
  • בעיות ב-HTTP או ב-HTTPS בשכבה 7.
  • בעיות בפענוח DNS.

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

בעיות ב-Ingress

אם הנושא הוא לקוח מחוץ לאשכול והוא לא הצליח להתחבר לשירות LoadBalancer, זו בעיה בקישוריות צפון-דרום. בתרשים הבא מוצגת דוגמה שבה התנועה הנכנסת עוברת דרך המערך משמאל לימין, והתנועה החוזרת עוברת דרך המערך מימין לשמאל. ב-Seesaw זה שונה, כי התנועה החוזרת מדלגת על מאזן העומסים וחוזרת ישירות ללקוח:

תנועת נתונים נכנסת עוברת מהמשתמש לתשתית הפיזית, דרך מאזן עומסים ל-anetd / kube-proxy, ואז אל ה-backend. ב-Seesaw, תעבורת הנתונים היוצאת מדלגת על מאזן העומסים.

אם יש בעיה בזרימת התנועה הזו, אפשר להשתמש בתרשים הזרימה הבא לפתרון בעיות כדי לזהות את מקור הבעיה:

פתרון בעיות בתעבורת נתונים נכנסת (ingress) לרשת על ידי בדיקת כל שלב שחבילה עוברת בדרך בסביבה שלכם. בודקים אם הפעולות והקישוריות המתאימות קיימות לאורך הדרך.

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

  • האם החבילה יוצאת מהלקוח? אם לא, כנראה שיש בעיה בתשתית הרשת.
  • האם אתם משתמשים במאזן העומסים של Seesaw? אם כן, האם החבילה מגיעה לצומת Seesaw, והאם פרוטוקול ARP נשלח בצורה תקינה? אם לא, כנראה שיש בעיה בתשתית הרשת.
  • האם אתם משתמשים ב-MetalLB? אם כן, האם המנה מגיעה לצומת של LB, והאם ARP נשלח בצורה תקינה? אם לא, כנראה שיש בעיה בתשתית הרשת.
  • האם אתם משתמשים ב-F5 BIG-IP? אם כן, בדקתם אם יש בעיות ב-F5?
  • האם תרגום כתובת הרשת (NAT) מתבצע בצורה נכונה? אם לא, כנראה שיש לכם בעיה ב-kube-proxy או ב-Dataplane V2.
  • האם המנה מגיעה לצומת העובד? אם לא, כנראה שיש בעיה ב-Pod-to-Pod של Calico / Dataplane v2.
  • האם המנה מגיעה ל-Pod? אם לא, כנראה שיש בעיה בהעברה מקומית של Calico / Dataplane v2.

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

האם החבילה יוצאת מהלקוח?

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

  1. משתמשים ב-tcpdump כדי לבדוק את החבילה כשהיא יוצאת מהלקוח לשירות היעד:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    אם לא רואים תנועה יוצאת, זה המקור לבעיה.

האם החבילה מגיעה לצומת Seesaw?

אם אתם משתמשים ב-Seesaw, תוכלו לעיין במסמכי התיעוד של גרסה 1.16, למצוא את צומת הראשי ואז להתחבר לצומת באמצעות SSH.

  1. משתמשים ב-tcpdump כדי לבדוק אם החבילות שהתקבלו הגיעו לצומת Seesaw:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    אם לא רואים תנועה נכנסת, זה המקור לבעיה.

האם החבילה מגיעה לצומת LoadBalancer?

אם משתמשים ב-MetalLB כמאזן העומסים:

  1. בודקים את היומן metallb-controller כדי לראות איזה צומת של מאזן עומסים משרת את ה-VIP של השירות:

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. מתחברים לצומת באמצעות SSH.

  3. בצומת MetalLB, משתמשים בפקודה tcpdump כדי לבדוק את התנועה:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    ב-ManualLB, התנועה יכולה להגיע לכל צומת. בהתאם להגדרות של איזון העומסים, אפשר לבחור צומת אחד או כמה צמתים. כדי לבדוק את התנועה, משתמשים ב-tcpdump:

    tcpdump -ni any host NODE_IP and port NODE_PORT

    הפקודה שונה בין סוגים של איזון עומסים, כי MetalLB ו-Seesaw לא מבצעים NAT לפני העברת המנות לצמתים.

    אם לא רואים תנועה שנכנסת לאף צומת, זה המקור לבעיה.

האם יש בעיה ב-F5 BIG-IP?

כדי לפתור בעיות ב-F5 BIG-IP, אפשר לעיין באחד מהקטעים הבאים בנושא F5 Service doesn't receive traffic.

האם פרוטוקול ה-ARP נשלח בצורה נכונה?

צומת מאזן העומסים של MetalLB או Seesaw מסתמך על ARP כדי לפרסם את ה-VIP של השירות. אם תגובת ה-ARP נשלחת בצורה תקינה, אבל התנועה לא נכנסת, זה סימן לבעיה בתשתית הפיזית של הרשת. סיבה נפוצה לבעיה הזו היא שחלק מהתכונות המתקדמות של שכבת הנתונים מתעלמות מתגובת ARP בפתרונות של רשת מוגדרת בתוכנה (SDN).

  1. משתמשים ב-tcpdump כדי לזהות תגובות ל-ARP:

    tcpdump -ni any arp

    נסו למצוא את ההודעה שמפרסמת את ה-VIP שנתקלתם בו בבעיות.

    • ב-Seesaw, בקשות ARP מיותרות נשלחות לכל כתובות ה-VIP. אמורות להופיע הודעות ARP לכל כתובת VIP כל 10 שניות.

    • ב-MetalLB, לא נשלח ARP מיותר. התדירות שבה מוצגת תגובה תלויה במועד שבו מכשיר אחר, כמו מתג ToR או מתג וירטואלי, שולח בקשת ARP.

האם מתבצע NAT?

‫Dataplane v2 / kube-proxy מבצע תרגום של כתובת הרשת של היעד (תרגום כתובת רשת של היעד או DNAT) כדי לתרגם את כתובת ה-IP של ה-VIP של היעד לכתובת IP של Pod בקצה העורפי. אם אתם יודעים איזה צומת הוא הקצה העורפי של מאזן העומסים, מתחברים לצומת באמצעות SSH.

  1. משתמשים ב-tcpdump כדי לבדוק אם כתובת ה-VIP של השירות מתורגמת בצורה נכונה:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. ב-Dataplane v2, אפשר גם להתחבר ל-pods של anetd ולהשתמש בכלי הניפוי באגים המוטמעים של Cilium:

    cilium monitor --type=drop

מידע נוסף זמין באחד מהקטעים הבאים בנושא בעיות ב-Dataplane v2 / Cilium.

האם המנה מגיעה לצומת עובד?

בצמתי העובדים, החבילה מגיעה לממשק החיצוני ואז מועברת ל-Pods.

  1. בודקים אם המנה מגיעה לממשק החיצוני, שבדרך כלל נקרא eth0 או ens192, באמצעות tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

מכיוון ש-Service backends רגילים מכילים כמה Pods בצמתים שונים, יכול להיות שיהיה קשה לפתור בעיות בצומת מסוים. פתרון נפוץ הוא לתעד את הבעיה למשך זמן מספיק כדי שחלק מהמנות יגיעו בסופו של דבר, או להגביל את מספר השרתים העורפיים לאחד.

אם המנה לא מגיעה לצומת העבודה, זה מעיד על בעיה בתשתית הרשת. כדאי לבדוק עם צוות תשתית הרשת למה המנה נפסלת בין צמתי LoadBalancer לצמתי worker. דוגמאות לבעיות נפוצות:

  • בודקים את היומנים של הרשת מוגדרת התוכנה (SDN). לפעמים, ה-SDN עלול להפיל מנות מסיבות שונות, כמו פילוח, סכום ביקורת שגוי או מניעת זיוף.
  • כללי חומת אש שמסננים מנות שהיעד שלהן הוא כתובת ה-IP והיציאה של ה-Pod בקצה העורפי.

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

לכל Pod יש זוגות של ממשקי Ethernet וירטואליים, שפועלים כמו צינורות. מנות שנשלחות לקצה אחד של הממשק מתקבלות מהקצה השני של הממשק. אחד הממשקים מועבר למרחב השמות של הרשת של ה-Pod, ומשנה את השם שלו ל-eth0. הממשק השני נשמר במרחב השמות של המארח. ל-CNI שונים יש סכימות שונות. ב-Dataplane v2, השם של הממשק הוא בדרך כלל lxcxxxx. לשמות יש מספרי ממשק עוקבים, כמו lxc17 ו-lxc18. אפשר לבדוק אם המנה מגיעה ל-Pod באמצעות tcpdump, או לציין את הממשק:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

אם החבילה מגיעה לצומת אבל לא מגיעה ל-Pod, צריך לבדוק את טבלת הניתוב באופן הבא:

ip route

בדרך כלל, לכל Pod צריכה להיות רשומת ניתוב שמנתבת את כתובת ה-IP של ה-Pod לממשק lxc. אם הרשומה חסרה, בדרך כלל זה אומר שיש שגיאה בנתיב הנתונים של CNI. כדי לזהות את שורש הבעיה, בודקים את היומנים של CNI DaemonSet.

בעיות בתעבורת נתונים יוצאת (egress)

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

תעבורת הנתונים היוצאת עוברת מה-Pod דרך הממשק החיצוני של המארח אל התשתית הפיזית, ואז אל השירות החיצוני.

  1. כדי לוודא שהחבילה היוצאת מוסתרת בצורה נכונה ככתובת ה-IP של הצומת, בודקים את השירות החיצוני (שכבה 4).

    כתובת ה-IP של המקור של חבילת הנתונים צריכה להיות ממופה מכתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת באמצעות תרגום כתובות רשת של המקור (source NAT או SNAT). ב-Dataplane v2, התהליך הזה מתבצע באמצעות ebpf שנטען בממשק חיצוני. ‫Calico משתמש בכללי iptables.

    משתמשים ב-tcpdump כדי לבדוק אם כתובת ה-IP של המקור מתורגמת בצורה נכונה מכתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    אם הפקודה tcpdump מראה שהמנות מוסוות בצורה נכונה אבל השירות המרוחק לא מגיב, צריך לבדוק את החיבור לשירות החיצוני בתשתית שלכם.

  2. אם המיסוך של החבילות היוצאות מתבצע בצורה נכונה ככתובת ה-IP של הצומת, צריך לבדוק את הקישוריות של המארח החיצוני (שכבה 3) באמצעות tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    במקביל להרצת הפקודה tcpdump, מריצים פינג מאחד מה-Pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

    אם לא רואים תגובות פינג, צריך לבדוק את החיבור לשירות החיצוני בתשתית.

בעיות בתוך האשכול

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

  1. ב-Dataplane v2, בודקים את הקישוריות של הצומת מהצומת הנוכחי לכל הצמתים האחרים באותו אשכול. מתוך ה-Pod‏ anetd, בודקים את סטטוס התקינות:

    cilium status --all-health

    שימוש ב-Google Distributed Cloud במצב ניתוב ישיר. צריכה להופיע רשומה אחת של מסלול לכל צומת באשכול, כמו שמוצג בדוגמה הבאה:

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    אם מסלול צפוי חסר בצומת, החיבור לצומת הזה ינותק.

בעיות בשכבת הרשת

זיהוי שכבת הרשת שבה מתרחשת בעיית הקישוריות הוא שלב חשוב. הודעת שגיאה כמו "בעיה בקישוריות ממקור ליעד" לא מספקת מספיק מידע כדי לפתור את הבעיה, שיכולה להיות שגיאה באפליקציה, בעיה בניתוב או בעיה ב-DNS. הבנה באיזו שכבה הבעיה מתרחשת עוזרת לתקן את הרכיב הנכון.

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

  • שגיאות HTTP מציינות שמדובר בבעיה בשכבה 7.
    • קודי HTTP‏ 40x, 50x או שגיאות ב-TLS handshake מציינים שהכול פועל כרגיל בשכבה 4.
  • שגיאות "החיבור אופס על ידי עמית" מצביעות על בעיה בשכבה 4.
    • הרבה פעמים, השקע המרוחק לא יכול להסכים עם המצב הנוכחי של חיבור ולכן שולח מנה מסוג RESET. יכול להיות שההתנהגות הזו נובעת מטעות במעקב אחר חיבורים או ב-NAT.
  • השגיאות No route to host (אין מסלול למארח) ו-Connection timeout (זמן קצוב לתפוגה של החיבור) הן בדרך כלל בעיה בשכבה 3 או בשכבה 2.
    • השגיאות האלה מציינות שלא ניתן לנתב את החבילה ליעד בצורה תקינה.

כלים שימושיים לפתרון בעיות

חבילות DaemonSet שקשורות לרשת פועלות בצמתים שלכם, ויכול להיות שהן הגורם לבעיות בקישוריות. עם זאת, הגדרה שגויה של הצמתים, המתגים בחלק העליון של המתקן (ToR), נתבי הליבה או חומות האש יכולה גם לגרום לבעיות. אתם יכולים להשתמש בכלים הבאים כדי לקבוע את היקף הבעיה או השכבה שבה היא מתרחשת, וכדי להבין אם הבעיה היא בצמתים של GKE Enterprise או בתשתית הפיזית שלכם.

פינג

הפקודה Ping פועלת בשכבה 3 (שכבת ה-IP) ובודקת את הנתיב בין מקור ליעד. אם הפקודה ping לא מצליחה להגיע ליעד, לרוב הבעיה היא בשכבה 3.

עם זאת, לא לכל כתובות ה-IP אפשר לשלוח פינג. לדוגמה, אי אפשר לבצע פינג לחלק מכתובות ה-VIP של מאזני עומסים אם מדובר במאזן עומסים טהור בשכבה 4. ClusterIP הוא דוגמה למצב שבו ה-VIP לא מחזיר תגובה לפינג. ברמה 4, השירות הזה מחזיר תגובת פינג רק כשמציינים מספר יציאה, כמו VIP:port.

מאזני העומסים BGPLB,‏ MetalLB ו-Seesaw ב-Google Distributed Cloud פועלים בשכבה 3. אפשר להשתמש בפקודה ping כדי לבדוק את הקישוריות. למרות שהמצב שונה ב-F5, גם שם יש תמיכה ב-ICMP. אפשר להשתמש בפינג כדי לבדוק את הקישוריות ל-F5 VIP.

Arping

‫Arping דומה ל-ping, אבל הוא פועל בשכבה 2. לבעיות בשכבה 2 ובשכבה 3 יש לרוב הודעות שגיאה דומות מהאפליקציות. הפקודות arping ו-ping יכולות לעזור להבחין בין הבעיות. לדוגמה, אם המקור והיעד נמצאים באותה רשת משנה, אבל אי אפשר לבצע arping ליעד, זו בעיה בשכבה 2.

אם הפקודה arping <ip> מסתיימת ללא שגיאות, היא מחזירה את כתובת ה-MAC של היעד. בשכבה 2, הכתובת הזו מצביעה בדרך כלל על בעיה בתשתית הפיזית. הבעיה הזו היא הגדרה שגויה של מתג וירטואלי.

הפקודה arping יכולה לזהות גם התנגשויות של כתובות IP. קונפליקט של כתובות IP מתרחש כששתי מכונות מוגדרות להשתמש באותה כתובת IP באותה רשת משנה, או כשמכונה פיזית אחרת משתמשת בכתובת IP וירטואלית. סכסוכי כתובות IP עלולים ליצור בעיות לסירוגין שקשה לפתור. אם הפקודה arping <ip> מחזירה יותר מכתובת MAC אחת, זה מצביע על כך שיש התנגשות בין כתובות IP.

אחרי שמקבלים את כתובת ה-MAC מ-arping, אפשר להשתמש בכתובת https://maclookup.app/ כדי לחפש את היצרן של כתובת ה-MAC. לכל יצרן יש קידומת MAC, כך שאפשר להשתמש במידע הזה כדי לקבוע איזה מכשיר מנסה להשתמש באותה כתובת IP. לדוגמה, VMware היא הבעלים של הבלוק 00:50:56, ולכן כתובת MAC‏ 00:50:56:xx:yy:zz היא מכונה וירטואלית בסביבת vSphere.

iproute2

ל-ip CLI של iproute2 יש הרבה פקודות משנה שימושיות, כמו הפקודות הבאות:

  • ‫ip r: הדפסת טבלת הניתוב
  • ‫ip n: הדפסת טבלת השכנים למיפוי כתובת IP לכתובת MAC
  • ‫ip a: הדפסת כל הממשקים במחשב

מסלול חסר או רשומה חסרה בטבלת השכנים עלולים לגרום לבעיות בקישוריות מהצומת. ‫Anetd ו-Calico מנהלים את טבלת הניתוב ואת טבלת השכנים. הגדרה שגויה בטבלאות האלה עלולה לגרום לבעיות בקישוריות.

‫Cilium / Hubble CLI ל-Dataplane v2

לכל anetd Pod יש כמה כלים שימושיים לניפוי באגים לבעיות קישוריות:

  • cilium monitor --type=drop
    • הדפסת היומן לכל מנה (packet) שמופלת על ידי anetd / Cilium.
  • hubble observe
    • הדפסת כל החבילות שעוברות דרך מחסנית ה-ebpf של anetd.
  • cilium status --all-health
    • הדפסת הסטטוס של Cilium, כולל סטטוס הקישוריות בין הצמתים. כל פוד של anetd בודק את תקינות כל הצמתים האחרים באשכול ויכול לעזור לקבוע אם יש בעיות בקישוריות בין הצמתים.

‫Iptables

משתמשים ב-iptables בהרבה רכיבים ומערכות משנה של Kubernetes. kube-proxy משתמש ב-iptables כדי להטמיע את פתרון השירות. ‫Calico משתמש ב-iptables כדי להטמיע מדיניות רשת

  1. כדי לפתור בעיות ברשת ברמת iptables, משתמשים בפקודה הבאה:

    iptables -L -v | grep DROP

    בודקים את כללי ההשמטה, ואת מספר החבילות ומספר הבייטים כדי לראות אם הם גדלים לאורך זמן.

Tcpdump

‫Tcpdump הוא כלי רב עוצמה ללכידת חבילות נתונים, שמפיק הרבה נתונים על תעבורת רשת. אחת השיטות הנפוצות היא להריץ tcpdump גם מהמקור וגם מהיעד. אם חבילת נתונים מתועדת כשהיא יוצאת מצומת המקור אבל אף פעם לא מתועדת בצומת היעד, זה אומר שמשהו בדרך מפיל את חבילת הנתונים. ההתנהגות הזו בדרך כלל מצביעה על כך שמשהו בתשתית הפיזית שלכם מפיל את החבילה בטעות.

מדדים

‫Google Distributed Cloud כולל מדדים רבים שעוזרים לעקוב אחרי ההתנהגות של הרשת. המדדים הבאים הם נקודת התחלה טובה:

קטגוריה מדד תיאור
חבילות שהושמטו cilium_drop_bytes_total סה"כ בייטים שהושמטו, מתויגים לפי סיבת ההשמטה וכיוון הכניסה/היציאה. המדד הזה הוא נקודת התחלה טובה לבדיקת ירידות ברמת הבייט.
cilium_drop_count_total סה"כ חבילות שהושמטו, מתויגות לפי סיבת ההשמטה וכיוון הכניסה/היציאה.
container_network_receive_packets_dropped_total המספר המצטבר של חבילות שהושמטו במהלך הקבלה. נדגמים כל 60 שניות.
container_network_transmit_packets_dropped_total המספר המצטבר של חבילות הנתונים שהושמטו במהלך השידור. נדגמים כל 60 שניות.
מנות שהועברו cilium_forward_bytes_total המספר הכולל של בייטים שהועברו, מתויג לפי כניסה או יציאה. נדגמים כל 60 שניות. המדד הזה מספק מידע על העברה ברמת הבייט.
cilium_forward_count_total המספר הכולל של חבילות שהועברו, עם תיוג לפי כיוון הכניסה/היציאה. נדגמים כל 60 שניות. המדד הזה מציג את מספר החבילות של תנועה שהועברה.
cilium_policy_l7_forwarded_total המספר הכולל של בקשות שהועברו ברמה 7.
מנות שהתקבלו cilium_policy_l7_received_total המספר הכולל של בקשות/תגובות ברמה 7 שהתקבלו. נדגמים כל 60 שניות.
container_network_receive_bytes_total מספר מצטבר של בייטים שהתקבלו. הדגימה מתבצעת כל 60 שניות.
container_network_receive_packets_total מספר מצטבר של מנות שהתקבלו. הדגימה מתבצעת כל 60 שניות.
container_network_receive_errors_total מספר מצטבר של שגיאות שהתרחשו במהלך הקבלה. נדגמים כל 60 שניות.
cilium_kubernetes_events_received_total מספר האירועים של Kubernetes שהתקבלו, עם תוויות לפי היקף, פעולה, נתונים תקינים ושוויוניות. הדגימה מתבצעת כל 60 שניות.
BPF cilium_bpf_maps_virtual_memory_max_bytes הגודל המקסימלי של השימוש בזיכרון ליבה בבייטים במיפוי BPF.
cilium_bpf_progs_virtual_memory_max_bytes הגודל המקסימלי של השימוש בזיכרון ליבה בבייטים בתוכניות BPF.
Conntrack node_nf_conntrack_entries מספר רשומות הזרימה שהוקצו כרגע למעקב אחר חיבורים. הדגימה מתבצעת כל 60 שניות.
node_nf_conntrack_entries_limit הגודל המקסימלי של טבלת מעקב החיבורים. הדגימה מתבצעת כל 60 שניות.
קישוריות cilium_node_connectivity_latency_seconds החביון האחרון שנצפה בין סוכן Cilium הנוכחי לבין צמתי Cilium אחרים, בשניות. הדגימה מתבצעת כל 60 שניות.
cilium_node_connectivity_status הסטטוס האחרון של קישוריות ICMP ו-HTTP בין הסוכן הנוכחי של Cilium לבין צמתי Cilium אחרים. הדגימה מתבצעת כל 60 שניות.
Cilium operators cilium_operator_process_cpu_seconds_total הזמן הכולל של השימוש במעבד של המשתמש והמערכת, בשניות. נדגמים כל 60 שניות.
cilium_operator_process_max_fds המספר המקסימלי של מתארי קבצים פתוחים. הדגימה מתבצעת כל 60 שניות.
cilium_operator_process_open_fds מספר תיאורי הקבצים הפתוחים. הדגימה מתבצעת כל 60 שניות.
cilium_operator_process_resident_memory_bytes גודל הזיכרון התושב בבייטים. הדגימה מתבצעת כל 60 שניות.
cilium_operator_process_start_time_seconds שעת ההתחלה של התהליך מאז ראשית זמן יוניקס (Unix epoch) בשניות. נדגמים כל 60 שניות.
cilium_operator_process_virtual_memory_bytes גודל הזיכרון הווירטואלי בבייטים. הדגימה מתבצעת כל 60 שניות.
cilium_operator_process_virtual_memory_max_bytes הכמות המקסימלית של זיכרון וירטואלי שזמינה בבייטים. נדגמים כל 60 שניות.
cilium_operator_identity_gc_entries מספר הזהויות הפעילות והזהויות שנמחקו בסיום הפעלת איסוף האשפה. הדגימה מתבצעת כל 60 שניות.
cilium_operator_identity_gc_runs מספר הפעמים שבו הופעל איסוף הגרבג' של הזהויות. נדגמים כל 60 שניות.

כדי לקבל התראות כשאחד מהמדדים האלה עולה על סף מסוים או יורד מתחתיו, צריך ליצור כללי מדיניות התראות. מידע נוסף זמין במאמר בנושא יצירת מדיניות התראות מבוססת-מדדים במסמכי התיעוד של Cloud Monitoring.

מידע נוסף על המדדים האלה ורשימה מלאה של המדדים מופיעים במאמר מדדים של Google Distributed Cloud.

פתרון בעיות ב-DNS

בעיות שקשורות לפענוח DNS נחלקות לשתי קטגוריות עיקריות:

  • ‫Pods רגילים, שמשתמשים בשרתי ה-DNS בתוך האשכול.
  • ‫Pods או צמתים ברשת המארחת שלא משתמשים בשרתי DNS בתוך האשכול

בקטעים הבאים מופיע מידע על ארכיטקטורת ה-DNS של האשכול, וטיפים שימושיים לפני שמתחילים לפתור בעיות באחת מהקטגוריות האלה.

ארכיטקטורת DNS של אשכול

שירות DNS של אשכול מבצע רזולוציה של בקשות DNS עבור קבוצות Pod באשכול. ‫CoreDNS מספק את השירות הזה לגרסאות 1.9.0 ואילך של Google Distributed Cloud.

לכל אשכול יש שני Pods או יותר מסוג coredns, ומידרוג אוטומטי שאחראי על שינוי גודל של מספר ה-Pods של DNS ביחס לגודל האשכול. יש גם שירות בשם kube-dns שמאזן את העומס של הבקשות בין כל קבוצות ה-Pod של ה-Backend‏ coredns.

ברוב ה-Pods מוגדר DNS במעלה הזרם לכתובת ה-IP של שירות kube-dns, וה-Pods שולחים בקשות DNS לאחד מ-Pods של coredns. אפשר לקבץ בקשות DNS לאחד מהיעדים הבאים:

  • אם הבקשה היא לדומיין cluster.local, זהו שם DNS בתוך האשכול שמפנה לשירות או ל-Pod באשכול.
    • ‫CoreDNS עוקב אחרי api-server של כל השירותים וה-Pods באשכול, ומגיב לבקשות של דומיינים תקפים של cluster.local.
  • אם הבקשה לא מתייחסת לדומיין cluster.local, היא מתייחסת לדומיין חיצוני.
    • ‫CoreDNS מעביר את הבקשה לשרת השמות שלמעלה. כברירת מחדל, CoreDNS משתמש בשרתי השמות שלמעלה שמוגדרים בצומת שבו הוא פועל.

מידע נוסף זמין במאמר סקירה כללית על האופן שבו DNS פועל ומוגדר ב-Kubernetes.

טיפים לפתרון בעיות ב-DNS

כדי לפתור בעיות ב-DNS, אפשר להשתמש בכלים dig ו-nslookup. הכלים האלה מאפשרים לשלוח בקשות DNS כדי לבדוק אם פענוח ה-DNS פועל בצורה תקינה. בדוגמאות הבאות מוצגות הדרכים להשתמש בפקודות dig ו-nslookup כדי לבדוק אם יש בעיות בפתרון DNS.

  • משתמשים ב-dig או ב-nslookup כדי לשלוח בקשה ל-google.com:

    dig google.com
nslookup google.com

  • משתמשים ב-dig כדי לשלוח בקשה ל-kubernetes.default.svc.cluster.local לשרת 192.168.0.10:

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • אפשר להשתמש גם בפקודה nslookup כדי לבצע את אותו חיפוש DNS כמו בפקודה הקודמת dig:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    בודקים את הפלט של הפקודות dig או nslookup. אם אתם מקבלים תשובה שגויה או לא מקבלים תשובה בכלל, זה מצביע על בעיה בפענוח ה-DNS.

Regular Pods

השלב הראשון בניפוי באגים בבעיה ב-DNS הוא לקבוע אם הבקשות מגיעות ל-Pods של coredns או לא. לעתים קרובות, בעיה כללית בקישוריות של אשכול מופיעה כבעיות ב-DNS, כי בקשת DNS היא סוג התנועה הראשון שעומס עבודה שולח.

בודקים את הודעות השגיאה מהאפליקציות. שגיאות כמו io timeout או שגיאות דומות מצביעות על כך שאין תגובה ושיש בעיה כללית בקישוריות לרשת.

הודעות שגיאה שכוללות קוד שגיאת DNS כמו NXDOMAIN או SERVFAIL מצביעות על כך שיש קישוריות לשרת ה-DNS באשכול, אבל השרת לא הצליח לפתור את שם הדומיין:

  • שגיאות NXDOMAIN מציינות ששרת ה-DNS מדווח שהדומיין לא קיים. מוודאים ששם הדומיין שהאפליקציה מבקשת הוא תקין.
  • השגיאות SERVFAIL או REFUSED מציינות ששרת ה-DNS שלח תגובה, אבל הוא לא הצליח לפענח את הדומיין או לוודא שהוא לא קיים. מידע נוסף זמין ביומנים של coredns Pods.

אפשר למצוא את כתובת ה-IP של שירות kube-dns באמצעות הפקודה הבאה:

kubectl -n kube-system get svc kube-dns

מתוך Pod שבו DNS לא פועל, מנסים לשלוח בקשת DNS לכתובת ה-IP הזו באמצעות dig או nslookup, כמו שמתואר בקטע הקודם:

  • אם הבקשות האלה לא עובדות, מנסים לשלוח בקשות לכתובת ה-IP של כל coredns Pod.
  • אם חלק מה-Pods פועלים אבל אחרים לא, כדאי לבדוק אם יש דפוסים ברורים, למשל אם תרגום DNS פועל עבור Pods באותו צומת כמו ה-Pod‏ coredns, אבל לא בין צמתים. התנהגות כזו יכולה להעיד על בעיה בקישוריות בתוך האשכול.

אם CoreDNS לא יכול לפענח שמות של דומיינים חיצוניים, כדאי לעיין בקטע הבא כדי לפתור בעיות ב-Pods של רשת המארח. ‫CoreDNS מתנהג כמו Pod של רשת מארחת ומשתמש בשרתי ה-DNS של הצומת במעלה הזרם לצורך פענוח שמות.

פודים או צמתים ברשת המארחת

תאי Pod ברשת המארח והצמתים משתמשים בשרתי השמות שהוגדרו בצומת לפענוח DNS, ולא בשירות ה-DNS בתוך האשכול. בהתאם למערכת ההפעלה, שרת השמות הזה מוגדר ב-/etc/resolv.conf או ב-/run/systemd/resolve/resolv.conf. ההגדרה הזו אומרת שהם לא יכולים לפתור שמות של דומיינים מסוג cluster.local.

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

בעיות נפוצות ברשת

בקטעים הבאים מפורטות כמה בעיות נפוצות ברשת שאולי תיתקלו בהן. כדי לפתור את הבעיה, צריך לפעול לפי ההנחיות המתאימות לפתרון בעיות. לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

Calico

שגיאה נפוצה: calico/node is not ready: BIRD is not ready: BGP not established

בדרך כלל, השגיאה הזו של סטטוס 'לא מוכן' ב-Kubernetes מציינת שלא ניתן להגיע לעמית מסוים באשכול. בודקים שהקישוריות של BGP בין שני ה-Peers מותרת בסביבה שלכם.

השגיאה הזו יכולה להתרחש גם אם משאבי צומת לא פעילים מוגדרים לרשת צמתים. כדי לפתור את הבעיה, צריך להוציא משימוש את הצמתים הלא פעילים.

Dataplane v2 / Cilium

שגיאה נפוצה: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

השגיאה הזו מציינת שאירוע יצירת ה-Pod נדחה על ידי סוכן Cilium בגלל מגבלת קצב. לכל צומת, ב-Cilium יש מגבלה של ארבע בקשות בו-זמניות לנקודת הקצה PUT. התנהגות כזו צפויה כשמתקבלות הרבה בקשות לצומת אחד. הסוכן של Cilium צריך לעדכן את הבקשות שמתעכבות.

ב-GKE Enterprise מגרסה 1.14 ואילך, מגבלת הקצב מותאמת אוטומטית לקיבולת הצומת. הגבלת הקצב יכולה להתכנס למספר סביר יותר, עם הגבלות קצב גבוהות יותר לצמתים חזקים יותר.

שגיאה נפוצה: Ebpf map size is full

‫Dataplane v2 מאחסן את המצב במפה של eBFP. הסטטוס כולל את השירות, מעקב אחר חיבורים, זהות של Pod וכללים של מדיניות רשת. אם המפה מלאה, הסוכן לא יכול להוסיף רשומות, ונוצר פער בין מישור הבקרה למישור הנתונים. לדוגמה, במפת השירות יש הגבלה של 64,000 רשומות.

  1. כדי לבדוק את הרשומות במפת eBFP ואת הגודל הנוכחי שלהן, משתמשים בפונקציה bpftool. בדוגמה הבאה נבדקות המפות של מאזן העומסים:

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. אם המפה קרובה למגבלה של 64K, צריך לנקות את המפות. בדוגמה הבאה מנקים את המיפויים של מאזן העומסים:

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. כדי למלא מחדש את המצב במפת ה-eBFP, מפעילים מחדש את anetd.

הצומת לא מוכן בגלל שגיאות NetworkPluginNotReady

אם ה-Pod של CNI לא פועל בצומת, יכול להיות שתופיע שגיאה שדומה לזו:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

יכול להיות שהצומת יהיה במצב לא מוכן, עם שגיאה שדומה לדוגמה הבאה:

  "Network plugin not installed"

כשצומת מאותחל, kubelet ממתין להתרחשות של כמה אירועים לפני שהוא מסמן את הצומת כ-Ready. אחד מהאירועים ש-kubelet בודק הוא שהתוסף Container Network Interface‏ (CNI) מותקן. פלאגין ה-CNI צריך להיות מותקן על ידי anetd או Calico באמצעות קונטיינר init כדי להתקין את קובץ ה-CNI הבינארי ואת הגדרת ה-CNI בספריות המארח הנדרשות.

כדי לפתור את הבעיה, צריך לבדוק למה ה-Pods האלה לא פועלים בצומת. בדרך כלל השגיאה לא נובעת מבעיות ברשת. הפודים האלה פועלים ברשת המארחת, כך שאין תלות ברשת.

  1. בודקים את המצב של ה-Pod‏ anetd או calico-node. כדי לזהות את הגורם לבעיה, כדאי לעיין בשלבים הבאים לפתרון בעיות:

    • אם ה-Pod נמצא במצב Crashlooping, צריך לבדוק את היומנים כדי להבין למה ה-Pod לא יכול לפעול בצורה תקינה.
    • אם ה-Pod במצב Pending, משתמשים ב-kubectl describe ובודקים את אירועי ה-Pod. לדוגמה, יכול להיות שחסר למאגר משאב כמו נפח אחסון.
    • אם ה-Pod במצב Running, בודקים את היומנים ואת ההגדרה. חלק מההטמעות של CNI מספקות אפשרויות להשבתת ההתקנה של CNI, כמו ב-Cilium.
    • קיימת אפשרות הגדרה ב-anetd שנקראת custom-cni-conf. אם ההגדרה הזו מוגדרת כ-true, קובץ ה-CNI הבינארי של anetd לא יותקן.

‫Node NOT READY due to stale ARP entries

לפעמים, רשומות ARP מיושנות בצמתים של מישור הבקרה באשכול הניהול יכולות לגרום לחוסר התאמה בכתובות MAC. חוסר התאמה בכתובות יכול לגרום לפסק זמן בחיבורים לכתובות ה-VIP של מישור הבקרה של אשכולות משתמשים מנוהלים. פסק הזמן של החיבור עלול לגרום לסימון הצומת עם רשומות ARP לא עדכניות כNOT READY. צמתים שמסומנים ב-NOT READY עלולים לגרום לעיכובים בהתקנות ובשדרוגים של אשכולות.

במצב כזה, יומן kubelet בצומת עם רשומות ARP לא עדכניות מכיל שגיאת פסק זמן של לחיצת יד בפרוטוקול TLS, כמו השגיאה הבאה:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

כדי לאמת את הבעיה ולפתור אותה:

  1. משתמשים ב-SSH כדי להתחבר לצומת של מישור הבקרה של אשכול המשתמשים.

  2. מאמתים את כתובת ה-MAC של הממשק שאליו משויכת כתובת ה-VIP:

    ip a | grep DEVICE_NAME: -A 6

    מחליפים את DEVICE_NAME בשם של מכשיר הרשת של צומת מישור הבקרה.

  3. משתמשים ב-SSH כדי להתחבר לצומת של מישור הבקרה של אשכול אדמין.

  4. בודקים את מטמון ה-ARP במישור הבקרה של אשכול האדמין לגבי כתובת ה-VIP של מישור הבקרה של אשכול המשתמשים:

    ip n | grep VIP_ADDRESS

    מחליפים את VIP_ADDRESS בכתובת ה-IP של ה-VIP של מישור הבקרה של אשכול המשתמשים (controlPlaneVIP).

    אם שתי הפקודות ip מחזירות כתובת MAC שונה, אתם מושפעים מהבעיה הזו.

  5. כדי לפתור את הבעיה, צריך לנקות את מטמון ה-ARP בצומת של מישור הבקרה של אשכול האדמין:

    ip n flush all

שירות F5 לא מקבל תנועה

אם לא מועברת תנועה לשירות F5, כדאי לבצע את השלבים הבאים לפתרון בעיות:

  1. בודקים שכל מחיצה ב-F5 BIG-IP מוגדרת באשכול אחד, אשכול אדמין או אשכול משתמש. אם מחיצה אחת משותפת לכמה אשכולות שונים, יכולות להיות הפרעות לחיבור לסירוגין. ההתנהגות הזו נובעת מכך ששני אשכולות מנסים להשתלט על אותה מחיצה, ומוחקים שירותים מאשכולות אחרים.

  2. מוודאים ששני ה-Pods הבאים פועלים. אם יש רכיבי Pod שלא פועלים, זה מצביע על שגיאה:

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    ‫Load-balancer-f5 בבעלות GKE Enterprise, ויוצר ConfigMap לכל שירות מסוג LoadBalancer. בסופו של דבר, ה-ConfigMap נצרך על ידי בקר bigip.

  3. מוודאים שקובץ ה-ConfigMap קיים לכל יציאה של כל שירות. לדוגמה, עם היציאות הבאות:

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    השירות kube-server אמור להיראות כמו בדוגמה הבאה:

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    בקטע הנתונים ב-ConfigMap צריכים להיות ה-VIP והיציאה של קצה קדמי, כמו בדוגמה הבאה:

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. בודקים את היומנים והמדדים של מופע BIG-IP. אם ה-ConfigMap מוגדר בצורה נכונה, אבל מופע BIG-IP לא מכבד את ההגדרה, יכול להיות שזו בעיה ב-F5. במקרה של בעיות שמתרחשות בתוך מופע BIG-IP, צריך לפנות לתמיכה של F5 כדי לאבחן ולפתור את הבעיות.

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל: