Kubernetes adventure Dailymotion: יצירת תשתית בעננים + מקומית

הערה. תרגום: Dailymotion הוא אחד משירותי אירוח הווידאו הגדולים בעולם ולכן משתמש בולט של Kubernetes. בחומר זה, אדריכל המערכת David Donchez משתף בתוצאות יצירת פלטפורמת הייצור של החברה המבוססת על K8s, שהחלה בהתקנת ענן ב-GKE והסתיימה כפתרון היברידי, שאיפשר זמני תגובה טובים יותר וחיסכון בעלויות תשתית.

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

למה כדאי לבנות פלטפורמה משלך המבוססת על Kubernetes?

ממשק API ברמת ייצור תוך זמן קצר באמצעות Google Cloud

קיץ 2016

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

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

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

למה בחרת ב-GKE?

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

אשכולות GKE ב-Dailymotion

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

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

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

ניטור איזון עומסים של Google

הפלטפורמה שלנו גם עושה שימוש רב במעבדי GPU. Google Cloud מאפשר לך להשתמש בהם ביעילות רבה ישירות באשכולות Kubernetes.

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

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

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

השקת פלטפורמת תזמור מכולות מקומית Dailymotion

סתיו 2016

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

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

התשתית של Dailymotion כללה יותר מ-2,5 אלף שרתים בשישה מרכזי נתונים. כולם מוגדרים באמצעות Saltstack. התחלנו להכין את כל המתכונים הדרושים ליצירת צמתים מאסטר ועובד, כמו גם אשכול וכו'.

חלק ברשת

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

מכיוון שרצינו להשתמש בכל רכיבי התשתית הזמינים, הדבר הראשון שהיינו צריכים לעשות היה להבין את כלי הרשת שלנו (בשימוש בכל השרתים): השתמש בו כדי לפרסם טווחי כתובות IP ברשת עם צמתי Kubernetes. אפשרנו ל-Calico להקצות כתובות IP ל-pods, אך לא השתמשנו ועדיין לא השתמשנו בה עבור הפעלות BGP בציוד רשת. למעשה, הניתוב מטופל על ידי Exabgp, המפרסמת את רשתות המשנה שבהן משתמשת Calico. זה מאפשר לנו להגיע לכל פוד מהרשת הפנימית (ובפרט ממאזני עומסים).

כיצד אנו מנהלים תנועה נכנסת

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

לפני שלוש שנים, nginx-ingress-controller היה הבקר הבוגר ביותר: Nginx היה קיים כבר זמן רב והיה ידוע ביציבות ובביצועים שלו.

במערכת שלנו, החלטנו למקם את הבקרים על שרתי להב ייעודיים של 10 גיגה-ביט. כל בקר היה מחובר לנקודת הקצה kube-apiserver של האשכול המתאים. שרתים אלה השתמשו גם ב-Exabgp כדי לפרסם כתובות IP ציבוריות או פרטיות. טופולוגיית הרשת שלנו מאפשרת לנו להשתמש ב-BGP מבקרים אלו כדי לנתב את כל התעבורה ישירות אל הפודים מבלי להשתמש בשירות כמו NodePort. גישה זו מסייעת להימנע מתעבורה אופקית בין צמתים ומשפרת את היעילות.

תנועת תנועה מהאינטרנט לתרמילים

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

העברת תעבורה מ-Google Cloud לתשתית Dailymotion

סתיו 2018

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

אסטרטגיית הניתוב הנוכחית היא די פשוטה, אבל מספיקה כדי לענות על הצרכים. בנוסף לכתובות IP ציבוריות (ב-Google Cloud ו-Dailymotion), AWS Route 53 משמש להגדרת מדיניות ולהפנות משתמשים לאשכול לפי בחירתנו.

דוגמה למדיניות ניתוב באמצעות כביש 53

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

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

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

במצב רגיל, כל התנועה האזורית מופנית לאשכול המקומי, ו-GKE משמשת עתודה למקרה של בעיות (בדיקות בריאות מבוצעות על ידי כביש 53).

...

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

נ.ב מהמתרגם

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

קרא גם בבלוג שלנו:

• «מעבר טינדר ל-Kubernetes".
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 10: reddit";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 9: אשכולות CERN ו-210 K8s";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 8: Huawei";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 7: בלקרוק";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 6: BlaBlaCar";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 5: בנק דיגיטלי Monzo";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 4: SoundCloud (מאת פרומתאוס)";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 3: GitHub";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 2: Concur ו-SAP";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 1: 4200 אח ו-TessMaster מ-eBay".

מקור: www.habr.com