Kubernetes ישתלט על העולם. מתי ואיך?

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

ראיון מקורי האזינו לפודקאסט ב-DevOps Deflop - פודקאסט בשפה הרוסית על DevOps, ולהלן גרסת הטקסט.

כאן ומטה הוא שואל שאלות ויטלי חברוב מהנדס מ- Express42.

על "פלנט"

- שלום דימה. אתה המנהל הטכני"פלאנט" וגם המייסד שלה. אנא ספר לנו מה החברה עושה ומה אתה בתוכה?

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




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

על Kubernetes

- לאחרונה ראיתי הרבה דיווחים מ-Flant ו מאמרים על Kubernetes. איך הגעת לזה?

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

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

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

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

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

על Kubernetes

- האם אתה מעורב ישירות בפיתוח של Kubernetes עצמו?

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

— במקביל, האם אתה מפתח הרבה מהכלים שלך סביב Kubernetes?

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

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

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

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

כלי פלנטה

- אני יודע שלפלנט יש כעת אופרטורים, אופרטורים של מעטפת וכלי dapp/werf. לפי הבנתי, זהו אותו מכשיר בגלגולים שונים. אני גם מבין שיש הרבה יותר כלים שונים בתוך פלאונט. זה נכון?

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

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

פיתוח מערכת אקולוגית

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

דמיטרי: ברוסיה, מבין החברות שפועלות בשוק שלנו, אף אחד אפילו לא קרוב. כמובן שזו אמירה קולנית, כי יש שחקנים מרכזיים כמו Mail ו-Yandex – גם הם עושים משהו עם Kubernetes, אבל אפילו הם לא מתקרבים לתרומה של חברות בעולם כולו שעושות הרבה יותר מאיתנו. קשה להשוות בין פלנט, שיש לה צוות של 80 אנשים, לבין רד האט, שיש לה 300 מהנדסים לכל Kubernetes בלבד, אם אני לא טועה. קשה להשוות. יש לנו 6 אנשים במחלקת RnD, כולל אותי, שחתכו את כל הכלים שלנו. 6 אנשים מול 300 מהנדסי Red Hat - איכשהו קשה להשוות.

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

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

אני מבין הכל לגבי התפקיד מהנדס DevOps, כולם מבינים הכל ורגילים לקרוא למהנדסי DevOps מהנדסי DevOps, לא נדון בזה. כל 40 מהנדסי ה-DevOps המדהימים הללו מתמודדים ופותרים בעיות מדי יום, אנחנו פשוט מנתחים את החוויה הזו ומנסים להכליל. אנחנו מבינים שאם זה יישאר בתוכנו, אז בעוד שנה-שנתיים הכלי יהיה חסר תועלת, כי איפשהו בקהילה תופיע טולה מוכנה. אין טעם לצבור את החוויה הזו באופן פנימי - זה פשוט שואב אנרגיה וזמן ל-dev/null. ואנחנו לא מרחמים על זה בכלל. אנחנו מפרסמים הכל בהנאה רבה ומבינים שצריך לפרסם, לפתח, לקדם, לקדם, כדי שאנשים ישתמשו בו ויוסיפו את הניסיון שלהם – ואז הכל גדל וחי. ואז אחרי שנתיים המכשיר לא נכנס לפח. לא חבל להמשיך לשפוך כוח, כי ברור שמישהו משתמש בכלי שלך, ואחרי שנתיים כולם משתמשים בו.

זה חלק מהאסטרטגיה הגדולה שלנו עם dapp/werf. אני לא זוכר מתי התחלנו להכין אותו, זה נראה כאילו לפני 3 שנים. בתחילה, זה היה בדרך כלל על הקליפה. זה היה סופר הוכחה לקונספט, פתרנו כמה מהבעיות המיוחדות שלנו - זה עבד! אבל יש בעיות עם המעטפת, אי אפשר להרחיב אותה יותר, תכנות על המעטפת זו משימה אחרת. היה לנו הרגל לכתוב ברובי, בהתאם, עשינו מחדש משהו ברובי, פיתחנו, פיתחנו, פיתחנו, ונתקלנו בעובדה שהקהילה, הקהל שלא אומר "אנחנו רוצים את זה או אנחנו לא רוצים את זה, " מפנה את האף לעבר רובי, כמה זה מצחיק? הבנו שאנחנו צריכים לכתוב את כל הדברים האלה ב-Go רק כדי לעמוד בנקודה הראשונה ברשימת הבדיקה: כלי DevOps צריך להיות בינארי סטטי. להיות Go או לא זה לא כל כך חשוב, אבל בינארי סטטי שנכתב ב-Go עדיף.

השקענו את האנרגיה שלנו, כתבנו מחדש את ה-dapp ב-Go וקראו לזה werf. ה-Dapp כבר לא נתמך, לא מפותח, פועל בגרסה עדכנית כלשהי, אבל יש נתיב שדרוג מוחלט לראש, ותוכל לעקוב אחריו.

מדוע נוצר ה-Dapp?

- האם תוכל לספר לנו בקצרה מדוע ה-dapp נוצר, אילו בעיות הוא פותר?

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

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

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

מסתבר שהלם הוא רק מעבד קדם טקסט שטוען נתונים לתוך Kubernetes.

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

תוכניות

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

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

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

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

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

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

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

האם קשה לתחזק Kubernetes?

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

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

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

דמיטרי: זה ככה.

- כמה קשה לקחת ולהתקין את Kubernetes מאפס כדי שיהיה מוכן לייצור?

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

התקנת Kubernetes והפעלתו היא קלה: צ'יק! - מותקן, יש הרבה שיטות התקנה. אבל מה קורה כשצצות בעיות?

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

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

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

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

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

מה קרה? ביצועים מגניבים מאוד, תכונות מגניבות - פשוט מגניב! אבל אנחנו מסתכלים על זה ורואים שבכל מכונה יש תוכנית שמתחברת ל-Kubernetes API, ועל סמך הנתונים שהיא מקבלת מה-API הזה, מייצרת קוד C ומרכיבה קבצים בינאריים שהיא טוענת לתוך הקרנל כך שה-hooks האלה יעבדו. במרחב הקרנל.

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

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

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

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

לגבי גישת "יהיה לי מזל".

— האם יש חברות שבהן כמעט מובטח שהניואנסים האלה יופיעו? נניח ש- Yandex תעביר פתאום את כל השירותים ל- Kubernetes, יהיה שם עומס עצום.

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

יש לי אובונטו 16.04. אפשר לומר שזו גרסה ישנה, ​​אבל אנחנו עדיין על זה כי זה LTS. יש systemd, שהניואנס שלה הוא שהוא לא מנקה קבוצות C. Kubernetes משיקה פודים, יוצרת קבוצות C, ואז מוחקת פודים, ואיכשהו מסתבר - אני לא זוכר את הפרטים, מצטער - שנותרו פרוסות מערכת. זה מוביל לעובדה שעם הזמן כל מכונית מתחילה להאט מאוד. זו אפילו לא שאלה לגבי עומס גבוה. אם מושקים פודים קבועים, למשל, אם יש Cron Job שמייצר כל הזמן פודים, אז המכונה עם אובונטו 16.04 תתחיל להאט לאחר שבוע. יהיה ממוצע עומס גבוה כל הזמן בגלל העובדה שנוצרו חבורה של קבוצות C. זו הבעיה שאיתה יתמודד כל אדם שפשוט יתקין את אובונטו 16 ו-Kubernetes למעלה.

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

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

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

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

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

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

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

האם אנחנו צריכים מכולות?

- האם אתה יכול לספר לנו עד כמה Kubernetes נפוצה ברוסיה?

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

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

לא יהיה דבר מלבד Kubernetes.

זהו מחליף משחק מוחלט בתחום ניהול התשתיות. פשוט מוחלט - זהו, לא עוד Ansible, Chef, מכונות וירטואליות, Terraform. אני לא מדבר על שיטות החווה הקיבוצית הישנות. Kubernetes הוא מחליף מוחלט, ועכשיו זה יהיה רק ​​ככה.

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

— כלומר, אותן חברות שעדיין לא עברו ל-Kubernetes בהחלט יעברו אליה או יישארו בשכחה. הבנתי אותך נכון?

דמיטרי: זה גם לא לגמרי נכון. לדוגמה, אם יש לנו את המשימה להפעיל שרת DNS, אז ניתן להפעיל אותו על FreeBSD 4.10 והוא יכול לעבוד בצורה מושלמת במשך 20 שנה. פשוט תעבוד וזהו. אולי בעוד 20 שנה משהו יצטרך להתעדכן פעם אחת. אם אנחנו מדברים על תוכנה בפורמט שהשקנו והיא למעשה עובדת שנים רבות ללא עדכונים, ללא שינויים, אז כמובן שלא יהיו Kubernetes. הוא לא נחוץ שם.

כל מה שקשור ל-CI/CD - בכל מקום בו יש צורך ב-Continuous Delivery, היכן שצריך לעדכן גרסאות, לבצע שינויים פעילים, בכל מקום בו צריך לבנות סובלנות תקלות - רק Kubernetes.

לגבי שירותי מיקרו

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

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

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

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

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

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

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

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

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

על אמזון וגוגל

— האם מארח מפתרון מאמזון או גוגל יכול להיחשב כמיקור חוץ?

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

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

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

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

מי צריך Kubernetes?

- ובכל זאת, מי צריך Kubernetes? מי כבר צריך לעבור ל-Kubernetes, מיהו הלקוח הטיפוסי של Flaunt שמגיע במיוחד עבור Kubernetes?

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

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

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

תשובה לשאלה מי צריך Kubernetes - אף אחד לא צריך Kubernetes.

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

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

הניסוח שאנו או כל אחד אחר צריכים Kubernetes אינו נכון.

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

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

התשובה הסופית היא: אתה לא צריך Kubernetes. אתה צריך לפתור את הבעיות שלך.

מה שאתה יכול להשיג הוא:

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

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

לגבי חסר שרת

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

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

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

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

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

איך Kubernetes יתפתח

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

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

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

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

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

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

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

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

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

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

מה לעשות עם מהנדסים?

- אז מה יקרה למהנדסים ומנהלי המערכת שתומכים ב-Kubernetes?

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

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

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

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

DevOps או הנדסת מערכות לא ייעלמו - עבודה ברמה גבוהה ויעילות יגדלו.

— שמעתי גם רעיון מעניין שהעבודה דווקא תגדל.

דמיטרי: כמובן, מאה אחוז! כי כמות התוכנה שאנחנו כותבים גדלה כל הזמן. מספר הבעיות שאנו פותרים באמצעות תוכנה גדל כל הזמן. כמות העבודה הולכת וגדלה. עכשיו שוק ה-DevOps מאוד מחומם יתר על המידה. ניתן לראות זאת בציפיות השכר. בצורה טובה, בלי להיכנס לפרטים, צריכים להיות זוטרים שרוצים X, בינוניים שרוצים 1,5X, וקשישים שרוצים 2X. ועכשיו, אם מסתכלים על שוק השכר של DevOps במוסקבה, זוטר רוצה מ-X ל-3X ובכיר רוצה מ-X ל-3X.

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

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

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

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

היו מוכנים לפניות חדות של 180 מעלות. אני לא שולל מצב שבו משהו משתנה באופן קיצוני, משהו חדש מומצא - זה קורה. לִקְפּוֹץ! - ועכשיו אנחנו פועלים אחרת. חשוב להיות מוכנים לכך ולא לדאוג. יכול לקרות שמחר כל מה שאעשה יתברר כמיותר - כלום, למדתי כל חיי ומוכנה ללמוד עוד משהו. זאת לא בעיה. אין צורך לפחד מביטחון תעסוקתי, אבל צריך להיות מוכנים ללמוד כל הזמן משהו חדש.

איחולים ודקת פרסום

- יש לך איזושהי משאלה?

דמיטרי: כן, יש לי כמה משאלות.

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

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

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

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

- תודה רבה לך!

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

בראיון, דמיטרי נגע בסוגיית werf. כעת מדובר בסכין שוויצרית אוניברסלית שפותרת כמעט את כל הבעיות. אבל זה לא תמיד היה כך. עַל DevOpsConf  בפסטיבל RIT++ דמיטרי סטוליארוב יספר לך על הכלי הזה בפירוט. בדוח "werf הוא הכלי שלנו ל-CI/CD ב-Kubernetes" יהיה הכל: בעיות וניואנסים נסתרים של Kubernetes, אפשרויות לפתרון קשיים אלה והיישום הנוכחי של werf בפירוט. הצטרפו אלינו ב-27 וב-28 במאי, ניצור את הכלים המושלמים.

מקור: www.habr.com