🥇מעבר טינדר ל-Kubernetes

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

למה?

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

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

התהליך התברר כקשה. במהלך ההגירה שלנו בתחילת 2019, אשכול Kubernetes הגיע למסה קריטית והתחלנו להיתקל בבעיות שונות עקב נפח תעבורה, גודל אשכול ו-DNS. לאורך הדרך, פתרנו הרבה בעיות מעניינות הקשורות להעברת 200 שירותים ותחזוקת אשכול Kubernetes המורכב מ-1000 צמתים, 15000 פודים ו-48000 קונטיינרים פועלים.

איך?

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

בניית תמונות עבור Kubernetes

יש לנו למעלה מ-30 מאגרי קוד מקור עבור שירותי מיקרו הפועלים על אשכול Kubernetes. הקוד במאגרים אלה כתוב בשפות שונות (לדוגמה, Node.js, Java, Scala, Go) עם מספר סביבות זמן ריצה עבור אותה שפה.

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

איור 1-1. תהליך בנייה סטנדרטי באמצעות קונטיינר Builder

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

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

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

ארכיטקטורת אשכולות והגירה של Kubernetes

ניהול גודל אשכול

החלטנו להשתמש kube-aws לפריסת אשכולות אוטומטית במופעי Amazon EC2. בהתחלה הכל עבד במאגר אחד משותף של צמתים. מהר מאוד הבנו את הצורך להפריד עומסי עבודה לפי גודל וסוג מופע כדי לעשות שימוש יעיל יותר במשאבים. ההיגיון היה שהפעלת מספר תרמילים מרובים פתילים טעונים התבררה כצפויה יותר מבחינת ביצועים מאשר הדו-קיום שלהם עם מספר רב של פוטים עם חיבורים בודדים.

בסוף הסתפקנו ב:

m5.4x להגדיל - לניטור (פרומתאוס);
c5.4x להגדיל - עבור עומס עבודה של Node.js (עומס עבודה עם חוט יחיד);
c5.2x להגדיל - עבור Java ו-Go (עומס עבודה מרובה חוטים);
c5.4x להגדיל - עבור לוח הבקרה (3 צמתים).

הגירה

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

נקודות קצה אלו נוצרו באמצעות קבוצות משוקללות של רשומות DNS שבהן היו CNAMEs שהצביעו על כל ELB חדש. כדי לעבור, הוספנו ערך חדש המצביע על ה-ELB החדש של שירות Kubernetes עם משקל של 0. לאחר מכן הגדרנו את Time To Live (TTL) של הערך שהוגדר ל-0. לאחר מכן, המשקל הישן והחדש היו מותאם לאט, ובסופו של דבר 100% מהעומס נשלח לשרת חדש. לאחר השלמת המעבר, ערך ה-TTL חזר לרמה נאותה יותר.

מודולי ה-Java שהיו לנו יכלו להתמודד עם DNS נמוך של TTL, אבל יישומי ה-Node לא יכלו. אחד המהנדסים כתב מחדש חלק מקוד מאגר החיבור ועטף אותו במנהל שעדכן את המאגרים כל 60 שניות. הגישה שנבחרה עבדה טוב מאוד וללא כל ירידה ניכרת בביצועים.

השיעורים

הגבולות של מארג הרשת

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

ישנן שלוש אפשרויות לינוקס הקשורות למטמון ARP:

(מקור)

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

אנו משתמשים פלָנֶל כמארג רשת ב- Kubernetes. מנות מועברות דרך VXLAN. VXLAN היא מנהרה L2 המורמת על גבי רשת L3. הטכנולוגיה משתמשת באנקפסולציה של MAC-in-UDP (MAC Address-in-User Datagram Protocol) ומאפשרת הרחבה של מקטעי רשת שכבה 2. פרוטוקול התחבורה ברשת מרכז הנתונים הפיזי הוא IP פלוס UDP.

איור 2-1. דיאגרמת פלנל (מקור)

איור 2-2. חבילת VXLAN (מקור)

כל צומת עובד של Kubernetes מקצה מרחב כתובות וירטואלי עם מסיכת /24 מבלוק /9 גדול יותר. עבור כל צומת זה אמצעים ערך אחד בטבלת הניתוב, ערך אחד בטבלת ה-ARP (בממשק flannel.1), וערך אחד בטבלת המיתוג (FDB). הם מתווספים בפעם הראשונה שצומת עובד מופעל או בכל פעם שמתגלה צומת חדש.

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

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

בזמן הכשל, היו 605 צמתים באשכול. מהטעמים שצוינו לעיל, די היה בכך כדי להתגבר על המשמעות gc_thresh3, שהיא ברירת המחדל. כשזה קורה, לא רק שמתחילות להישמט מנות, אלא שכל מרחב הכתובות הווירטואלי של פלנל עם מסיכת /24 נעלם מטבלת ה-ARP. תקשורת ב-Pod ושאילתות DNS נקטעות (DNS מתארח באשכול; קרא בהמשך מאמר זה לפרטים).

כדי לפתור בעיה זו, אתה צריך להגדיל את הערכים gc_thresh1, gc_thresh2 и gc_thresh3 והפעל מחדש את Flanell כדי לרשום מחדש את הרשתות החסרות.

שינוי קנה מידה DNS לא צפוי

במהלך תהליך ההגירה, השתמשנו באופן פעיל ב-DNS לניהול תעבורה והעברה הדרגתית של שירותים מהתשתית הישנה ל-Kubernetes. הגדרנו ערכי TTL נמוכים יחסית עבור RecordSets משויכים ב-Route53. כאשר התשתית הישנה פעלה על מופעי EC2, תצורת הפותר שלנו הצביעה על אמזון DNS. לקחנו את זה כמובן מאליו וההשפעה של ה-TTL הנמוך על השירותים שלנו ושירותי אמזון (כגון DynamoDB) נעלמה ברובה.

כשהעברנו שירותים ל-Kubernetes, גילינו ש-DNS מעבד 250 אלף בקשות בשנייה. כתוצאה מכך, יישומים החלו לחוות פסק זמן קבוע ורציני עבור שאילתות DNS. זה קרה למרות מאמצים מדהימים לייעל ולהעביר את ספק ה-DNS ל-CoreDNS (שבעומס השיא הגיע ל-1000 פודים הפועלים על 120 ליבות).

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

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

אין צורך ב-SNAT כי התעבורה נשארת בתוך הצומת. אין צורך לנתב אותו דרך הממשק eth0.
אין צורך ב-DNAT מכיוון שכתובת ה-IP של היעד היא מקומית לצומת, ולא תרמיל שנבחר באקראי לפי הכללים iptables.

החלטנו להישאר עם הגישה הזו. CoreDNS נפרס כ-DaemonSet ב-Kubernetes והטמענו שרת DNS מקומי של צומת ב- resolve.conf כל תרמיל על ידי הצבת דגל --cluster-dns צוותים קובלט . פתרון זה התברר כיעיל עבור פסקי זמן של DNS.

עם זאת, עדיין ראינו אובדן מנות ועלייה במונה insert_failed בממשק פלנל. זה נמשך לאחר הטמעת הפתרון לעקיפת הבעיה מכיוון שהצלחנו לבטל את SNAT ו/או DNAT עבור תעבורת DNS בלבד. תנאי המרוץ נשמרו לסוגי תנועה אחרים. למרבה המזל, רוב החבילות שלנו הן TCP, ואם מתרחשת בעיה הן פשוט מועברות מחדש. אנחנו עדיין מנסים למצוא פתרון מתאים לכל סוגי התנועה.

שימוש ב-Envoy לאיזון עומסים טוב יותר

כשהעברנו שירותי backend ל-Kubernetes, התחלנו לסבול מעומס לא מאוזן בין התרמילים. מצאנו ש-HTTP Keepalive גרם לחיבורי ELB להיתקע על הפודים המוכנים הראשונים של כל פריסה שהושקה. לפיכך, עיקר התנועה עברה באחוז קטן מהפודים הזמינים. הפתרון הראשון שבדקנו היה להגדיר את MaxSurge ל-100% על פריסות חדשות עבור תרחישים גרועים ביותר. ההשפעה התבררה כלא משמעותית ולא מבטיחה במונחים של פריסות גדולות יותר.

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

כבר מזמן רצינו להעריך במלואו שַׁגְרִיר. המצב הנוכחי אפשר לנו לפרוס אותו בצורה מאוד מוגבלת ולקבל תוצאות מיידיות. Envoy הוא פרוקסי בעל ביצועים גבוהים, קוד פתוח, שכבה XNUMX המיועד ליישומי SOA גדולים. הוא יכול ליישם טכניקות מתקדמות של איזון עומסים, כולל ניסיונות חוזרים אוטומטיים, מפסקים והגבלת קצב גלובלי. (הערה. תרגום: אתה יכול לקרוא עוד על זה ב מאמר זה על Istio, המבוססת על Envoy.)

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

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

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

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

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

איור 3-1. התכנסות מעבד של שירות אחד במהלך המעבר ל-Envoy

תוצאה סופית

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

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

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

נ.ב מהמתרגם

קרא גם סדרת מאמרים בבלוג שלנו:

מקור: www.habr.com

מעבר טינדר ל-Kubernetes