הכירו את Helm 3

הערה. תרגום: 16 במאי השנה מהווה אבן דרך משמעותית בפיתוח מנהל החבילות של Kubernetes - Helm. ביום זה הוצגה מהדורת האלפא הראשונה של הגרסה הראשית העתידית של הפרויקט - 3.0 -. שחרורו יביא שינויים משמעותיים ומיוחלים בהלם, אשר רבים בקהילת Kubernetes תולים עבורם תקוות גדולות. אנחנו עצמנו אחד מאלה, מכיוון שאנו משתמשים באופן פעיל בהלם לפריסת יישומים: שילבנו אותו בכלי שלנו להטמעת CI/CD werf ומדי פעם אנו תורמים את תרומתנו לפיתוח הנחל. תרגום זה משלב 7 הערות מהבלוג הרשמי של Helm, המוקדשים למהדורת האלפא הראשונה של Helm 3 ומדברות על ההיסטוריה של הפרויקט והמאפיינים העיקריים של Helm 3. מחברם הוא מאט "בקונגובלר" פישר, עובד של מיקרוסופט ואחד המתחזקים המרכזיים של Helm.

ב-15 באוקטובר 2015 נולד הפרויקט הידוע כיום בשם Helm. שנה בלבד לאחר הקמתה, קהילת Helm הצטרפה ל-Kubernetes, תוך כדי עבודה פעילה על Helm 2. ביוני 2018, Helm הצטרף ל-CNCF כפרויקט מתפתח (אינקובציה). מהר קדימה להווה, ומהדורת האלפא הראשונה של Helm 3 החדש יוצאת לדרך. (מהדורה זו כבר התרחש באמצע מאי - כ. תרגום).

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

סיכום:

• ההיסטוריה של יצירתו של Helm;
• פרידה עדינה מטילר;
• מאגרי תרשימים;
• ניהול שחרור;
• שינויים בתלות בתרשים;
• טבלאות ספרייה;
• מה הלאה?

ההיסטוריה של הלם

לידה

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

באמצע 2015, החלטנו לשנות מסלול והעברנו את Deis (באותה תקופה שונה שם ל-Deis Workflow) מ-Fleet ל-Kubernetes. אחד הראשונים שעוצבו מחדש היה כלי ההתקנה. deisctl. השתמשנו בו כדי להתקין ולנהל את Deis Workflow באשכול הצי.

Helm 1 נוצר בדמותם של מנהלי חבילות מפורסמים כמו Homebrew, apt ו-yum. המטרה העיקרית שלו הייתה לפשט משימות כמו אריזה והתקנת אפליקציות ב-Kubernetes. Helm הוצג רשמית בשנת 2015 בכנס KubeCon בסן פרנסיסקו.

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

* הערה. תרגום: מהגרסה הראשונה של Helm, תחביר YAML נבחר לתיאור משאבי Kubernetes, ותבניות Jinja וסקריפטים של Python נתמכו בעת כתיבת תצורות. כתבנו עוד על זה ועל המבנה של הגרסה הראשונה של הלם בכלל בפרק "קיצור תולדות הלם" החומר הזה.

לדוגמה, כדי להחליף שדה בקובץ YAML, היה עליך להוסיף את המבנה הבא למניפסט:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

זה נהדר שמנועי תבנית קיימים היום, לא?

מסיבות רבות, המתקין הקדום הזה של Kubernetes דרש רשימה מקודדת של קבצי מניפסט והוציא לפועל רק רצף קטן וקבוע של אירועים. זה היה כל כך קשה לשימוש שצוות ה-Deis Workflow R&D התקשה כשניסו להעביר את המוצר שלהם לפלטפורמה הזו – אולם זרעי הרעיון כבר נזרעו. הניסיון הראשון שלנו היה הזדמנות למידה מצוינת: הבנו שאנחנו באמת נלהבים ליצור כלים פרגמטיים הפותרים בעיות יומיומיות עבור המשתמשים שלנו.

בהתבסס על הניסיון של טעויות העבר, התחלנו לפתח את Helm 2.

ביצוע הגה 2

בסוף 2015, צוות גוגל פנה אלינו. הם עבדו על כלי דומה עבור Kubernetes. Deployment Manager for Kubernetes היה יציאה של כלי קיים ששימש עבור Google Cloud Platform. "האם נרצה," הם שאלו, "לבלות כמה ימים בדיון על הדמיון וההבדלים?"

בינואר 2016, צוותי ההגה ומנהל הפריסה נפגשו בסיאטל כדי להחליף רעיונות. המשא ומתן הסתיים בתוכנית שאפתנית: לשלב את שני הפרויקטים ליצירת Helm 2. יחד עם דייס וגוגל, החבר'ה מ SkippBox (כיום חלק מביטנאמי - בערך תרגום), והתחלנו לעבוד על Helm 2.

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

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

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

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

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

פרידה ענוגה מטילר

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

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

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

המטרה העיקרית של טילר הייתה יכולה להיות מושגת ללא טילר, אז אחת ההחלטות הראשונות שלנו לגבי Helm 3 הייתה לנטוש לחלוטין את טילר.

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

מאגרי תרשימים

ברמה גבוהה, מאגר תרשימים הוא מקום בו ניתן לאחסן ולשתף תרשימים. הלקוח של Helm אורז ושולח את התרשימים למאגר. במילים פשוטות, מאגר תרשימים הוא שרת HTTP פרימיטיבי עם קובץ index.yaml וכמה תרשימים ארוזים.

אמנם יש כמה יתרונות ל-API של מאגר תרשימים העונה על רוב דרישות האחסון הבסיסיות, אבל יש גם כמה חסרונות:

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

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

אבל האם ידעת שפרויקט ההפצה נועד להפיץ כל צורה של תוכן, לא רק תמונות מכילות?

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

תיאור מפורט יותר של כמה שינויים צפויים במאגרי תרשים Helm זמין по ссылке.

ניהול שחרורים

בהלמה 3, מצב היישום נמצא בתוך האשכול על ידי זוג אובייקטים:

• release object - מייצג מופע יישום;
• גרסת שחרור סודית - מייצגת את המצב הרצוי של האפליקציה בנקודת זמן מסוימת (לדוגמה, שחרור של גרסה חדשה).

Вызов helm install יוצר אובייקט שחרור וסוד גרסת שחרור. שִׂיחָה helm upgrade דורש אובייקט שחרור (שהוא יכול לשנות) ויוצר סוד גרסת שחרור חדש המכילה את הערכים החדשים ומניפסט מוכן.

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

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

בהלמה 2, התיקונים היו עקביים ביותר. שִׂיחָה helm install נוצר v1, העדכון הבא (שדרוג) - v2, וכן הלאה. סוד גרסת השחרור והשחרור כווצו לאובייקט יחיד המכונה גרסה. גרסאות נשמרו באותו מרחב שמות כמו טילר, מה שאומר שכל מהדורה הייתה "גלובלית" מבחינת מרחב השמות; כתוצאה מכך, ניתן היה להשתמש רק במופע אחד של השם.

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

לאחר נטישת טילר, Helm 3 מאחסן נתוני שחרור באותו מרחב שמות כמו הגרסה. שינוי זה מאפשר לך להתקין תרשים עם אותו שם מהדורה במרחב שמות אחר, והנתונים נשמרים בין עדכוני אשכול/אתחול מחדש ב-etcd. לדוגמה, אתה יכול להתקין וורדפרס במרחב השמות "foo" ולאחר מכן במרחב השמות של "בר", ושתי המהדורות יכולות לקבל את השם "wordpress".

שינויים בתלות בתרשים

תרשימים ארוזים (באמצעות helm package) לשימוש עם Helm 2 ניתן להתקין עם Helm 3, אולם זרימת העבודה של פיתוח התרשים עברה שיפוץ מוחלט, ולכן יש לבצע כמה שינויים כדי להמשיך בפיתוח התרשים עם Helm 3. במיוחד, מערכת ניהול התלות בתרשים השתנתה.

מערכת ניהול התלות של התרשים עברה requirements.yaml и requirements.lock על Chart.yaml и Chart.lock. זה אומר שהתרשימים שהשתמשו בפקודה helm dependency, דורש הגדרה מסוימת כדי לעבוד ב- Helm 3.

בואו נסתכל על דוגמה. בואו נוסיף תלות לתרשים ב-Helm 2 ונראה מה משתנה בעת המעבר ל-Helm 3.

בהמה 2 requirements.yaml נראה כך:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

בהלמה 3, אותה תלות תבוא לידי ביטוי אצלך Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

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

היכרות עם תרשימי ספרייה

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

תרשימי ספרייה מוצהרים בסעיף dependencies בקובץ Chart.yaml. התקנתם וניהולם אינם שונים מתרשימים אחרים.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

מה הלאה?

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

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

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

אם אתה מרגיש שפספסנו משהו, נשמח לשמוע את דעתך!

הצטרף לדיון שלנו ערוצים רפויים:

• #helm-users לשאלות ותקשורת פשוטה עם הקהילה;
• #helm-dev לדון בבקשות משיכה, קוד ובאגים.

אתה יכול גם לשוחח בצ'אט בשיחות הציבוריות השבועיות שלנו למפתחים בימי חמישי בשעה 19:30 MSK. הפגישות מוקדשות לדיון בנושאים שעליהם עובדים מפתחי מפתח והקהילה, כמו גם נושאי דיון לשבוע. כל אחד יכול להצטרף ולקחת חלק במפגש. קישור זמין בערוץ Slack #helm-dev.

נ.ב מהמתרגם

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

• «מנהל חבילות עבור Kubernetes - Helm: עבר, הווה, עתיד";
• «מבט מפוכח על הגה 2: "זה מה שזה..."";
• «היכרות מעשית למנהל החבילות של Kubernetes - Helm";
• «עצות וטריקים של Kubernetes: העברת משאבים הפועלים באשכול לניהול Helm 2";
• «תרגול עם dapp. חלק 2. פריסת תמונות Docker ל-Kubernetes באמצעות Helm".

מקור: www.habr.com