האם קל ונוח להכין אשכול Kubernetes? מכריז על מפעיל תוסף

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

למה בכלל תוספות?

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

הצורך ברכיבים נוספים באשכול מתגלה ב להגיש תלונה עמיתים דריושה. בקיצור, המצב עם Kubernetes כרגע הוא כזה שעבור התקנה פשוטה של ​​"משחק סביב" אפשר להסתדר עם הרכיבים מחוץ לקופסה, למפתחים ולבדיקות אפשר להוסיף את Ingress, אבל להתקנה מלאה, בערך אתה יכול לומר "ההפקה שלך מוכנה", אתה צריך להוסיף עם תריסר תוספות שונות: משהו לניטור, משהו לרישום, אל תשכח כניסה ומנהל אישורים, בחר קבוצות של צמתים, הוסף מדיניות רשת, עונה עם הגדרות sysctl ו-pod autoscaler...

מה המאפיינים של העבודה איתם?

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

אז אולי Ansible יספיק כאן? אולי. אבל באופן כללי, תוספות מן המניין אינן חיות ללא הגדרות. הגדרות אלו עשויות להיות שונות בהתאם לגרסת האשכול (aws, gce, azure, bare-metal, do, ...). לא ניתן לציין הגדרות מסוימות מראש; יש לקבל אותן מהאשכול. והאשכול אינו סטטי: עבור הגדרות מסוימות תצטרך לפקח על שינויים. וכאן כבר חסרה Ansible: צריך תוכנית שחיה באשכול, כלומר. מפעיל Kubernetes.

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

איך זה מאורגן ב-addon-operator?

בעת יצירת פתרון חדש, יצאנו מהעקרונות הבאים:

• מתקין ההרחבה חייב לתמוך תבנית ותצורה הצהרתית. אנחנו לא יוצרים סקריפטים קסומים שמתקינים תוספות. Addon-operator משתמש בהלם כדי להתקין תוספות. כדי להתקין, עליך ליצור תרשים ולבחור את הערכים שישמשו להגדרה.
• הגדרות יכולות להיות ליצור בהתקנה, הם יכולים לקבל מאשכולאו לקבל עדכונים, ניטור משאבי אשכול. ניתן ליישם פעולות אלו באמצעות ווים.
• הגדרות יכולות להיות לאחסן באשכול. כדי לאחסן הגדרות באשכול, נוצר ConfigMap/addon-operator וה-Addon-operator עוקב אחר שינויים ב-ConfigMap זה. Addon-operator נותן ל-hooks גישה להגדרות באמצעות מוסכמות פשוטות.
• הוספה תלויה בהגדרות. אם ההגדרות השתנו, אזי ה-Addon-operator מוציא את תרשים ההגה עם ערכים חדשים. קראנו לשילוב של טבלת ההגה, הערכים שלו והווים מודול (ראה למטה לפרטים נוספים).
• הַצָגָה. אין תסריטים לשחרור קסם. מנגנון העדכון דומה לאפליקציה רגילה – אספו תוספות ומפעילי תוספים לתמונה, תייגו אותם ותגלגלו אותם.
• בקרת תוצאות. Addon-operator יכול לספק מדדים עבור Prometheus.

מה זה ריפוד ב-addon-operator?

תוספת יכולה להיחשב לכל דבר שמוסיף פונקציות חדשות לאשכול. לדוגמה, התקנת Ingress היא דוגמה מצוינת לתוסף. זה יכול להיות כל מפעיל או בקר עם CRD משלו: prometheus-operator, cert-manager, kube-controller-manager וכו'. או משהו קטן, אבל קל יותר לשימוש - למשל, מכונת צילום סודית, שמעתיקה את סודות הרישום למרחבי שמות חדשים, או מקלט sysctl, שמגדיר פרמטרים של sysctl בצמתים חדשים.

כדי ליישם תוספות, Addon-operator מספק מספר מושגים:

• תרשים הגה משמש להתקנת תוכנות שונות לתוך האשכול - למשל, Prometheus, Grafana, nginx-ingress. אם לרכיב הנדרש יש תרשים Helm, אז התקנתו באמצעות Addon-operator תהיה פשוטה מאוד.
• אחסון ערכים. לתרשימי הגה יש בדרך כלל הגדרות רבות ושונות שיכולות להשתנות עם הזמן. Addon-operator תומך באחסון הגדרות אלה ויכול לעקוב אחר השינויים שלהן כדי להתקין מחדש את טבלת ההגה עם ערכים חדשים.
• ווים הם קבצי הפעלה שה-Addon-operator מריץ באירועים ושנכנסים למאגר הערכים. הוו יכול לעקוב אחר שינויים באשכול ולעדכן את הערכים במאגר הערכים. הָהֵן. באמצעות הוקס, אתה יכול לבצע גילוי כדי לאסוף ערכים מהאשכול בעת ההפעלה או לפי לוח זמנים, או שאתה יכול לעשות גילוי רציף, לאסוף ערכים מהאשכול על סמך שינויים באשכול.
• Модуль הוא שילוב של טבלת Helm, חנות ערכים וווים. ניתן להפעיל או להשבית מודולים. השבתת מודול פירושה מחיקת כל גרסאות התרשים של Helm. מודולים יכולים להפעיל את עצמם באופן דינמי, למשל, אם כל המודולים הדרושים להם מופעלים או אם Discovery מצא את הפרמטרים הדרושים ב-hooks - זה נעשה באמצעות סקריפט מאופשר עזר.
• ווים גלובליים. אלו הם ווים "בעצמם", הם אינם כלולים במודולים ויש להם גישה לחנות ערכים גלובלית, שהערכים שלה זמינים לכל הווים במודולים.

איך החלקים האלה עובדים ביחד? בואו נסתכל על התמונה מהתיעוד:

ישנם שני תרחישי עבודה:

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

ניתן ליישם את התוספת כהוק אחד בודד, או כתרשים Helm אחד, או אפילו כמספר מודולים תלויים - הדבר תלוי במורכבות הרכיב המותקן באשכול וברמת גמישות התצורה הרצויה. לדוגמה, במאגר (/examples) יש תוסף sysctl-tuner, אשר מיושם הן כמודול פשוט עם הוק ותרשים Helm, והן באמצעות מאגר הערכים, המאפשר להוסיף הגדרות על ידי עריכת ConfigMap.

מסירת עדכונים

כמה מילים על ארגון עדכוני רכיבים ש-Addon-operator מתקין.

כדי להפעיל Addon-operator באשכול, אתה צריך לבנות תמונה עם תוספות בצורה של קבצי תרשים Hook ו-Helm, הוסף קובץ בינארי addon-operator וכל מה שאתה צריך עבור ווים: bash, kubectl, jq, python וכו ' לאחר מכן ניתן לגלגל את התמונה הזו לאשכול כאפליקציה רגילה, וסביר להניח שתרצו לארגן סכימת תיוג כזו או אחרת. אם יש מעט אשכולות, אותה גישה כמו עם יישומים עשויה להתאים: מהדורה חדשה, גרסה חדשה, עבור לכל האשכולות ותקן את התמונה של Pods. עם זאת, במקרה של השקה למספר לא מבוטל של אשכולות, הקונספט של עדכון עצמי מערוץ התאים לנו יותר.

הנה איך אנחנו עושים את זה:

• ערוץ הוא בעצם מזהה שניתן להגדיר לכל דבר (לדוגמה, dev/stage/ea/stable).
• שם הערוץ הוא תג התמונה. כאשר אתה צריך להפיץ עדכונים לערוץ, תמונה חדשה מורכבת ומתויגת עם שם הערוץ.
• כאשר תמונה חדשה מופיעה ברישום, Addon-operator מופעל מחדש ומופעל עם התמונה החדשה.

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

ערוצים עוזרים ו בבדיקה: אם יש אשכול עזר, אתה יכול להגדיר אותו לערוץ stage ולגלגל לתוכו עדכונים לפני פרסום זה לערוצים ea и stable. אם עם אשכול בערוץ ea אירעה שגיאה, אתה יכול להעביר אותה ל stable, בזמן שהבעיה עם אשכול זה נחקרת. אם מוציאים את האשכול מתמיכה פעילה, הוא עובר לערוץ ה"קפוא" שלו - למשל, freeze-2019-03-20.

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

באופן כללי, ניתן לעשות זאת ללא Addon-operator, אך עם Addon-operator המודול להתקנת node-exporter יהיה גלוי במאגר אחד, ה- Dockerfile לבניית התמונה שלך יכול להישמר ממש שם, זה הופך להיות קל יותר עבור כל המשתתפים ב- התהליך כדי להבין מה קורה... ואם יש כמה אשכולות, אז זה הופך להיות קל יותר גם לבחון את יחסי הציבור שלך וגם להוציא גרסה חדשה!

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

מסקנה

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

ניתן להפוך תוספות ל-Addon-operator בפורמט מודול (תרשים הגה + ווים) לזמינים לציבור. אנחנו, חברת פלנט, מתכננים לפרסם את הפיתוחים שלנו בצורת תוספות כאלה במהלך הקיץ. הצטרף לפיתוח ב-GitHub (מפעיל מעטפת, מפעיל addon), נסה ליצור תוספת משלך על סמך דוגמאות и תיעוד, חכה לחדשות על Habré ועל שלנו ערוץ יוטיוב!

נ.ב.

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

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

מקור: www.habr.com