K8S מסע רב אשכולות

היי הבר!

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

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

• מחלקת הפיתוח שלנו מורכבת מ-100+ אנשים, כולל יותר מ-10 צוותים שונים עם תהליכי QA, DevOps ו-Scrum עצמאיים. מחסנית פיתוח - Python, PHP, C++, Java ו-Golang. 
• גודל סביבות הבדיקה והייצור הוא כ-2000 מכולות כל אחת. הם מריצים את Rancher v1.6 בווירטואליזציה משלהם ותחת VMware. 

מוטיבציה

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

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

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

צעדים ראשונים

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

לאחר מכן עלתה השאלה של בחירת כלי ליצירת אשכולות. השווינו את הפתרונות הפופולריים ביותר: kops, kubespray, kubeadm.

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

והמנצח היה:

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

בעיות ראשונות

Ansible זה מה ש-kubespray בנוי עליו, זה לא כלי שמאפשר לך לעקוב אחר IaC: בעת הפעלה/הסרה של צמתים, משהו כל הזמן השתבש ונדרשת איזושהי התערבות, וכאשר משתמשים במערכת הפעלה שונות, ה-Playbook התנהג אחרת. אחרת . ככל שמספר הקבוצות והצמתים באשכול גדל, התחלנו לשים לב שלוקח יותר ויותר זמן להשלים את ספר המשחקים, וכתוצאה מכך השיא שלנו עמד על 3,5 שעות, מה לגבי שלך? 🙂

וזה נראה כאילו kubespray הוא רק Ansible, והכל ברור במבט ראשון, אבל:

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


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

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

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

מה לעשות?

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

אז קיבלנו אחד שני:

ואז האשכול השלישי: 

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

Kubernetes מלא היה מגיע! זה סוג של MultiKubernetes, מסתבר. 

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

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

בשלב הראשון של המחקר שלנו, Rancher Labs כבר הוציאה את המהדורה הראשונה של גרסה 2, אבל למרות שניתן היה להעלות אותה מהר מאוד על ידי השקת קונטיינר ללא תלות חיצונית עם כמה פרמטרים או שימוש בתרשים HELM הרשמי, זה נראה גס לנו, ולא ידענו אם נוכל לסמוך על ההחלטה הזו אם היא תפתח או תינטש במהירות. גם פרדיגמת cluster = clicks ב-UI עצמו לא התאימה לנו, ולא רצינו להיות קשורים ל-RKE, שכן מדובר בכלי ממוקד למדי. 

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

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

מה קרה

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

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

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

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

מקור: www.habr.com