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

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

למה?

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

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

מפעיל תוך 15 דקות

בואו נסתכל על דוגמה של מה שניתן לבצע אוטומטית באשכול Kubernetes וכיצד מפעיל המעטפת יכול לעזור. דוגמה תהיה הבאה: שכפול סוד כדי לגשת ל-docker registry.

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

אוטומציה פשוטה

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

אוטומציה עם מפעיל מעטפת

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

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

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

כאן מתואר שאנו מעוניינים להוסיף אירועים (add) אובייקטים מסוג namespace.

כעת עליך להוסיף את הקוד שיבוצע כאשר האירוע מתרחש:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

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

הכנת תמונה עם וו

אם אתה מסתכל על הסקריפט, אתה יכול לראות שהפקודות משמשות kubectl и jq. זה אומר שהתמונה חייבת לכלול את הדברים הבאים: ה-hook שלנו, shell-operator שינטר אירועים ויריץ את ה-hook, והפקודות המשמשות את ה-hook (kubectl ו-jq). ל- Hub.docer.com כבר יש תמונה מוכנה שבה ארוזים shell-operator, kubectl ו-jq. כל מה שנותר הוא להוסיף וו פשוט Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

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

ריצה במקבץ

בואו נסתכל שוב על הוו והפעם נכתוב אילו פעולות ועם אילו אובייקטים הוא מבצע באשכול:

1. נרשם לאירועי יצירת מרחב שמות;
2. יוצר סוד במרחבי שמות שאינם זה שבו הוא מופעל.

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

התיאור הסופי ב-YAML ייראה בערך כך:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

מטעמי נוחות, נוצר מרחב שמות נפרד שבו יופעל ה-Shell-operator ויושמו המניפסטים שנוצרו:

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

זה הכל: ה-Shell-operator יתחיל, ירשם לאירועי יצירת מרחב שמות ויריץ את ה-hook בעת הצורך.

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

יש עוד המחשה בעניין הזה...

את משמעותו נחשוף ביתר פירוט באחד מהפרסומים הבאים.

סינון

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

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

לדוגמה, כדי להגיב לשינויים בתוויות עבור אובייקטי Deployment, עליך לסנן את השדה labels מחוץ לשטח metadata. התצורה תהיה כך:

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

ביטוי jqFilter זה הופך את המניפסט הארוך של ה-JSON של Deployment ל-JSON קצר עם תוויות:

shell-operator יפעיל את ה-hook רק כאשר ה-JSON הקצר הזה משתנה, ושינויים במאפיינים אחרים יתעלמו.

הקשר השקת הוק

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

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

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

כדי להבחין מדוע הופעל ה-hook, ה-Shell-operator יוצר קובץ זמני ומעביר את הנתיב אליו במשתנה ל-hook BINDING_CONTEXT_TYPE. הקובץ מכיל תיאור JSON של הסיבה להפעלת ה-hook. לדוגמה, כל 10 דקות הקרס יפעל עם התוכן הבא:

[{ "binding": "every 10 min"}]

... וביום שני זה יתחיל בזה:

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

עבור onKubernetesEvent יהיו יותר טריגרים של JSON, כי הוא מכיל תיאור של האובייקט:

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

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

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

אתה יכול לקבל שדות אחרים בצורה דומה.

מה הלאה?

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

קיימת תמיכה באיסוף מדדים באמצעות פרומתאוס - המדדים הזמינים מתוארים בסעיף מדדים.

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

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

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

המשך לעקוב!

נ.ב.

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

• «אופרטורים עבור Kubernetes: כיצד להפעיל יישומים סטטיסטיים";
• «כתיבת מפעיל עבור Kubernetes בגולנג";
• «מציגים תוסף חדש לגראפאנה - פאנל Statusmap";
• «מציגים את loghouse - מערכת קוד פתוח לעבודה עם לוגים ב-Kubernetes";
• «אנו מציגים רשמית את dapp - כלי עזר DevOps לתחזוקת CI/CD".

מקור: www.habr.com