werf - הכלי שלנו עבור CI / CD ב-Kubernetes (סקירה כללית ודוח וידאו)

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

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

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

מסירת קוד ל-Kubernetes

השיחה לא תהיה יותר על werf, אלא על CI/CD ב-Kubernetes, מה שמרמז שהתוכנה שלנו ארוזה בקונטיינרים של Docker (דיברתי על זה ב דו"ח 2016), ו-K8s ישמשו להפעלתו בייצור (עוד על זה ב השנה 2017).

איך נראה משלוח ב-Kubernetes?

• יש מאגר Git עם הקוד והוראות לבנייתו. האפליקציה מובנית בתמונת Docker ומתפרסמת ב-Docker Registry.
• אותו מאגר מכיל גם הוראות כיצד לפרוס ולהפעיל את האפליקציה. בשלב הפריסה, הנחיות אלו נשלחות אל Kubernetes, שמקבלת את התמונה הרצויה מהרישום ומשיקה אותה.
• בנוסף, יש בדרך כלל בדיקות. חלק מאלה ניתן לעשות בעת פרסום תמונה. אתה יכול גם (בעקבות אותן הוראות) לפרוס עותק של היישום (במרחב שמות נפרד של K8s או באשכול נפרד) ולהריץ שם בדיקות.
• לבסוף, אתה צריך מערכת CI שמקבלת אירועים מ-Git (או לחיצות על כפתור) וקוראת לכל השלבים המיועדים: לבנות, לפרסם, לפרוס, לבדוק.

יש כאן כמה הערות חשובות:

1. כי יש לנו תשתית בלתי ניתנת לשינוי (תשתית בלתי ניתנת לשינוי), תמונת האפליקציה המשמשת בכל השלבים (בימוי, הפקה וכו'), חייב להיות אחד. דיברתי על זה ביתר פירוט ועם דוגמאות. כאן.
2. מכיוון שאנו עוקבים אחר התשתית כגישת קוד (IAC), קוד היישום, הוראות ההרכבה וההפעלה שלו צריכים להיות בדיוק במאגר אחד. למידע נוסף על כך, ראה אותו דוח.
3. שרשרת משלוחים (מְסִירָה) בדרך כלל אנחנו רואים את זה כך: האפליקציה הורכבה, נבדקה, שוחררה (שלב השחרור) וזהו - המסירה בוצעה. אבל במציאות, המשתמש מקבל את מה שפרסמת, לא ואז כשמסרת את זה לייצור, וכשהוא היה מסוגל ללכת לשם וההפקה הזו עבדה. אז אני מאמין ששרשרת המשלוחים מסתיימת רק בשלב המבצעי (לָרוּץ), או ליתר דיוק, אפילו ברגע שבו הקוד הוסר מהייצור (החלפתו בחדש).

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

שלב בנייה

נראה שאפשר לדבר על בניית תמונות Docker בשנת 2019, כשכולם יודעים איך לכתוב Dockerfiles ולהפעיל docker build?.. להלן הניואנסים שהייתי רוצה לשים לב אליהם:

1. משקל תמונה חשוב, אז השתמש רב שלביםלהשאיר בתמונה רק את האפליקציה שבאמת נחוצה לפעולה.
2. מספר שכבות יש למזער על ידי שילוב שרשראות של RUN-פקודות לפי משמעות.
3. עם זאת, זה מוסיף בעיות איתור באגים, כי כאשר המכלול קורס, אתה צריך למצוא את הפקודה הנכונה מהשרשרת שגרמה לבעיה.
4. מהירות הרכבה חשוב כי אנחנו רוצים להפעיל שינויים במהירות ולראות את התוצאות. לדוגמה, אינך רוצה לבנות מחדש תלות בספריות שפה בכל פעם שאתה בונה יישום.
5. לעתים קרובות ממאגר Git אחד שאתה צריך תמונות רבות, שניתן לפתור על ידי קבוצה של Dockerfiles (או שלבים עם שם בקובץ אחד) וסקריפט Bash עם ההרכבה הרציפה שלהם.

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

1. לעתים קרובות בשלב ההרכבה אנחנו צריכים משהו הר (לדוגמה, שמור את התוצאה של פקודה כמו apt בספרייה של צד שלישי).
2. אנחנו רוצים בלתי אפשרי במקום לכתוב במעטפת.
3. אנחנו רוצים לבנות ללא Docker (למה אנחנו צריכים מכונה וירטואלית נוספת שבה אנחנו צריכים להגדיר הכל בשביל זה, כשכבר יש לנו אשכול Kubernetes שבו אנחנו יכולים להריץ קונטיינרים?).
4. הרכבה מקבילה, שניתן להבין בדרכים שונות: פקודות שונות מה- Dockerfile (אם נעשה שימוש רב-שלבי), מספר commits של אותו מאגר, מספר Dockerfile.
5. הרכבה מבוזרת: אנחנו רוצים לאסוף דברים בתרמילים שהם "זמניים" בגלל המטמון שלהם נעלם, מה שאומר שצריך לאחסן אותו איפשהו בנפרד.
6. לבסוף, ציינתי את פסגת הרצונות אוטומאגיה: זה יהיה אידיאלי ללכת למאגר, להקליד פקודה כלשהי ולקבל תמונה מוכנה, מורכבת עם הבנה של איך ומה לעשות נכון. עם זאת, אני אישית לא בטוח שניתן לצפות את כל הניואנסים בדרך זו.

והנה הפרויקטים:

• moby/buildkit - בונה מ- Docker Inc (כבר משולב בגרסאות הנוכחיות של Docker), שמנסה לפתור את כל הבעיות הללו;
• קאניקו - Builder מגוגל המאפשר לבנות ללא Docker;
• Buildpacks.io - הניסיון של CNCF ליצור קסם אוטומטי ובמיוחד פתרון מעניין עם בסיס מחדש לשכבות;
• ועוד חבורה של כלי עזר אחרים, כגון בונה, genuinetools/img...

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

הרכבה בוורף

אז הגענו werf (קודם המפורסם כמו dapp) — כלי עזר בקוד פתוח של חברת פלנט, שאנחנו מייצרים כבר שנים רבות. הכל התחיל לפני 5 שנים עם סקריפטים של Bash שמיטבו את ההרכבה של Dockerfiles, ובמשך 3 השנים האחרונות בוצע פיתוח מלא במסגרת פרויקט אחד עם מאגר Git משלו (תחילה ברובי, ואחר כך כתב מחדש to Go, ובאותו זמן שונה שם). אילו בעיות הרכבה נפתרות ב-werf?

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

שלב הפרסום ברישום (פרסם)

חייגנו docker push... - מה יכול להיות קשה בהעלאת תמונה לרישום? ואז נשאלת השאלה: "איזה תג אני צריך לשים על התמונה?" זה נובע מהסיבה שיש לנו Gitflow (או אסטרטגיית Git אחרת) ו-Kubernetes, והתעשייה מנסה להבטיח שמה שקורה ב-Kubernetes יבוא בעקבות מה שקורה ב-Git. אחרי הכל, גיט הוא מקור האמת היחיד שלנו.

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

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

אסטרטגיות תיוג

הראשון פשוט תג git. יש לנו רישום עם תמונה מתויגת כ 1.0. ל-Kubernetes יש במה והפקה, שם התמונה הזו מועלית. ב-Git אנחנו עושים commits ובשלב מסוים אנחנו מתייגים 2.0. אנו אוספים אותו לפי ההוראות מהמאגר ומניחים אותו ברישום עם התג 2.0. אנחנו מגלגלים את זה לבמה ואם הכל בסדר אז להפקה.

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

האפשרות השנייה היא git commit + תג. לסניף המאסטר יש תג 1.0; עבורו ברישום - תמונה שנפרסה לייצור. בנוסף, לאשכול Kubernetes יש קווי מתאר תצוגה מקדימה וקווי מתאר. לאחר מכן אנו עוקבים אחר Gitflow: בענף הראשי לפיתוח (develop) אנו יוצרים תכונות חדשות, וכתוצאה מכך מתבצעת commit עם המזהה #c1. אנו אוספים אותו ומפרסמים אותו ברישום באמצעות מזהה זה (#c1). עם אותו מזהה אנו מתגלגלים לתצוגה מקדימה. אנחנו עושים את אותו הדבר עם התחייבויות #c2 и #c3.

כשהבנו שיש מספיק תכונות, אנחנו מתחילים לייצב הכל. צור סניף ב-Git release_1.1 (על הבסיס #c3 של develop). אין צורך לאסוף את המהדורה הזו, כי... זה נעשה בשלב הקודם. לכן, אנחנו יכולים פשוט לגלגל את זה לבימוי. אנחנו מתקנים באגים בפנים #c4 ובאופן דומה מתגלגלים לבימוי. במקביל, הפיתוח מתבצע ב develop, שממנו נלקחים שינויים מעת לעת release_1.1. בשלב מסוים, אנו מקבלים comcompiled ומועלה ל-Staging, שאנו מרוצים ממנו (#c25).

לאחר מכן אנו ממזגים (עם הרצה קדימה) את ענף השחרור (release_1.1) במאסטר. שמנו תג עם הגרסה החדשה ב-commit הזה (1.1). אבל התמונה הזו כבר נאספת ברישום, אז כדי לא לאסוף אותה שוב, אנחנו פשוט מוסיפים תג שני לתמונה הקיימת (עכשיו יש לה תגיות ברישום #c25 и 1.1). לאחר מכן, אנו מגלגלים אותו לייצור.

יש חיסרון שרק תמונה אחת מועלית לסטייג'ינג (#c25), ובהפקה זה קצת שונה (1.1), אבל אנחנו יודעים ש"פיזית" אלו אותה תמונה מהרישום.

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

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

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

בואו נבנה ממנו קובץ לפי העיקרון הבא:

• SHA256 מהמזהים של התמונות בשימוש (ruby:2.3 и nginx:alpine), שהם סכומי ביקורת של תוכנם;
• כל הקבוצות (RUN, CMD וכולי.);
• SHA256 מקבצים שנוספו.

... ולקחת את הבדיקה (שוב SHA256) מקובץ כזה. זֶה חֲתִימָה כל מה שמגדיר את התוכן של תמונת Docker.

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

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

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

תיוג ב-werf

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

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

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

לפיכך, תמונות במה הן מטמון שניתן לאחסן בהפצה, והתמונות שכבר נוצרו ממנו מועלות ל-Docker Registry.

ניקוי הרישום

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

מהן אסטרטגיות הניקוי?

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

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

למה הגענו werf? אנחנו אוספים:

1. Git head: כל התגים, כל הסניפים - בהנחה שאנחנו צריכים את כל מה שמתויג ב-Git בתמונות (ואם לא, אז צריך למחוק את זה ב-Git עצמו);
2. כל התרמילים שנשאבים כעת אל Kubernetes;
3. ReplicaSets ישנים (מה ששוחרר לאחרונה), ואנחנו גם מתכננים לסרוק מהדורות של Helm ולבחור את התמונות האחרונות שם.

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

שלב הפריסה

הצהרות אמינה

הנקודה הראשונה שאליה ברצוני למשוך את תשומת הלב בפריסה היא השקת תצורת המשאב המעודכנת, המוצהרת בהצהרה. מסמך YAML המקורי המתאר את משאבי Kubernetes תמיד שונה מאוד מהתוצאה הפועלת בפועל באשכול. כי Kubernetes מוסיף לתצורה:

1. מזהים;
2. מידע שירות;
3. ערכי ברירת מחדל רבים;
4. קטע עם סטטוס נוכחי;
5. שינויים שבוצעו כחלק מ-webhook של קבלה;
6. התוצאה של עבודתם של בקרים שונים (והמתזמן).

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

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

יש גם מיזוג דו כיווני, אשר שונה בכך:

• משווה הוחל לאחרונה и חדש, אנו מסתכלים על מה שנמחק;
• משווה חדש и לחיות, אנו מסתכלים על מה שנוסף או השתנה;
• התיקון המסוכם מוחל עליו לחיות.

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

סטטוס השקה אמיתי

לאחר שמערכת ה-CI שלנו מייצרת תצורה חדשה עבור Kubernetes על סמך האירוע הבא, היא משדרת אותה לשימוש (להגיש מועמדות) לאשכול - באמצעות Helm or kubectl apply. לאחר מכן, מתרחש המיזוג N-way שתואר כבר, שאליו מגיב ה-API של Kubernetes באישור למערכת ה-CI, וזה למשתמש שלה.

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

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

ההתנהגות של עוקב זה ברמת werf מוגדרת באמצעות הערות המוצבות על Deployments או StatefulSets. הערה ראשית - fail-mode - מבין את המשמעויות הבאות:

• IgnoreAndContinueDeployProcess - אנו מתעלמים מהבעיות של הפעלת רכיב זה וממשיכים בפריסה;
• FailWholeDeployProcessImmediately - שגיאה ברכיב זה עוצרת את תהליך הפריסה;
• HopeUntilEndOfDeployProcess - אנו מקווים שהרכיב הזה יעבוד עד סוף הפריסה.

לדוגמה, השילוב הזה של משאבים וערכי הערות fail-mode:

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

יש עוד שתי הערות עבור kubedog ב-werf:

• failures-allowed-per-replica - מספר הנפילות המותרות עבור כל העתק;
• show-logs-until - מסדיר את הרגע שבו werf מציג (ב-stdout) יומנים מכל התרמילים המגולגלים. ברירת המחדל היא PodIsReady (כדי להתעלם מהודעות שאנחנו כנראה לא רוצים כשהתנועה מתחילה להגיע לפוד), אבל הערכים תקפים גם: ControllerIsReady и EndOfDeploy.

מה עוד אנחנו רוצים מהפריסה?

בנוסף לשתי הנקודות שכבר תוארו, נרצה:

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

תוצאות של

עבורנו כחברה, כדי ליישם את כל הניואנסים המתוארים בשלבי אספקה ​​שונים (בנייה, פרסום, פריסה), מערכת CI וכלי עזר מספיקים werf.

במקום מסקנה:

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

סרטונים ושקופיות

סרטון מההופעה (~47 דקות):

הצגת הדו"ח:

נ.ב.

דיווחים נוספים על Kubernetes בבלוג שלנו:

• «קנה מידה אוטומטי וניהול משאבים ב- Kubernetes» (דמיטרי סטוליארוב; 27 באפריל 2019 ב"שביתה");
• «הרחבה והשלמה של Kubernetes» (אנדריי פולובוב; 8 באפריל 2019 ב-Saint HighLoad++);
• «מסדי נתונים ו-Kubernetes» (דמיטרי סטוליארוב; 8 בנובמבר 2018 ב-HighLoad++);
• «ניטור ו-Kubernetes» (דמיטרי סטוליארוב; 28 במאי 2018 ב-RootConf);
• «שיטות עבודה מומלצות ל-CI/CD עם Kubernetes ו-GitLab» (דמיטרי סטוליארוב; 7 בנובמבר 2017 ב-HighLoad++);
• «הניסיון שלנו עם Kubernetes בפרויקטים קטנים» (דמיטרי סטוליארוב; 6 ביוני 2017 ב-RootConf).

מקור: www.habr.com