🥇 מפעילים עבור Kubernetes: כיצד להפעיל יישומים סטטיסטיים

הבעיה עם יישומים מצביים ב-Kubernetes

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

במילים פשוטות, כדי להשיק עוד חמישה עותקים של ה-backend ב-PHP/Ruby/Python באשכול של קונטיינרים, צריך רק להגדיר שרת חדש 5 פעמים ולהעתיק את המקורות. מכיוון שגם קוד המקור וגם סקריפט ה-init נמצאים בתמונה, קנה מידה של יישום חסר מצב הופך לאלמנטרי לחלוטין. כפי שחובבי קונטיינרים וארכיטקטורת מיקרו-שירותים יודעים היטב, הקושי מתחיל אפליקציות ממלכתיות, כלומר עם התמדה של נתונים כגון מסדי נתונים ומטמונים (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). זה תקף הן לתוכנה המיישמת באופן עצמאי אשכול קוורום (לדוגמה, Percona XtraDB ו- Cassandra), והן לתוכנה הדורשת כלי עזר נפרדים לניהול (כגון Redis, MySQL, PostgreSQL...).

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

מפעילי CoreOS

על מנת "לתכנת" ידע תפעולי, בסוף השנה שעברה פרויקט CoreOS הגישו "מחלקה חדשה של תוכנה" לפלטפורמת Kubernetes - מפעילים (מהאנגלית "פעולה", כלומר "פעולה").

מפעילים המשתמשים ומרחיבים את יכולות הליבה של Kubernetes (כולל. StatefulSets, ראה את ההבדל למטה) מאפשרים למומחי DevOps להוסיף ידע תפעולי לקוד היישום.

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

איך המפעילים עובדים

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

במה זה שונה מ StatefulSets, המיועד ליישומים שדורשים שהאשכול יספק להם משאבים סטטיים כגון אחסון נתונים או כתובות IP סטטיות? עבור יישומים כאלה, המפעילים יכולים להשתמש StatefulSets (במקום ReplicaSets) כבסיס, מציע אוטומציה נוספת: לבצע את הפעולות הדרושות במקרה של קריסות, לבצע גיבויים, לעדכן את התצורה וכו'.

לפיכך, איך כל זה עובד האופרטור הוא דמון מנהל ש:

נרשם לממשק API לאירועים ב-Kubernetes;
מקבל ממנו נתונים על המערכת (עליה ReplicaSets, תרמילים, שירותים וכולי.);
מקבל נתונים על משאבי צד שלישי (ראה דוגמאות למטה);
מגיב למראה/שינוי משאבי צד שלישי (לדוגמה, כדי לשנות את הגודל, לשנות את הגרסה, וכן הלאה);
מגיב לשינויים במצב המערכת (בערך שלה ReplicaSets, תרמילים, שירותים וכולי.);
החשוב ביותר:
1. קורא לממשק ה-API של Kubernetes ליצור את כל מה שהוא צריך (שוב, משלו ReplicaSets, תרמילים, שירותים...),
2. מבצע קצת קסם (כדי לפשט, אפשר לחשוב שה-Operator נכנס לתרמילים עצמם וקורא פקודות, למשל, כדי להצטרף לאשכול או לשדרג את פורמט הנתונים בעת עדכון גרסה).

למעשה, כפי שניתן לראות מהתמונה, פשוט מתווספת אפליקציה נפרדת ל-Kubernetes (רגיל פְּרִיסָה с ReplicaSet), אשר נקרא המפעיל. הוא חי בתרמיל רגיל (בדרך כלל רק אחד) וככלל, הוא אחראי רק על מרחב שמות. אפליקציית מפעיל זה מיישמת את ה-API שלה - אם כי לא ישירות, אלא דרך משאבי צד שלישי ב-Kubernetes.

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

דוגמה עבור וכו' (ראה למטה לפרטים):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

דוגמה עבור Elasticsearch:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

דרישות למפעילים

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

ההתקנה חייבת להיעשות באמצעות יחיד פְּרִיסָה: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - ואינם דורשים פעולות נוספות.
בעת התקנת מפעיל ב-Kubernetes, יש ליצור סוג צד שלישי חדש (ThirdPartyResource). כדי להפעיל מופעי יישומים (מופעי אשכול) ולנהל אותם בהמשך (עדכון גרסאות, שינוי גודל וכו'), המשתמש ישתמש בסוג זה.
במידת האפשר, עליך להשתמש בפרימיטיבים המובנים ב-Kubernetes, כגון שירותים и ReplicaSetsלהשתמש בקוד בדוק ומובן.
דורש תאימות לאחור של מפעילים ותמיכה בגרסאות ישנות יותר של משאבים שנוצרו על ידי משתמשים.
אם המפעיל יוסר, היישום עצמו אמור להמשיך לפעול ללא שינויים.
המשתמשים צריכים להיות מסוגלים להגדיר את גרסת האפליקציה הרצויה ולארגן עדכוני גרסת אפליקציה. חוסר עדכוני תוכנה הוא מקור נפוץ לבעיות תפעול ואבטחה, ולכן המפעילים חייבים לסייע למשתמשים בעניין זה.
יש לבדוק את המפעילים עם כלי כמו Chaos Monkey, המזהה כשלים פוטנציאליים בתרמילים, בתצורות וברשת.

etcd מפעיל

דוגמה ליישום מפעיל - מפעיל וכו', מוּכָן ביום ההכרזה על קונספט זה. תצורת אשכול ה-etcd יכולה להיות מורכבת עקב הצורך לשמור על הקוורום, הצורך להגדיר מחדש את החברות באשכול, ליצור גיבויים וכו'. לדוגמה, קנה מידה ידני של אשכול etcd פירושו שעליך ליצור שם DNS עבור חבר אשכול חדש, להתחיל ישות etcd חדשה ולהתריע לאשכול על החבר החדש (הוסף חבר etcdctl). במקרה של ה-Operator, המשתמש יצטרך רק לשנות את גודל האשכול - כל השאר יקרה אוטומטית.

ומכיוון ש-etcd נוצר גם ב-CoreOS, זה היה די הגיוני לראות את ה-Operator שלה מופיע ראשון. איך הוא עובד? לוגיקה אופרטור וכו' נקבע על ידי שלושה מרכיבים:

לצפות. המפעיל עוקב אחר מצב האשכול באמצעות ה-API של Kubernetes.
אָנָלִיזָה. מוצא הבדלים בין המצב הנוכחי לבין המצב הרצוי (מוגדר על ידי תצורת המשתמש).
פעולה. פותר הבדלים שזוהו באמצעות ממשקי API של שירות etcd ו/או Kubernetes.

כדי ליישם את ההיגיון הזה, הוכנו פונקציות ב-Operator צור/הרוס (יצירה ומחיקה של חברי אשכול etcd) ו שינוי הגודל (שינוי במספר חברי האשכול). נכונות פעולתו נבדקה באמצעות כלי עזר שנוצר בדמותו של Chaos Monkey מ-Netflix, כלומר. הרג תרמילים וכו' באופן אקראי.

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

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

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

הסטטוס הנוכחי של etcd Operator הוא גרסת בטא, המחייבת את Kubernetes 1.5.3+ ו-etcd 3.0+ כדי לפעול. קוד מקור ותיעוד (כולל הוראות שימוש) זמינים בכתובת GitHub.

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

סטטוס וסיכויים

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

המפתחים חוזים "עתיד שבו משתמשים מתקינים את Postgres Operators, Cassandra Operators או Redis Operators באשכולות ה-Kubernetes שלהם ועובדים עם הישויות הניתנות להרחבה של יישומים אלה באותה קלות כמו פריסת העתקים של יישומי אינטרנט חסרי מדינה". ראשון מפעילים ממפתחי צד שלישי באמת התחיל להופיע:

מפעיל Elasticsearch מ-UPMC Enterprises;
מפעיל PostgreSQL מ-Crunchy Data (הוכרז בסוף מרץ 2017);
מפעיל צריח מחברי מערכת אחסון נתונים מבוזרת המבוססת על Ceph (Rook נמצא בסטטוס אלפא);
מפעילי Openstack מ-SAP CCloud.

בוועידת התוכנה החינמית הגדולה באירופה FOSDEM, שהתקיימה בפברואר 2017 בבריסל, הכריז ג'וש ווד מ- CoreOS על מפעילים ב להגיש תלונה (סרטון זמין בקישור!), מה שאמור לתרום לצמיחת הפופולריות של מושג זה בקהילת הקוד הפתוח הרחבה יותר.

נ.ב. תודה על התעניינותך במאמר! הירשם למרכז שלנו, כדי לא לפספס חומרים ומתכונים חדשים ב-DevOps ובניהול מערכת GNU/Linux - נפרסם אותם באופן קבוע!

מקור: www.habr.com

אופרטורים עבור Kubernetes: כיצד להפעיל יישומים סטטיסטיים