הרחבת והשלמה של Kubernetes (סקירה כללית ודוח וידאו)

8 באפריל בכנס Saint HighLoad++ 2019, במסגרת מדור "DevOps and Operations", ניתן דוח "הרחבת והשלמה של Kubernetes", שביצירתו השתתפו שלושה עובדי חברת פלנט. בו אנו מדברים על מצבים רבים בהם רצינו להרחיב ולהשלים את היכולות של Kubernetes, אך עבורם לא מצאנו פתרון מוכן ופשוט. יש לנו את הפתרונות הדרושים בצורה של פרויקטים בקוד פתוח, וגם הנאום הזה מוקדש להם.

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

ליבה ותוספות ב-K8s

Kubernetes משנה את התעשייה והגישות למינהל שהוקמו זה מכבר:

• תודה לו הפשטות, אנחנו כבר לא פועלים עם מושגים כמו הגדרת תצורה או הפעלת פקודה (Chef, Ansible...), אלא משתמשים בקיבוץ קונטיינרים, שירותים וכו'.
• אנחנו יכולים להכין יישומים מבלי לחשוב על הניואנסים של אתר ספציפי, עליו יושק: מתכת חשופה, ענן של אחת הספקיות וכו'.
• עם K8s מעולם לא היית נגיש יותר השיטות הטובות ביותר על ארגון תשתית: טכניקות קנה מידה, ריפוי עצמי, סובלנות לתקלות וכו'.

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

קוברנט לא הוא קומבינה שפותר את כל הבעיות של כל המשתמשים. הגרעין Kubernetes אחראית רק לקבוצה של הפונקציות המינימליות ההכרחיות הקיימות ב כל אחד אֶשׁכּוֹל:

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

מצד שני, K8s מציע הזדמנויות נהדרות להרחיב את הפונקציות הזמינות, שעוזרות לסגור אחרים - ספֵּצִיפִי - צרכי המשתמש. תוספות ל-Kubernetes הן באחריותם של מנהלי אשכולות, שחייבים להתקין ולהגדיר את כל הדרוש כדי שהאשכול שלהם יהיה "בצורה הנכונה" [כדי לפתור את הבעיות הספציפיות שלהם]. באיזה תוספות מדובר? בואו נסתכל על כמה דוגמאות.

דוגמאות לתוספות

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

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

דוגמאות אחרות כוללות:

• Ingress-בקרים (ראה את הביקורת שלהם ב המאמר האחרון שלנו).
• מנהל cert:

  

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

  

• מדדים - המחשה נוספת לאופן שבו Kubernetes הפרידה את הממשק (Metrics API) מהיישום (תוספות של צד שלישי כגון מתאם Prometheus, Datadog cluster agent...).
• עבור ניטור וסטטיסטיקה, שבו בפועל לא רק נחוצים פרומתאוס וגראפנה, אלא גם קוב-מצב-מדדי, צומת-יצואן וכו'.

וזו לא רשימה מלאה של תוספות... למשל בחברת פלנט אנחנו מתקינים כיום 29 תוספות (כולם יוצרים בסך הכל 249 אובייקטים של Kubernetes). במילים פשוטות, איננו יכולים לראות את חייו של אשכול ללא תוספות.

אוטומציה

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

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

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

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

איך כותבים הצהרה עבור Kubernetes?

באופן כללי, התוכנית פשוטה:

... אבל אז מסתבר ש:

• ה-API של Kubernetes הוא דבר לא טריוויאלי שלוקח הרבה זמן לשלוט בו;
• גם התכנות לא מתאים לכולם (שפת הגו נבחרה כשפה המועדפת כי יש לה מסגרת מיוחדת - SDK של מפעיל);
• המצב דומה למסגרת עצמה.

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

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

מפעיל מעטפת

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

איך מפעיל הפגז יודע לאילו ווים להתקשר באילו אירועים? המידע הזה מועבר למפעיל המעטפת על ידי הווים עצמם, והם עושים זאת בפשטות רבה.

Hook הוא סקריפט Bash או כל קובץ הפעלה אחר שמקבל ארגומנט בודד --config ומשיב עם JSON. האחרון קובע אילו חפצים מעניינים אותו ולאילו אירועים (עבור חפצים אלה) יש להגיב:

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

תרגול: 1. כתוב וו

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

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

איך ייראה ההיגיון? גם די פשוט:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

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

תרגול: 2. הרכבת התמונה

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

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

כל מה שנותר הוא להרכיב אותו ולדחוף אותו:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

המגע האחרון הוא לפרוס את התמונה לאשכול. כדי לעשות זאת, בואו נכתוב פְּרִיסָה:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

יש לשים לב לשתי נקודות:

1. אינדיקציה של התמונה החדשה שנוצרה;
2. זהו רכיב מערכת ש(לכל הפחות) זקוק להרשאות להירשם לאירועים ב-Kubernetes ולהקצאת סודות למרחבי שמות, ולכן אנו יוצרים ServiceAccount (ומערכת כללים) עבור ה-hook.

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

תכונות אחרות של מפעיל מעטפת

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

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

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

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

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

ועוד שתי תכונות של מפעיל המעטפת:

1. זה עובד באופן אסינכרוני. מכיוון שהתקבל אירוע Kubernetes (כגון אובייקט שנוצר), אירועים אחרים (כגון אותו אובייקט שנמחק) יכלו להתרחש באשכול, וה-hooks צריך לתת את הדעת על כך. אם ה-hook בוצע עם שגיאה, אז כברירת מחדל זה יהיה לִזכּוֹר עד להשלמה מוצלחת (ניתן לשנות התנהגות זו).
2. זה מייצא מדדים עבור Prometheus, שאיתו אתה יכול להבין אם ה-Shell-operator עובד, גלה את מספר השגיאות עבור כל וו ואת גודל התור הנוכחי.

לסיכום חלק זה של הדו"ח:

התקנת תוספות

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

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

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

כדי לעשות סדר, התחלנו עם תסריט (install-ingress.sh), שלקח כטיעון את סוג האשכול שאליו נפרוס, יצר את תצורת ה-YAML הנחוצה וגלגל אותה אל Kubernetes.

בקיצור, הדרך הנוספת שלנו וההיגיון הקשור בה היו כדלקמן:

• כדי לעבוד עם תצורות YAML, נדרש מנוע תבנית (בשלבים הראשונים זה פשוט סד);
• עם הגידול במספר האשכולות, הגיע הצורך בעדכון אוטומטי (הפתרון המוקדם ביותר היה לשים את הסקריפט ב-Git, לעדכן אותו באמצעות cron ולהפעיל אותו);
• נדרש תסריט דומה עבור פרומתאוס (install-prometheus.sh), עם זאת, זה בולט בעובדה שהוא דורש הרבה יותר נתוני קלט, כמו גם האחסון שלהם (בצורה טובה - מרוכזת ובאשכול), וחלק מהנתונים (סיסמאות) יכולים להיווצר באופן אוטומטי:

  

• הסיכון להפיץ משהו לא בסדר למספר גדל והולך של אשכולות גדל כל הזמן, אז הבנו שמתקינים (כלומר שני סקריפטים: עבור Ingress ו-Prometheus) היה צורך בסטייג'ינג (מספר סניפים ב-Git, מספר קרונים כדי לעדכן אותם בהתאמה: יציבות או אשכולות בדיקה);
• с kubectl apply זה הפך להיות קשה לעבוד איתו כי זה לא הצהרתי והוא יכול ליצור רק אובייקטים, אבל לא לקבל החלטות על מעמדם/למחוק אותם;
• היו חסרות לנו כמה פונקציות שלא יישמנו כלל באותו זמן:
  • שליטה מלאה על התוצאה של עדכוני אשכולות,
  • קביעה אוטומטית של כמה פרמטרים (קלט עבור סקריפטים להתקנה) על סמך נתונים שניתן לקבל מהאשכול (גילוי),
  • התפתחותו הלוגית בצורה של גילוי מתמשך.

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

מפעיל תוסף

זה מבוסס על מפעיל המעטפת שכבר הוזכר. כל המערכת נראית כך:

הדברים הבאים מתווספים לווי מפעילי המעטפת:

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

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

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

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

סכימה זו עונה על כל הדרישות להתקנת תוספות שצוינו לעיל:

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

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

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

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

היכן אני יכול להשיג את המודולים עבור addon-operator? פרסום הספרייה שלנו הוא השלב הבא עבורנו; אנחנו מתכננים לעשות זאת בקיץ.

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

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

הצגת הדו"ח:

נ.ב.

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

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

ייתכן שתתעניין גם בפרסומים הבאים:

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

מקור: www.habr.com