הממצאים שלנו משנה של העברת GitLab.com ל-Kubernetes

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

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

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

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

צעדים ראשונים ל-Kubernetes ול-GitLab המבוסס על ענן

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

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

תכונות של GitLab.com ב-Kubernetes

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

במקרה של ה-frontend, הסוגים הללו מחולקים לבקשות לאינטרנט, API, Git SSH/HTTPS ו-Registry. במקרה של ה-backend, אנו מפצלים את העבודות בתור לפי מאפיינים שונים בהתאם גבולות משאבים מוגדרים מראש, המאפשרים לנו להגדיר יעדי שירות ברמת שירות (SLOs) עבור עומסי עבודה שונים.

כל שירותי GitLab.com הללו מוגדרים באמצעות תרשים GitLab Helm ללא שינוי. התצורה מתבצעת בתרשימים, שניתן להפעילם באופן סלקטיבי ככל שאנו מעבירים שירותים בהדרגה לאשכול. למרות שהחלטנו לא לכלול חלק מהשירותים הממלכתיים שלנו בהעברה, כמו Redis, Postgres, GitLab Pages ו-Gitaly, השימוש ב-Kubernetes מאפשר לנו לצמצם באופן קיצוני את מספר ה-VMs ששף מנהל כיום.

נראות וניהול של תצורת Kubernetes

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

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

• k8s-workloads/gitlab-com - מסגרת התצורה של GitLab.com עבור תרשים GitLab Helm;
• k8s-workloads/gitlab-helmfiles - מכיל תצורות לשירותים שאינם משויכים ישירות לאפליקציית GitLab. אלה כוללים תצורות לרישום וניטור אשכולות, כמו גם כלים משולבים כמו PlantUML;
• Gitlab-com-infrastructure - תצורת Terraform עבור Kubernetes ותשתית VM מדור קודם. כאן אתה מגדיר את כל המשאבים הדרושים להפעלת האשכול, כולל האשכול עצמו, מאגרי צמתים, חשבונות שירות והזמנות IP.

תצוגה ציבורית מוצגת כאשר מתבצעים שינויים. סיכום קצר עם קישור ל-diff המפורט ש-SRE מנתח לפני ביצוע שינויים באשכול.

עבור SRE, הקישור מוביל להפרש מפורט בהתקנת GitLab, המשמשת לייצור והגישה אליו מוגבלת. זה מאפשר לעובדים ולקהילה, ללא גישה לפרויקט התפעולי (שפתוח רק ל-SREs), לצפות בשינויי תצורה מוצעים. על ידי שילוב של מופע GitLab ציבורי עבור קוד עם מופע פרטי עבור צינורות CI, אנו שומרים על זרימת עבודה אחת תוך הבטחת עצמאות מ-GitLab.com עבור עדכוני תצורה.

מה גילינו במהלך ההגירה

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

1. עלויות מוגברות עקב תנועה בין אזורי זמינות

סטטיסטיקות יציאה יומיות (בתים ליום) עבור צי מאגר Git ב-GitLab.com

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

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

2. מגבלות, בקשות משאבים וקנה מידה

מספר העתקים המעבדים תעבורת ייצור ב-registry.gitlab.com. שיא התנועה ב-~15:00 UTC.

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

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

3. מדדים ויומנים

חטיבת התשתיות מתמקדת בהשהיה, שיעורי שגיאות ורוויה עם התקנה יעדי רמת השירות (SLO) מקושר ל זמינות כללית של המערכת שלנו.

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

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

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

4. העברת תעבורה לאשכול חדש

עבור GitLab.com, חלק מהשרתים מוקדש שלב קנרי. Canary Park משרת את הפרויקטים הפנימיים שלנו ויכול גם מופעל על ידי משתמשים. אבל הוא נועד בעיקר לבחון שינויים שבוצעו בתשתית וביישום. השירות המועבר הראשון התחיל בקבלת כמות מוגבלת של תעבורה פנימית, ואנו ממשיכים להשתמש בשיטה זו כדי להבטיח ש-SLO מתקיימים לפני שליחת כל התעבורה לאשכול.

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

5. יכולות מילואים של תרמילים והשימוש בהם

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

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

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

מסקנה

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

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

• «למה אנחנו עוברים ל- Kubernetes?";
• «GitLab.com על Kubernetes";
• אפי על העברת GitLab.com ל-Kubernetes.

נ.ב מהמתרגם

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

• «3 שנים עם Kubernetes בייצור: הנה מה שאנחנו מבינים";
• «10 טעויות נפוצות בשימוש ב-Kubernetes";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 3: GitHub";
• «מעבר טינדר ל-Kubernetes".

מקור: www.habr.com