Kubernetes ב-DomClick: איך לישון בשקט בניהול אשכול של 1000 מיקרו-שירותים

שמי ויקטור יאגופארוב, ואני מפתח את פלטפורמת Kubernetes ב-DomClick כמנהל פיתוח טכני בצוות Ops (תפעול). ברצוני לדבר על המבנה של תהליכי ה-Dev <-> Ops שלנו, על התכונות של הפעלת אחד מאשכולות ה-k8s הגדולים ברוסיה, וכן על שיטות ה-DevOps / SRE שהצוות שלנו משתמש בהן.

Team Ops

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

לכל אחד יש כישורים שונים: אנשי רשת, DBAs, מומחי מחסנית של ELK, מנהלי/מפתחים של Kubernetes, ניטור, וירטואליזציה, מומחי חומרה וכו'. דבר אחד מאחד את כולם - כולם יכולים להחליף כל אחד מאיתנו במידה מסוימת: למשל, להכניס צמתים חדשים לאשכול ה-k8s, לעדכן את PostgreSQL, לכתוב CI/CD + Ansible pipeline, להפוך משהו לאוטומטי ב-Python/Bash/Go, חבר יצירה של חומרה ל-DPC. כישורים חזקים בכל תחום לא מפריעים לשנות את כיוון הפעילות ולהתחיל לשאוב באזור אחר. לדוגמה, קיבלתי עבודה בחברה כמומחה PostgreSQL, ועכשיו תחום האחריות העיקרי שלי הוא אשכולות Kubernetes. בצוות כל צמיחה מתקבלת בברכה ותחושת הכתף מאוד מפותחת.

אגב, אנחנו צדים. הדרישות למועמדים הן די סטנדרטיות. לי אישית חשוב שאדם ישתלב בצוות, לא יתנגש, אבל גם ידע להגן על נקודת המבט שלו, ירצה להתפתח ולא יפחד לעשות משהו חדש, להציע את הרעיונות שלו. כמו כן, נדרשים כישורי תכנות בשפות סקריפטים, ידע ביסודות לינוקס ואנגלית. יש צורך באנגלית רק כדי שאדם במקרה של fakap יוכל לחפש בגוגל את הפתרון לבעיה תוך 10 שניות, ולא תוך 10 דקות. עם מומחים עם ידע מעמיק בלינוקס, עכשיו זה קשה מאוד: מצחיק, אבל שניים מתוך שלושה מועמדים לא יכולים לענות על השאלה "מהו ממוצע עומס? ממה זה מורכב?", והשאלה" איך לאסוף מזבלה ליבה מתוכנית sish "נחשבת למשהו מעולם העל-אנושיים... או הדינוזאורים. אנחנו צריכים להשלים עם זה, מכיוון שבדרך כלל לאנשים יש כישורים אחרים מפותחים מאוד, ואנחנו נלמד לינוקס. את התשובה לשאלה "מדוע מהנדס DevOps צריך לדעת את כל זה בעולם העננים המודרני" תצטרך להשאיר מחוץ לתחום המאמר, אבל בשלוש מילים: כל זה הכרחי.

פקודת כלים

צוות הכלים ממלא תפקיד משמעותי באוטומציה. המשימה העיקרית שלהם היא ליצור כלים גרפיים ו-CLI נוחים למפתחים. לדוגמה, הפיתוח הפנימי שלנו של Confer מאפשר לך להפעיל אפליקציה ל-Kubernetes בכמה לחיצות עכבר בלבד, להגדיר את המשאבים שלה, מפתחות מהכספת וכו'. פעם היה Jenkins + Helm 2, אבל הייתי צריך לפתח כלי משלי כדי לבטל את העתק-הדבק ולהביא אחידות למחזור החיים של התוכנה.

צוות Ops אינו כותב צינורות למפתחים, אך יכול לייעץ בכל בעיה בכתיבתם (לחלקם עדיין יש Helm 3).

דופים

לגבי DevOps, אנחנו רואים את זה כך:

צוותי Dev כותבים קוד, מוציאים אותו דרך Confer to dev -> qa/stage -> prod. באחריות צוותי ה-Dev ו-Ops לוודא שהקוד לא מאט ואינו יזרוק שגיאות. בשעות היום על קצין התורן מצוות אופס להגיב לאירוע עם פנייתו, ובערב ובלילה על המנהל התורן (אופס) להעיר את היזם התורן אם הוא יודע בוודאות שהבעיה אינה. בתשתית. כל המדדים וההתראות בניטור מופיעים באופן אוטומטי או חצי אוטומטי.

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

מפתחים מייעצים למנהלים אם הם זקוקים לעזרה בכתיבת מיקרו-שירות אדמין (לדוגמה, Go backend + HTML5), ומנהלים מייעצים למפתחים בכל נושא הקשור לתשתית או ל-k8s.

אגב, אין לנו מונוליט בכלל, רק שירותי מיקרו. מספרם עד כה נע בין 900 ל-1000 באשכול prod k8s, אם נמדד לפי המספר פריסות. מספר התרמילים נע בין 1700 ל-2000. התרמילים במקבץ התרמילים הם כעת בסביבות 2000.

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

ניהול משאבים

ניטור

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

• זאביקס. ניטור ישן וטוב, שנועד בעיקר לנטר את המצב הכללי של התשתית. זה אומר לנו מתי צומת מת על ידי מעבד, זיכרון, דיסקים, רשת וכן הלאה. שום דבר על טבעי, אבל יש לנו גם DaemonSet נפרד של סוכנים, שבעזרתו, למשל, אנחנו עוקבים אחר מצב ה-DNS באשכול: אנחנו מחפשים תרמילים מטופשים של coredns, אנחנו בודקים את הזמינות של מארחים חיצוניים. נראה כי למה לטרוח למען זה, אבל בהיקפי תנועה גדולים הרכיב הזה הוא נקודת כשל רצינית. בעבר יש לי מְתוּאָראיך נאבק בביצועי DNS באשכול.
• מפעיל פרומתאוס. קבוצה של יצואנים שונים נותנת סקירה נהדרת של כל מרכיבי האשכול. לאחר מכן, אנו מדמיינים את כל זה על לוחות מחוונים גדולים בגראפאנה, ומשתמשים ב-alertmanager עבור התראות.

כלי שימושי נוסף עבורנו הוא כניסה לרשימה. כתבנו את זה לאחר מספר פעמים שנתקלנו במצב שבו צוות אחד חפף את ה-Ingress של צוות אחר עם הנתיבים שלו, מה שגרם לשגיאות פי 50. כעת, לפני הפריסה לייצור, מפתחים בודקים שהם לא יפגעו באף אחד, ועבור הצוות שלי זה כלי טוב לאבחון ראשוני של בעיות עם Ingresses. זה מצחיק שבהתחלה זה נכתב למנהלים וזה נראה די "מסורבל", אבל אחרי שצוותי הפיתוח התאהבו בכלי, זה השתנה מאוד והתחיל להיראות לא כמו "המנהל עשה פרצוף אינטרנט למנהלים" . בקרוב נוותר על הכלי הזה ומצבים כאלה יעברו תוקף עוד לפני שהצנרת תתגלגל.

משאבי צוות ב"קוביה"

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

להבין אילו צוותים ובאילו כמויות משתמשים בהם ресурсы (מעבד, זיכרון, SSD מקומי), אנו מקצים משלנו מרחב שמות ב"קוביה" ולהגביל את היכולות המקסימליות שלו מבחינת מעבד, זיכרון ודיסק, לאחר שדנו בעבר בצורכי הצוותים. בהתאם לכך, פקודה אחת, במקרה הכללי, לא תחסום את כל האשכול לפריסה, ותקצה לעצמה אלפי ליבות וטרה-בייט של זיכרון. גישה למרחב השמות ניתנת דרך AD (אנו משתמשים ב-RBAC). מרחבי השמות והמגבלות שלהם מתווספים באמצעות בקשת משיכה למאגר ה-GIT, ואז הכל מתגלגל אוטומטית דרך הצינור של Ansible.

דוגמה להקצאת משאבים לצוות:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

בקשות ומגבלות

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

הדרך הנכונה לצאת ממצב זה היא להסתכל על צריכת המשאב בפועל ולהשוות בינה לבין הכמות המבוקשת (Request).

צילומי המסך למעלה מראים שהמעבדים ה"מבוקשים" (מבוקשים) נבחרים למספר האמיתי של שרשורים, ומגבלות יכולות לחרוג מהמספר האמיתי של שרשורי CPU =)

עכשיו בואו נסתכל מקרוב על מרחב שמות כלשהו (בחרתי במרחב השמות kube-system - מרחב השמות של המערכת עבור רכיבי ה"קוביה" עצמה) ונראה את היחס בין זמן המעבד והזיכרון שבשימוש בפועל לזה המבוקש:

ברור שיש הרבה יותר זיכרון ומעבד שמורים לשירותי מערכת מאשר בשימוש בפועל. במקרה של ה-kube-system זה מוצדק: קרה שבקר הכניסה של nginx או nodelocaldns בשיא נח על המעבד ואכל הרבה זיכרון RAM, אז כאן מרווח כזה מוצדק. בנוסף, איננו יכולים להסתמך על תרשימים של 3 השעות האחרונות: רצוי לראות מדדים היסטוריים על פני תקופה ארוכה של זמן.

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

והנה התרמילים שצריכים למתן את התיאבון שלהם:

על מצערת + משאבי ניטור, אתה יכול לכתוב יותר ממאמר אחד, אז שאל שאלות בתגובות. בכמה מילים, אני יכול לומר שהמשימה של אוטומציה של מדדים כאלה היא קשה מאוד ודורשת הרבה זמן ופעולת איזון עם פונקציות "חלון" ו-"CTE" Prometheus / VictoriaMetrics (מונחים אלה נמצאים במרכאות, שכן יש כמעט שום דבר כזה ב-PromQL, ואתה צריך לגדר שאילתות מפחידות בכמה מסכי טקסט ולבצע אופטימיזציה שלהן).

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

מתודולוגיות

בחברה כמו עכשיו אופנתי, אנו מקפידים על DevOps- and SRE-עוֹסֵק כשלחברה יש 1000 מיקרו-שירותים, כ-350 מפתחים ו-15 אדמינים לכל התשתית, צריך "להיות אופנתי": מאחורי כל ה"באזוורדים" האלה יש צורך דחוף לעשות הכל והכל לאוטומטי, ומנהלי מערכת לא צריכים להיות צוואר בקבוק בתהליכים.

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

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

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

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

Внедрение רשת שירות נמצא ממש מעבר לפינה ואמור לעשות את החיים הרבה יותר קלים לכולם, עמיתים מ-Tools כבר קרובים ליישם את המופשט "Istio של אדם בריא": מחזור החיים של כל בקשת HTTP(ים) יהיה גלוי בניטור, ו תמיד ניתן יהיה להבין "באיזה שלב הכל התקלקל" באינטראקציה בין-שירותית (ולא רק). הירשם לחדשות ממרכז DomClick. =)

תמיכה בתשתית Kubernetes

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

תהליך השדרוג עבור כל אשכולות ה-k8s נראה כך:

• קח קובספריי מסאות'ברידג', בדוק עם הסניף שלנו, merjim.
• משיק את העדכון ל לחץ- "קוביה".
• אנו מפיצים את העדכון צומת אחד בכל פעם (ב-Ansible זה "סדרתי: 1") ב dev- "קוביה".
• עִדכּוּן לדרבן במוצאי שבת, צומת אחד בכל פעם.

בעתיד יש תוכניות להחליף קובספריי למשהו מהיר יותר ולכו kubeadm.

בסך הכל, יש לנו שלוש "קוביות": Stress, Dev ו-Prod. אנחנו מתכננים להשיק עוד אחדהמתנה חמה) Prod- "קוביה" במרכז הנתונים השני. לחץ и dev חיים במכונות וירטואליות (oVirt for Stress ו-VMWare cloud for Dev). לדרבן- "Cube" חי על "bare metal" (bare metal): אלו אותם צמתים עם 32 חוטי CPU, 64-128 GB של זיכרון ו-300 GB של SSD RAID 10 - יש 50 מהם בסך הכל. שלושה צמתים "דקים" מוקדשים ל"מאסטרים" לדרבן- "קובה": 16 ג'יגה-בייט של זיכרון, 12 חוטי מעבד.

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

עבור CI/CD Cubic ורכיבי תשתית אחרים אנו משתמשים בשרת GIT נפרד, Helm 3 אטומי), ג'נקינס, אנסיבל ודוקר. אנחנו אוהבים סניפים מאפיינים ופריסה לסביבות שונות מאותו מאגר.

מסקנה

כך, באופן כללי, נראה תהליך DevOps ב-DomClick מהצד של מהנדס תפעול. הכתבה התבררה כפחות טכנית ממה שציפיתי: לכן, עקבו אחר חדשות DomClick ב-Habré: יהיו עוד כתבות "הארדקור" על Kubernetes ועוד.

מקור: www.habr.com