נפחים ארעיים עם מעקב אחר קיבולת אחסון: EmptyDir על סטרואידים

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

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

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

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

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

• כרכים ארעיים לשימוש כללי;

• מעקב אחר קיבולת אחסון CSI.

יתרונות הגישה החדשה:

• אחסון יכול להיות מקומי או מחובר דרך רשת;

• לנפחים יכול להיות גודל מוגדר שלא ניתן לחרוג ממנו על ידי היישום;

• עובד עם כל מנהלי התקנים של CSI שתומכים בהקצאה של אמצעי אחסון קבועים ו(כדי לתמוך במעקב קיבולת) מיישמים את השיחה GetCapacity;

• כרכים עשויים לכלול נתונים ראשוניים בהתאם למנהל ההתקן ולהגדרות;

• כל הפעולות הסטנדרטיות עם נפח (יצירת תמונת מצב, שינוי גודל וכו') נתמכות;

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

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

אפשרויות יישום

לכן, כרכים ארעיים לשימוש כללי מתאימים למקרי השימוש הבאים:

זיכרון מתמשך כתחליף ל-RAM עבור memcached

המהדורות האחרונות של memcached תמיכה נוספת שימוש בזיכרון מתמשך (Intel Optane וכו', משוער. מְתוּרגְמָן) במקום זיכרון RAM רגיל. בעת פריסת memcached דרך בקר יישומים, אתה יכול להשתמש באמצעי אחסון ארעיים לשימוש כללי כדי לבקש כי נפח בגודל נתון יוקצה מ-PMEM באמצעות מנהל ההתקן CSI, למשל PMEM-CSI.

אחסון מקומי של LVM כמרחב עבודה

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

גישה לקריאה בלבד עבור נפחי נתונים

הקצאת נפח יכולה לגרום ליצירת נפח מלא כאשר:

• התאוששות תמונת מצב של נפח;

• יצירה עותקי נפח;

• עבודה מצייני מיקום של נתונים.

ניתן להרכיב אמצעי אחסון אלה במצב קריאה בלבד.

אֵיך מַפעִילִים אֶת זֶה

כרכים ארעיים למטרות כלליות

תכונה מרכזית של כרכים ארעיים למטרות כלליות היא מקור הווליום החדש, EphemeralVolumeSource, המכיל את כל השדות ליצירת בקשת נפח (נקראת היסטורית בקשת נפח מתמשכת, PVC). בקר חדש נכנס kube-controller-manager מסתכל על התרמילים שיוצרים מקור נפח כזה, ואז יוצר PVC עבור התרמילים האלה. עבור מנהל ההתקן של ה-CSI, בקשה זו נראית כמו האחרות, כך שאין צורך בתמיכה מיוחדת כאן.

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

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

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

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

מעקב אחר קיבולת אחסון

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

חדש API CSIStorageCapacity, שנמצא בשלב אלפא, מאפשר לאחסן את הנתונים הדרושים ב-etcd כך שהם יהיו זמינים למתזמן. שלא כמו תמיכה בנפחים ארעיים למטרות כלליות, כאשר אתה פורס את מנהל ההתקן, עליך להפעיל מעקב אחר קיבולת האחסון: external-provisioner צריך לפרסם את מידע הקיבולת שהתקבל מהנהג דרך רגיל GetCapacity.

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

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

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

נ.ב. אתה יכול לקבל מידע מפורט יותר, כמו גם "לתרגל בבטחה על דוכן החתולים", ובמקרה של מצב לא מובן לחלוטין, לקבל סיוע טכני מוסמך בקורסים אינטנסיביים - בסיס Kubernetes יתקיים ב-28-30 בספטמבר, ולמומחים מתקדמים יותר Kubernetes Mega 14–16 באוקטובר.

אבטחה

CSIStorageCapacity

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

כרכים ארעיים למטרות כלליות

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

דוגמה

נפרד סניף PMEM-CSI מכיל את כל השינויים הדרושים להפעלת אשכול Kubernetes 1.19 בתוך מכונות וירטואליות QEMU עם כל התכונות בשלב האלפא. קוד מנהל ההתקן לא השתנה, רק הפריסה השתנתה.

במכונה מתאימה (לינוקס, משתמש רגיל יכול להשתמש סַוָר, תראה כאן פרטים) פקודות אלו יעלו את האשכול ויתקינו את מנהל ההתקן של PMEM-CSI:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

לאחר שהכל עובד, הפלט יכיל הוראות שימוש:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

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

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

לאובייקט בודד יש את התוכן הבא:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

בואו ננסה ליצור אפליקציית הדגמה עם נפח חד-פעמי של מטרה כללית. תוכן הקובץ pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

לאחר היצירה, כפי שמוצג בהוראות לעיל, יש לנו כעת תרמיל ו-PVC נוספים:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

בעל PVC - תחת:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  creationTimestamp: "2020-08-11T15:44:57Z"
  finalizers:
  - kubernetes.io/pvc-protection
  managedFields:
    ...
  name: my-csi-app-inline-volume-my-csi-volume
  namespace: default
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

מידע מעודכן צפוי עבור pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

אם אפליקציה אחרת צריכה יותר מ-26620Mi, המתזמן לא ייקח בחשבון pmem-csi-pmem-govm-worker1 בכל מקרה.

מה הלאה?

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

• KEP-1698: נפחים מוטבעים ארעיים גנריים

• KEP-1472: מעקב אחר קיבולת אחסון

מקור: www.habr.com