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

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

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

התשתית של רשתות פיזיות היא הבסיס לרשתות ב-GKE Enterprise. לדוגמה, Seesaw או MetalLB מסתמכים על כך שהמתגים יכבדו את ה-ARP החינמי, איזון העומסים בחבילה עם Border Gateway Protocol‏ (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 מאותו אשכול.
  • מאזן עומסים של Ingress Layer 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, תעבורת היציאה מדלגת על מאזן העומסים.

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

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

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

  • האם החבילה יוצאת מהלקוח? אם לא, כנראה שיש בעיה בתשתית הרשת.
  • האם אתם משתמשים במאזן העומסים של Seesaw? אם כן, האם החבילה מגיעה לצומת Seesaw, והאם פרוטוקול ARP נשלח בצורה תקינה? אם לא, כנראה שיש בעיה בתשתית הרשת.
  • האם אתם משתמשים ב-MetalLB? אם כן, האם המנה מגיעה לצומת של איזון העומסים, והאם פרוטוקול ה-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

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

האם המנה מגיעה לצומת של איזון העומסים?

אם משתמשים ב-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) כדי לתרגם את כתובת ה-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

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

    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 מציינים שהכול פועל כרגיל בשכבה 4.
  • שגיאות "החיבור אופס על ידי הרשת" מצביעות על בעיה בשכבה 4.
    • הרבה פעמים, השקע המרוחק לא יכול להסכים עם המצב הנוכחי של חיבור ולכן שולח מנה (packet) של 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. אפשר להשתמש בפינג כדי לבדוק את הקישוריות. למרות שהמערכת של 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 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](/kubernetes-engine/distributed-cloud/vmware/docs/metrics-anthos).

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

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

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

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

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

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

לכל אשכול יש שני 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 של הצומת במעלה הזרם כדי לפתור את הבעיה בשם.

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

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

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

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

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

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

    ‫Load-balancer-f5 בבעלות GKE Enterprise, ויוצר ConfigMaps לכל שירות מסוג 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 כדי לאבחן ולפתור את הבעיות.

זמן אחזור לסירוגין אחרי שמאגרי הנתונים הזמניים של הרשת מתרוקנים

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

אם מאגר הנתונים הזמני של הטבעת באשכול שלכם מתמלא, יכול להיות שתראו את ההודעות הבאות:

  • זמן האחזור של הרשת עולה באופן בלתי צפוי (לדוגמה, מ-1 ms ליותר מ-20 ms)
  • פסק זמן כשמתחברים לשירותים חיצוניים, כמו מסד נתונים חיצוני

אם לדעתכם הבעיה הזו רלוונטית לגביכם, כדאי לבדוק את נתוני הרשת של VMXNET3 מהמעטפת של ההיפר-ויז'ר ESXi:

  1. מתחברים למארח ESXi שבו פועל הצומת המושפע באמצעות SSH.

  2. מאתרים את מזהה היציאה של המכונה הווירטואלית שהושפעה:

    net-stats -l

  3. אחזור הנתונים הסטטיסטיים של תור הקבלה עבור מתאם VMXNET3 ספציפי:

    vsish -e get /net/portsets/SWITCH_NAME/ports/PORT_ID/vmxnet3/rxSummary

    מחליפים את SWITCH_NAME ו-PORT_ID בערכים מהשלב הקודם.

אם הערך של המונה running out of buffers גדול מ-0, מאגר הנתונים הזמני (ring buffer) מלא ומערכת ההפעלה של האורח משמיטה מנות:

 stats of a vmxnet3 vNIC rx queue {
  ...
  unicast pkts rx ok:43501967131
  multicast pkts rx ok:130494
  broadcast pkts rx ok:4308743
  running out of buffers:20574
 }

כדי לפתור את הבעיה של מערכת ההפעלה האורחת שנגמר לה הזיכרון בשטחי האחסון הזמניים של הרשת, צריך להגדיל אוטומטית את גודל שטח האחסון הזמני של הרשת כשמקצים צומת עובד חדש על ידי החלת Kubernetes DaemonSet על מרחב השמות kube-system. שם הממשק חייב להיות זהה לממשק הראשי בהגדרת הצומת. בדוגמה הבאה, שם הממשק הוא eth0.

החלת Kubernetes DaemonSet על מרחב השמות kube-system:

  1. יוצרים קובץ בשם tune-vmxnet3-buffers.yaml עם ההגדרות הבאות:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: tune-vmxnet3-buffers
  namespace: kube-system
  labels:
    app: tune-vmxnet3-buffers
spec:
  selector:
    matchLabels:
      app: tune-vmxnet3-buffers
  template:
    metadata:
      labels:
        app: tune-vmxnet3-buffers
    spec:
      hostNetwork: true
      hostPID: true
      initContainers:
      - name: tune-buffers
        # Uses nsenter to break out and run ethtool on the host OS
        # Note: If your cluster restricts outbound internet access, replace this with an image from your private registry.
        image: ubuntu:latest
        command:
        - /bin/sh
        - -c
        - |
          nsenter -t 1 -m -u -n -i ethtool -G eth0 rx 4096 tx 4096
        securityContext:
          privileged: true
      containers:
      - name: pause
        image: gcr.io/google_containers/pause:3.9

  2. מחילים את המניפסט על האשכול:

    kubectl apply -f tune-vmxnet3-buffers.yaml

  3. מוודאים ש-DaemonSet יכול להפעיל Pod בהצלחה בצמתי העובדים:

    kubectl get pods -n kube-system -l app=tune-vmxnet3-buffers -o wide

אחרי שמחילים את DaemonSet, קונטיינר האתחול מופעל פעם אחת כשהצומת מופעל. קונטיינר האתחול משתמש ב-ethtool כדי להגדיל את מאגרי הנתונים הזמניים של rx ו-tx ל-4096. הקונטיינר init מעביר את ה-pod למצב מושהה, וההגדרה נשמרת באופן דינמי בכל צמתי העובדים הקיימים והעתידיים.

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

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

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