תוספי נפח לאחסון Kubernetes: מ-Flexvolume ועד CSI

עוד כש-Kubernetes היה גרסה 1.0.0, היו תוספים לנפח. הם היו נחוצים כדי לחבר מערכות ל-Kubernetes לאחסון נתוני מיכל קבועים (קבועים). מספרם היה קטן, ובין הראשונים היו ספקי אחסון כמו GCE PD, Ceph, AWS EBS ואחרים.

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

תוסף Flexvolume: חכה מינימלית

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

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

דיאגרמת חיבור עבור מניות CIFS ב-OpenShift. מנהל התקן Flexvolume - ממש במרכז

סט מינימלי של שיטות נראה כך:

flexvolume_driver mount # отвечает за присоединение тома к pod'у
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver unmount # отвечает за отсоединение тома от pod'а
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver init # отвечает за инициализацию плагина
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
  // Определяет, использует ли драйвер методы attach/deatach
  "capabilities":{"attach": True/False}
}

שימוש בשיטות attach и detach יגדיר את התרחיש שבו הקובלט יפעל בעתיד בעת קריאת הנהג. יש גם שיטות מיוחדות expandvolume и expandfs, אשר אחראים על שינוי דינמי של גודל עוצמת הקול.

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

והנה דוגמה ליישום של מנהל ההתקן Flexvolume לעבודה עם NFS:

usage() {
    err "Invalid usage. Usage: "
    err "t$0 init"
    err "t$0 mount <mount dir> <json params>"
    err "t$0 unmount <mount dir>"
    exit 1
}

err() {
    echo -ne $* 1>&2
}

log() {
    echo -ne $* >&1
}

ismounted() {
    MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1`
    if [ "${MOUNT}" == "${MNTPATH}" ]; then
        echo "1"
    else
        echo "0"
    fi
}

domount() {
    MNTPATH=$1

    NFS_SERVER=$(echo $2 | jq -r '.server')
    SHARE=$(echo $2 | jq -r '.share')

    if [ $(ismounted) -eq 1 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    mkdir -p ${MNTPATH} &> /dev/null

    mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failure", "message": "Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}"}"
        exit 1
    fi
    log '{"status": "Success"}'
    exit 0
}

unmount() {
    MNTPATH=$1
    if [ $(ismounted) -eq 0 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    umount ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failed", "message": "Failed to unmount volume at ${MNTPATH}"}"
        exit 1
    fi

    log '{"status": "Success"}'
    exit 0
}

op=$1

if [ "$op" = "init" ]; then
    log '{"status": "Success", "capabilities": {"attach": false}}'
    exit 0
fi

if [ $# -lt 2 ]; then
    usage
fi

shift

case "$op" in
    mount)
        domount $*
        ;;
    unmount)
        unmount $*
        ;;
    *)
        log '{"status": "Not supported"}'
        exit 0
esac

exit 1

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

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/

... אך כאשר משתמשים בהפצות שונות של Kubernetes (OpenShift, Rancher...) הנתיב עשוי להיות שונה.

בעיות Flexvolume: איך להטיל חכה נכון?

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

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

הנה דוגמה ל-DaemonSet כזה לפריסת תוסף Flexvolume:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: flex-set
spec:
  template:
    metadata:
      name: flex-deploy
      labels:
        app: flex-deploy
    spec:
      containers:
        - image: <deployment_image>
          name: flex-deploy
          securityContext:
              privileged: true
          volumeMounts:
            - mountPath: /flexmnt
              name: flexvolume-mount
      volumes:
        - name: flexvolume-mount
          hostPath:
            path: <host_driver_directory>

... ודוגמה של סקריפט Bash לפריסת מנהל ההתקן של Flexvolume:

#!/bin/sh

set -o errexit
set -o pipefail

VENDOR=k8s.io
DRIVER=nfs

driver_dir=$VENDOR${VENDOR:+"~"}${DRIVER}
if [ ! -d "/flexmnt/$driver_dir" ]; then
  mkdir "/flexmnt/$driver_dir"
fi

cp "/$DRIVER" "/flexmnt/$driver_dir/.$DRIVER"
mv -f "/flexmnt/$driver_dir/.$DRIVER" "/flexmnt/$driver_dir/$DRIVER"

while : ; do
  sleep 3600
done

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

תרשים של עבודה עם Ceph באופרטור Rook: מנהל ההתקן של Flexvolume בתרשים ממוקם בתוך הסוכן Rook

הבעיה הבאה בעת שימוש במנהלי התקנים של Flexvolume היא של רוב האחסון בצומת אשכול יש להתקין את התוכנה הדרושה לכך (לדוגמה, חבילת ceph-common עבור Ceph). בתחילה, התוסף Flexvolume לא תוכנן ליישם מערכות מורכבות כאלה.

פתרון מקורי לבעיה זו ניתן לראות ביישום דרייבר Flexvolume של מפעיל ה-Rook:

הדרייבר עצמו מתוכנן כלקוח RPC. שקע ה-IPC לתקשורת ממוקם באותה ספרייה של מנהל ההתקן עצמו. אנו זוכרים שכדי להעתיק קבצי מנהלי התקנים, יהיה טוב להשתמש ב-DaemonSet, אשר מחבר את הספרייה עם מנהל ההתקן כאמצעי אחסון. לאחר העתקת קבצי הדרייבר הדרושים, הפוד הזה לא מת, אלא מתחבר לשקע ה-IPC דרך הכרך המצורף כשרת RPC מלא. החבילה ceph-common כבר מותקנת בתוך מיכל הפוד. שקע ה-IPC מבטיח שה-kubelet יתקשר בדיוק עם הפוד שנמצא באותו צומת. הכל גאוני פשוט!..

להתראות, תוספים החיבה שלנו... בתוך העץ!

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

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

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

התוסף האחרון שהתווסף לנפחים ב-Kubernetes, CSI, נקרא לסגור את הבעיה עם אחסון נתונים מתמשך אחת ולתמיד. גרסת האלפא שלו, המכונה באופן מלא יותר בשם Out-of-Tree CSI Volume Plugins, הוכרזה במהדורה קוברנטס 1.9.

מיכל אחסון ממשק, או מוט מסתובב CSI 3000!

קודם כל, אני רוצה לציין ש-CSI הוא לא רק תוסף נפח, אלא אמיתי стандарт על יצירת רכיבים מותאמים אישית לעבודה עם מחסני נתונים. מערכות תזמור קונטיינרים כמו Kubernetes ו-Mesos היו אמורות "ללמוד" כיצד לעבוד עם רכיבים המיושמים על פי תקן זה. ועכשיו כבר למדתי Kubernetes.

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

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

כיצד פועל הפלאגין CSI ב-Kubernetes

אתה יכול ללמוד על כמה פרטים אחרים על עבודתו של CSI, למשל, מהמאמר "הבנת ה-C.S.I.' תרגום מהם פרסמנו לפני שנה.

היתרונות של יישום כזה

• עבור דברים בסיסיים כמו רישום דרייבר לצומת, מפתחי Kubernetes הטמיעו קבוצה של קונטיינרים. אינך צריך עוד ליצור תגובת JSON עם יכולות בעצמך, כפי שנעשה עבור הפלאגין Flexvolume.
• במקום "להחליק" קבצי הפעלה לצמתים, אנו מעלים כעת תרמילים לאשכול. זה מה שאנחנו מצפים בהתחלה מ-Kubernetes: כל התהליכים מתרחשים בתוך קונטיינרים הפרוסים באמצעות פרימיטיבים של Kubernetes.
• אינך צריך עוד לפתח שרת RPC ולקוח RPC כדי ליישם דרייברים מורכבים. הלקוח הוטמע עבורנו על ידי מפתחי Kubernetes.
• העברת ארגומנטים לעבודה על פרוטוקול gRPC הרבה יותר נוחה, גמישה ואמינה מאשר העברת ארגומנטים של שורת הפקודה. כדי להבין כיצד להוסיף תמיכה עבור מדדי שימוש בנפח ל-CSI על ידי הוספת שיטת gRPC סטנדרטית, תוכל לקרוא: בקשת המשיכה שלנו עבור מנהל התקן vsphere-csi.
• התקשורת מתרחשת באמצעות שקעי IPC, כדי לא להתבלבל אם הקובלט שלח את הבקשה לפוד הנכון.

האם הרשימה הזו מזכירה לך משהו? היתרונות של CSI הם לפתור את אותן בעיות, שלא נלקחו בחשבון בעת ​​פיתוח התוסף Flexvolume.

ממצאים

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

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

לנו עצמנו כבר יש ניסיון בשימוש ב-ceph-csi, vsphere-csi ומוכנים להוסיף לרשימה זו! עד כה, CSI מתמודדת עם המשימות שהוטלו עליה ברעש גדול, אבל נחכה ונראה.

אל תשכח שכל דבר חדש הוא חשיבה מחודשת טובה על הישן!

נ.ב.

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

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

מקור: www.habr.com