בעיות עם DNS ב- Kubernetes. נתיחה פומבית שלאחר המוות

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

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

זה לא DNS
זה לא יכול להיות DNS
זה היה DNS

קצת על ניתוחים ותהליכים שלאחר המוות ב-Preply

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

מחפש SRE

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

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

Keep CALMS & DevOps: S מיועד לשיתוף

בעיות עם DNS ב- Kubernetes. נתיחה שלאחר המוות

Дата: 28.02.2020

מחברים: Amet U., Andrey S., Igor K., Alexey P.

סטָטוּס: גָמוּר

בקצרה: חוסר זמינות חלקית של DNS (26 דקות) עבור שירותים מסוימים באשכול Kubernetes

לְהַשְׁפִּיעַ: 15000 אירועים אבדו עבור שירותים א', ב' ו-ג'

סיבת שורש: Kube-proxy לא הצליח להסיר כהלכה ערך ישן מטבלת ה-conntrack, כך שחלק מהשירותים עדיין ניסו להתחבר ל-pods לא קיימים

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

הדק: בשל העומס הנמוך בתוך אשכול Kubernetes, CoreDNS-autoscaler הפחית את מספר הפודים בפריסה משלושה לשניים

פתרון: הפריסה הבאה של האפליקציה יזמה את היצירה של צמתים חדשים, CoreDNS-autoscaler הוסיפה תרמילים נוספים כדי לשרת את האשכול, מה שעורר שכתוב של טבלת החיבורים

איתור: ניטור Prometheus זיהה מספר רב של שגיאות 5xx עבור שירותים A, B ו-C ויזם קריאה למהנדסים התורנים

שגיאות 5xx ב-Kibana

פעילות

אפקט
סוג
אחראי
משימה

השבת את Autoscaler עבור CoreDNS
נמנע
אמט יו.
DEVOPS-695

הגדר שרת DNS לאחסון במטמון
לְהַקְטִין
מקס V.
DEVOPS-665

הגדר ניטור חיבורים
נמנע
אמט יו.
DEVOPS-674

לקחים

מה הלך טוב:

• הניטור עבד היטב. התגובה הייתה מהירה ומאורגנת
• לא פגענו בשום מגבלה על הצמתים

מה היה לא בסדר:

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

איפה התמזל מזלנו:

• הפריסה הבאה הופעלה על ידי CoreDNS-autoscaler, שהחליפה את טבלת החיבורים
• באג זה השפיע רק על שירותים מסוימים

ציר זמן (EET)

זמן
אפקט

22:13
CoreDNS-autoscaler הפחית את מספר הפודים משלושה לשניים

22:18
מהנדסים במשמרת החלו לקבל שיחות ממערכת הניטור

22:21
המהנדסים התורנים החלו לברר את סיבת הטעויות.

22:39
מהנדסים בתפקיד החלו להחזיר את אחד השירותים האחרונים לגרסה הקודמת

22:40
שגיאות 5xx הפסיקו להופיע, המצב התייצב

• זמן לגילוי: 4 דקות
• זמן לפני פעולה: 21 דקות
• זמן לתקן: 1 דקות

מידע נוסף

• יומני CoreDNS:

  I0228 20:13:53.507780       1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2

• קישורים לקיבאנה (חתוך), לגרפאנה (חתוך)
• היכן ש-Linux conntrack כבר לא חבר שלך
• דקויות kube-proxy: ניפוי באגים של איפוס חיבור לסירוגין
• זמן קצוב של חיבור מהיר ובדיקת DNS

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

איך עובד הקשר

תוצאות של

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

• GitLab: נתיחה שלאחר המוות של הפסקת מסד הנתונים ב-31 בינואר
• Dropbox: הפסקת נתיחה שלאחר המוות
• Spotify: יחסי אהבה/שנאה של Spotify עם DNS
• רבים אחרים מ התמצית הזו ומאגר סיפורי כישלון של Kubernetes
• גם דוגמה נתיחה פומבית שלאחר המוות עם ספר SRE

מקור: www.habr.com