קובייה על קובייה, מטה-צבירים, חלות דבש, חלוקת משאבים

אורז. 1. מערכת אקולוגית של Kubernetes ב- Alibaba Cloud

מאז 2015, Alibaba Cloud Container Service for Kubernetes (ACK) הוא אחד משירותי הענן הצומחים ביותר ב- Alibaba Cloud. הוא משרת לקוחות רבים ותומך גם בתשתית הפנימית של עליבאבא ובשירותי הענן האחרים של החברה.

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

במאמר זה, נשתף את הניסיון שלנו בניהול מספר רב של אשכולות Kubernetes על תשתית ענן, כמו גם את הארכיטקטורה של הפלטפורמה הבסיסית.

כניסה

Kubernetes הפך לסטנדרט דה פקטו עבור מגוון עומסי עבודה בענן. כפי שמוצג באיור. 1 לעיל, יותר ויותר יישומי ענן של Alibaba פועלים כעת באשכולות Kubernetes: יישומים מצביים וחסרי מדינה, כמו גם מנהלי יישומים. ניהול Kubernetes תמיד היה נושא דיון מעניין ורציני עבור מהנדסים שבונים ותחזקו תשתיות. כשמדובר בספקי ענן כמו Alibaba Cloud, נושא קנה המידה עולה על הפרק. כיצד לנהל אשכולות Kubernetes בקנה מידה זה? כבר כיסינו את השיטות המומלצות לניהול אשכולות Kubernetes ענקיים של 10 צמתים. כמובן שזו בעיית קנה מידה מעניינת. אבל יש קנה מידה אחר: כמות האשכולות עצמם.

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

אורז. 2. בעיות בניהול מספר עצום של אשכולות Kubernetes

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

• ההטרוגניות

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

• גדלי אשכולות שונים

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

• גרסאות שונות

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

• תאימות אבטחה

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

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

תכנית

קובייה על קובייה וחלת דבש

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

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

ACK מנהלת אשכולות Kubernetes אלה באמצעות Kubernetes עצמה, כלומר יש לנו מטא-קלוסטר Kubernetes הפועל לניהול אשכולות Kubernetes של הלקוח. ארכיטקטורה זו נקראת גם "קובה-על-קובה" (KoK). ארכיטקטורת KoK מפשטת את הניהול של אשכולות לקוח מכיוון שפריסת אשכולות היא פשוטה ודטרמיניסטית. חשוב מכך, אנו יכולים לעשות שימוש חוזר בתכונות מקוריות של Kubernetes. לדוגמה, ניהול שרתי API באמצעות פריסה, שימוש באופרטור ה-etcd לניהול מספר וכו'. רקורסיה כזו תמיד מביאה עונג מיוחד.

מספר metaclusters של Kubernetes פרוסים בתוך אזור אחד, בהתאם למספר הלקוחות. אנו קוראים ל- metaclusters הללו תאים. כדי להגן מפני כישלון של אזור שלם, ACK תומך בפריסות מרובות אקטיביות באזור יחיד: המטא-קלוסטר מפיץ רכיבי מאסטר של אשכול לקוח של Kubernetes על פני מספר אזורים ומריץ אותם בו-זמנית, כלומר, במצב רב-אקטיבי. כדי להבטיח את האמינות והיעילות של המאסטר, ACK מייעלת את מיקום הרכיבים ומבטיחה ששרת ה-API וה- etcd קרובים זה לזה.

מודל זה מאפשר לך לנהל את Kubernetes בצורה יעילה, גמישה ואמינה.

תכנון משאבי Metacluster

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

ניקח למשל משאבי רשת. בארכיטקטורת KoK, רכיבי Kubernetes מאשכולות לקוח נפרסים כ-pods במטא-cluster. אנו משתמשים Terway (איור 3) הוא תוסף בעל ביצועים גבוהים שפותח על ידי Alibaba Cloud לניהול רשת קונטיינרים. הוא מספק מערך עשיר של מדיניות אבטחה ומאפשר לך להתחבר לעננים פרטיים וירטואליים (VPCs) של לקוחות באמצעות ממשק הרשת האלסטית בענן של Alibaba (ENI). כדי להפיץ ביעילות משאבי רשת על פני צמתים, פודים ושירותים במטא-אשכול, עלינו לנטר בקפידה את השימוש בהם בתוך המטא-אשכול של עננים פרטיים וירטואליים. כאשר משאבי הרשת מגיעים לסופם, נוצר תא חדש.

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

אורז. 3. ארכיטקטורת רשת Terway

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

לרכיבי האשף יש צורכי משאבים שונים. הם תלויים במספר הצמתים והתרמילים באשכול, במספר הבקרים/אופרטורים הלא סטנדרטיים המקיימים אינטראקציה עם APIServer.

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

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

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

אורז. 4. מיתוג סוג רב-שלבי אינטליגנטי

אבולוציה של אשכולות לקוחות בקנה מידה

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

Kubernetes הוא ה"לינוקס" של עולם הענן. הוא מתעדכן כל הזמן והופך מודולרי יותר. עלינו לספק כל הזמן גרסאות חדשות ללקוחותינו, לתקן נקודות תורפה ולעדכן אשכולות קיימים, כמו גם לנהל מספר רב של רכיבים קשורים (CSI, CNI, Device Plugin, Scheduler Plugin ועוד רבים אחרים).

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

אורז. 5. רכיבים גמישים וניתנים לחיבור

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

אורז. 6. בדיקה מקדימה של רכיבי אשכול

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

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

אורז. 7. OpenKurise מארגן את ביצוע משימת השידור בכל הצמתים

כדי לעזור ללקוחות לבחור את תצורות האשכול הנכונות, אנו מספקים גם קבוצה של פרופילים מוגדרים מראש, כולל פרופילי Serverless, Edge, Windows ו-Bare Metal. ככל שהנוף מתרחב וצרכי ​​הלקוחות שלנו יגדלו, נוסיף עוד פרופילים כדי לפשט את תהליך ההגדרה המייגע.

אורז. 8. פרופילי אשכול מתקדמים וגמישים לתרחישים שונים

צפייה גלובלית בין מרכזי נתונים

כפי שמוצג באיור למטה. 9, שירות הענן של Alibaba Cloud Container נפרס בעשרים אזורים ברחבי העולם. בהתחשב בקנה מידה זה, אחת ממטרות המפתח של ACK היא לנטר בקלות את מצב ההפעלה של אשכולות כך שאם אשכול לקוח נתקל בבעיה, נוכל להגיב במהירות למצב. במילים אחרות, עליכם להמציא פתרון שיאפשר לכם לאסוף ביעילות ובבטחה נתונים סטטיסטיים בזמן אמת מאשכולות לקוחות בכל האזורים – ולהציג את התוצאות בצורה ויזואלית.

אורז. 9. פריסה גלובלית של שירות Alibaba Cloud Container בעשרים אזורים

כמו מערכות ניטור רבות של Kubernetes, אנו משתמשים ב-Prometheus ככלי העיקרי שלנו. עבור כל מטא-אשכול, סוכני פרומתאוס אוספים את המדדים הבאים:

• מדדי מערכת הפעלה כגון משאבי מארח (מעבד, זיכרון, דיסק וכו') ורוחב פס רשת.
• מדדים למערכת ניהול המטא-אשכול ו-Client, כגון kube-apiserver, kube-controller-manager ו-kube-scheduler.
• מדדים מ-kubernetes-state-metrics ו-cadvisor.
• מדדי etcd כגון זמן כתיבה בדיסק, גודל מסד נתונים, תפוקה של קישורים בין צמתים וכו'.

נתונים סטטיסטיים גלובליים נאספים באמצעות מודל צבירה טיפוסי רב-שכבתי. נתוני ניטור מכל metacluster נצברים תחילה בכל אזור ולאחר מכן נשלחים לשרת מרכזי המציג את התמונה הכוללת. הכל עובד דרך מנגנון הפדרציה. שרת פרומתאוס בכל מרכז נתונים אוסף מדדים מאותו מרכז נתונים, ושרת פרומתאוס המרכזי אחראי על צבירת נתוני הניטור. AlertManager מתחבר למרכז פרומתאוס ושולח התראות לפי הצורך באמצעות DingTalk, מייל, SMS וכו'. ויזואליזציה - שימוש בגראפנה.

באיור 10, ניתן לחלק את מערכת הניטור לשלוש רמות:

• רמת גבול

השכבה הכי רחוקה מהמרכז. שרת ה-Prometheus Edge פועל בכל מטא-קלוסטר, אוסף מדדים מ-meta ו-clisters בתוך אותו תחום רשת.

• רמת אשד

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

• רמה מרכזית

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

אורז. 10. ארכיטקטורת ניטור עולמית רב-שכבתית המבוססת על מנגנון הפדרציה של פרומתאוס

תקציר

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

מקור: www.habr.com