יצירת פלטפורמת kubernetes בפינטרסט

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

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

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

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

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

איור 1: סדרי עדיפויות של תשתית (אמינות, פרודוקטיביות מפתחים ויעילות).

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

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

Kubernetes: The Pinterest Way

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

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

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

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

מאפייני משתמש ובקרי Pinterest

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

CRDs מספקים את הפונקציונליות הבאה:

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

הנה דוגמה של PinterestService ומשאב פנימי המנוהל על ידי הבקר שלנו:

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

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

זרימת עבודה של פריסת יישומים

התמונה למעלה מראה כיצד לפרוס משאב מותאם אישית של Pinterest לאשכול Kubernetes:

1. מפתחים מקיימים אינטראקציה עם אשכול Kubernetes שלנו דרך ה-CLI וממשק המשתמש.
2. כלי ה-CLI/UI מאחזרים את קבצי YAML של תצורת זרימת העבודה ומאפייני בנייה אחרים (אותו מזהה גרסה) מ-Artifactory ולאחר מכן מגישים אותם לשירות הגשת העבודה. שלב זה מבטיח שרק גרסאות ייצור יימסרו לאשכול.
3. JSS הוא שער לפלטפורמות שונות, כולל Kubernetes. כאן המשתמש מאומת, מכסות מונפקות ותצורת ה-CRD שלנו נבדקת חלקית.
4. לאחר בדיקת ה-CRD בצד ה-JSS, המידע נשלח ל-API של פלטפורמת k8s.
5. בקר ה-CRD שלנו מנטר אירועים בכל משאבי המשתמש. הוא ממיר CRs למשאבי k8s מקוריים, מוסיף את המודולים הדרושים, מגדיר את משתני הסביבה המתאימים ומבצע עבודות תמיכה אחרות כדי להבטיח שלאפליקציות משתמש מכולות יש תמיכה מספקת בתשתית.
6. לאחר מכן, בקר ה-CRD מעביר את הנתונים שהתקבלו ל-Kubernetes API כך שניתן יהיה לעבד אותם על ידי המתזמן ולהכניסם לייצור.

שים לב: זרימת העבודה הזו של הפריסה לפני ההפצה נוצרה עבור המשתמשים הראשונים של פלטפורמת k8s החדשה. אנו נמצאים כעת בתהליך של חידוד תהליך זה כדי להשתלב במלואו עם ה-CI/CD החדשים שלנו. משמעות הדבר היא שאיננו יכולים לספר לך כל מה שקשור ל-Kubernetes. אנו מצפים לחלוק את הניסיון שלנו ואת ההתקדמות של הצוות בכיוון זה בפוסט הבא שלנו בבלוג, "בניית פלטפורמת CI/CD עבור Pinterest."

סוגי משאבים מיוחדים

בהתבסס על הצרכים הספציפיים של Pinterest, פיתחנו את ה-CRD הבאות כדי להתאים לזרימות עבודה שונות:

• PinterestService הם שירותים חסרי מדינה שפועלים כבר זמן רב. רבות ממערכות הליבה שלנו מבוססות על קבוצה של שירותים כאלה.
• PinterestJobSet מדגמנת עבודות אצווה במחזור מלא. תרחיש נפוץ ב-Pinterest הוא שעבודות מרובות מרצות את אותם קונטיינרים במקביל, ללא קשר לתהליכים דומים אחרים.
• PinterestCronJob נמצא בשימוש נרחב בשילוב עם עומסים תקופתיים קטנים. זוהי עטיפה לעבודת קרון מקורית עם מנגנוני תמיכה של Pinterest שאחראים על אבטחה, תעבורה, יומנים ומדדים.
• PinterestDaemon כולל תשתית Daemons. המשפחה הזו ממשיכה לגדול ככל שאנו מוסיפים עוד תמיכה לאשכולות שלנו.
• PinterestTrainingJob משתרע על תהליכי Tensorflow ו- Pytorch, ומספק את אותה רמה של תמיכה בזמן ריצה כמו כל שאר ה-CRDs. מכיוון ש-Pinterest משתמשת באופן פעיל ב- Tensorflow ובמערכות למידת מכונה אחרות, הייתה לנו סיבה לבנות CRD נפרד סביבן.

אנחנו עובדים גם על PinterestStatefulSet, שיותאם בקרוב למחסני נתונים ומערכות מתקדמות אחרות.

תמיכה בזמן ריצה

כאשר פוד יישומים פועל על Kubernetes, הוא מקבל אוטומטית אישור לזהות את עצמו. אישור זה משמש לגישה לאחסון סודי או לתקשורת עם שירותים אחרים באמצעות mTLS. בינתיים, Configurator Init Container ו-Daemon יורידו את כל התלות הדרושות לפני הפעלת האפליקציה המכולה. כשהכל יהיה מוכן, ה-sidecar ו-Daemon ירשמו את כתובת ה-IP של המודול אצל Zookeeper שלנו כדי שלקוחות יוכלו לגלות אותה. כל זה יעבוד מכיוון שמודול הרשת הוגדר לפני הפעלת היישום.

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

בדיקות ו-QA

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

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

אלטרנטיבות

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

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

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

עבודה קרובה

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

• אוסף של אשכולות מפיץ יישומים גדולים על פני אשכולות שונים לצורך מדרגיות ויציבות.
• הבטחת יציבות אשכול, מדרגיות ונראות ליצירת קישוריות יישומים ו-SLAs.
• ניהול משאבים ומכסות כך שהאפליקציות לא יתנגשו זו בזו, והיקף האשכול נשלט מצידנו.
• פלטפורמת CI/CD חדשה לתמיכה ופריסה של יישומים ב-Kubernetes.

מקור: www.habr.com