ללכת? לַחֲבוֹט! הכירו את מפעיל המעטפת (סקירה ודיווח וידאו מ-KubeCon EU'2020)

השנה, כנס Kubernetes האירופאי המרכזי - KubeCon + CloudNativeCon Europe 2020 - היה וירטואלי. עם זאת, שינוי כזה בפורמט לא מנע מאיתנו להעביר את הדו"ח המתוכנן הזה "לך? לַחֲבוֹט! הכירו את ה-Shell-operator" המוקדש לפרויקט הקוד הפתוח שלנו מפעיל מעטפת.

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

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

ב-Flant אנחנו כל הזמן עושים אופטימיזציה ואוטומציה של הכל. היום נדבר על עוד קונספט מרגש. לִפְגוֹשׁ: סקריפטים מקוריים של מעטפת בענן!

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

Kubernetes API ובקרים

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

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

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

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

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

בואו נסתכל מקרוב על תהליך יצירת פריסה ב-Kubernetes:

• בקר פריסה (כלול ב kube-controller-manager) מקבל מידע על פריסה ויוצר ReplicaSet.
• ReplicaSet יוצר שני העתקים (שני פודים) בהתבסס על מידע זה, אך התרמילים הללו אינם מתוכננים עדיין.
• המתזמן מתזמן תרמילים ומוסיף מידע על צומת ל-YAML שלהם.
• Kubelets מבצעים שינויים במשאב חיצוני (נגיד Docker).

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

מפעיל מעטפת

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

דוגמה פשוטה: העתקת סודות

בואו נסתכל על דוגמה פשוטה.

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

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

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

כיצד פועל מפעיל מעטפת

כמו עומסי עבודה אחרים ב-Kubernetes, ה-Shell-operator פועל בתרמיל משלו. בפוד הזה בספרייה /hooks קבצי הפעלה מאוחסנים. אלה יכולים להיות סקריפטים ב-Bash, Python, Ruby וכו'. אנו קוראים לקבצי הפעלה כאלה Hooks (ווים).

Shell-operator נרשם לאירועי Kubernetes ומפעיל את ה-hooks האלה בתגובה לאותם אירועים שאנחנו צריכים.

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

ביצוע מפעיל בבאש

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

• הראשון נחוץ לשלב התצורה - הוא מציג את ההקשר המחייב;
• השני מכיל את ההיגיון העיקרי של הקרס.

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

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

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

הירשם למקור הסודי

תצורה מחייבת עבור זה היא די פשוטה. אנו מציינים שאנו מעוניינים בסוד עם השם mysecret במרחב השמות default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

כתוצאה מכך, ה-hook יופעל כאשר סוד המקור משתנה (src_secret) וקבל את ההקשר המחייב הבא:

כפי שאתה יכול לראות, הוא מכיל את השם ואת כל האובייקט.

מעקב אחר מרחבי שמות

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

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

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

הוא מכיל מערך filterResults עבור כל מרחב שמות באשכול. משתנה בוליאני hasLabel מציין אם תווית מחוברת למרחב שמות נתון. בוחר keepFullObjectsInMemory: false מציין שאין צורך לשמור אובייקטים שלמים בזיכרון.

מעקב אחר סודות יעד

אנו מנויים לכל הסודות שצוין בהם הערה managed-secret: "yes" (אלה היעד שלנו dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

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

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

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

• אם hasLabel עניינים true עבור מרחב השמות הנוכחי:
  • משווה את הסוד העולמי לזה המקומי:
    • אם הם זהים, זה לא עושה כלום;
    • אם הם שונים - מבצע kubectl replace או create;
• אם hasLabel עניינים false עבור מרחב השמות הנוכחי:
  • מוודא ש-Secret לא נמצא במרחב השמות הנתון:
    • אם הסוד המקומי קיים, מחק אותו באמצעות kubectl delete;
    • אם הסוד המקומי לא מתגלה, זה לא עושה כלום.

יישום האלגוריתם ב-Bash אתה יכול להוריד אצלנו מאגרים עם דוגמאות.

כך הצלחנו ליצור בקר Kubernetes פשוט באמצעות 35 שורות של תצורת YAML ובערך אותה כמות של קוד Bash! תפקידו של מפעיל המעטפת הוא לקשר אותם יחד.

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

דוגמה 1: ביצוע שינויים ב-ConfigMap

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

כעת נניח שה-ConfigMap השתנה (v.2). עם זאת, הפודים ישתמשו בגרסה הקודמת של ConfigMap (v.1):

כיצד אוכל לגרום להם לעבור ל-ConfigMap החדש (v.2)? התשובה פשוטה: השתמש בתבנית. בואו נוסיף הערת סכום בדיקה לקטע template תצורות פריסה:

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

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

דוגמה 2: עבודה עם הגדרות משאבים מותאמות אישית

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

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

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

דוגמה 3: ניטור רשת אשכול

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

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

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

פרמטר executeHookOnEvent: [] מונע מה-hook לפעול בתגובה לכל אירוע (כלומר, בתגובה לשינוי, הוספה, מחיקה של צמתים). עם זאת, הוא ירוץ (ועדכן את רשימת הצמתים) על פי לוח הזמנים - כל דקה, לפי הוראות השדה schedule.

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

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

אנו עוברים על רשימת הצמתים, מקבלים את שמותיהם וכתובות ה-IP שלהם, פינג אותם ושולחים את התוצאות ל-Prometheus. ה-Shell-operator יכול לייצא מדדים ל-Prometheus, שמירתם בקובץ הממוקם לפי הנתיב שצוין במשתנה הסביבה $METRICS_PATH.

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

מנגנון תור

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

• מה קורה אם, באותו הזמן, משהו קורה באשכול? עוד דבר אחד מִקרֶה?
• האם מפעיל המעטפת יפעיל מופע נוסף של הוו?
• מה אם, נניח, חמישה אירועים מתרחשים באשכול בבת אחת?
• האם מפעיל המעטפת יעבד אותם במקביל?
• מה לגבי משאבים נצרכים כמו זיכרון ומעבד?

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

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

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

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

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

מסקנה

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

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

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

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

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

הצגת הדו"ח:

נ.ב.

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

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

מקור: www.habr.com