הניסיון שלנו בפיתוח מנהל התקן CSI ב-Kubernetes עבור Yandex.Cloud

אנו שמחים להודיע ​​ש-Flant מרחיבה את תרומתה לכלי קוד פתוח עבור Kubernetes על ידי שחרור גרסת אלפא של מנהל ההתקן CSI (ממשק אחסון מיכל) עבור Yandex.Cloud.

אבל לפני שנעבור לפרטי היישום, בואו נענה על השאלה מדוע זה נחוץ בכלל כאשר ל-Yandex כבר יש שירות שירות מנוהל עבור Kubernetes.

מבוא

למה זה?

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

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

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

מה זה ולמי?

אז, כבר דיברנו על הגישה המודרנית לאחסון ב- Kubernetes: איך CSI עובד? и איך הגיעה הקהילה לגישה זו.

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

לקחנו כבסיס לפיתוח מנהל התקן CSI עבור ענן DigitalOcean וכמה רעיונות מ מנהלי התקנים עבור GCP, שכן לאינטראקציה עם ה-API של העננים הללו (גוגל ו-Yandex) יש מספר קווי דמיון. בפרט, ה-API ו GCP, ו Yandex להחזיר חפץ Operation כדי לעקוב אחר המצב של פעולות ארוכות (לדוגמה, יצירת דיסק חדש). כדי ליצור אינטראקציה עם ה-API של Yandex.Cloud, השתמש Yandex.Cloud Go SDK.

התוצאה של העבודה שנעשתה פורסם ב-GitHub ועשויים להיות שימושיים עבור אלה שמסיבה כלשהי, משתמשים בהתקנת Kubernetes משלהם במכונות וירטואליות של Yandex.Cloud (אך לא באשכול מנוהל מוכן) ורוצים להשתמש (להזמין) דיסקים דרך CSI.

Реализация

תכונות עיקריות

כרגע מנהל ההתקן תומך בפונקציות הבאות:

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

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

הקושי העיקרי ואיך להתגבר עליו

היעדר היכולת להגדיל דיסקים בזמן אמת ב-Yandex.Cloud API היא מגבלה שמסבכת את פעולת שינוי הגודל עבור PV (Persistent Volume): במקרה זה, יש צורך לעצור את הפוד של האפליקציה שמשתמש בדיסק, וזה יכול לגרום ליישומי השבתה.

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

אם לפלאגין יש רק VolumeExpansion.OFFLINE יכולת הרחבה ונפח מתפרסמים כעת או זמינים בצומת אז ControllerExpandVolume יש להתקשר רק לאחר:

• לפלאגין יש בקר PUBLISH_UNPUBLISH_VOLUME יכולת ו ControllerUnpublishVolume הופעל בהצלחה.

אחרת

• לפלאגין אין בקר PUBLISH_UNPUBLISH_VOLUME יכולת, לפלאגין יש צומת STAGE_UNSTAGE_VOLUME יכולת, ו NodeUnstageVolume הושלם בהצלחה.

אחרת

• לפלאגין אין בקר PUBLISH_UNPUBLISH_VOLUME יכולת, ולא צומת STAGE_UNSTAGE_VOLUME יכולת, ו NodeUnpublishVolume הסתיים בהצלחה.

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

עם זאת, למרבה הצער יישום מפרט ה-CSI באמצעות קרונות צד אינו עומד בדרישות הבאות:

• במיכל צד csi-attacher, שאמור להיות אחראי לנוכחות הפער הנדרש בין הרכיבים, הפונקציונליות הזו פשוט לא מיושמת בשינוי הגודל הלא מקוון. נפתח דיון בנושא כאן.
• מה זה בעצם מיכל צד בהקשר הזה? התוסף CSI עצמו אינו יוצר אינטראקציה עם ה-API של Kubernetes, אלא מגיב רק לקריאות gRPC הנשלחות אליו באמצעות קונטיינרים צדדיים. הכי מאוחר נמצאים בפיתוח על ידי קהילת Kubernetes.

במקרה שלנו (תוסף CSI), פעולת הגדלת הדיסק נראית כך:

1. אנו מקבלים שיחת gRPC ControllerExpandVolume;
2. אנו מנסים להגדיל את הדיסק ב-API, אך אנו מקבלים שגיאה לגבי חוסר האפשרות לבצע את הפעולה מכיוון שהדיסק מותקן;
3. אנו מאחסנים את מזהה הדיסק במפה, המכילה את הדיסקים שעבורם יש לבצע את פעולת ההגדלה. להלן, לקיצור, נקרא למפה זו בשם volumeResizeRequired;
4. הסר באופן ידני את הפוד שמשתמש בדיסק. Kubernetes יפעיל אותו מחדש. כדי שלדיסק אין זמן לעלות (ControllerPublishVolume) לפני השלמת פעולת ההגדלה בעת ניסיון לעלות, אנו בודקים שהדיסק הנתון עדיין בפנים volumeResizeRequired ולהחזיר שגיאה;
5. מנהל ההתקן של CSI מנסה לבצע מחדש את פעולת שינוי הגודל. אם הפעולה הצליחה, הסר את הדיסק מ volumeResizeRequired;
6. כי מזהה דיסק חסר volumeResizeRequired, ControllerPublishVolume עובר בהצלחה, הדיסק מותקן, הפוד מתחיל.

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

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

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

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

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

כיצד להתחיל להשתמש?

מנהל ההתקן נתמך בגרסה 1.15 ומעלה של Kubernetes. כדי שהנהג יעבוד, יש לעמוד בדרישות הבאות:

• דגל --allow-privileged מוגדר לערך true עבור שרת API ו-kubelet;
• כלול --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true עבור שרת API ו-kubelet;
• התפשטות הר (התפשטות הר) חייב להיות זמין באשכול. בעת שימוש ב-Docker, יש להגדיר את הדמון כך שיאפשר רכיבות משותפות.

כל השלבים הדרושים להתקנה עצמה מתואר ב-README. ההתקנה כוללת יצירת אובייקטים ב-Kubernetes ממניפסטים.

כדי שהנהג יעבוד תצטרך את הדברים הבאים:

• ציין את מזהה הספרייה במניפסט (folder-id) Yandex.Cloud (ראה תיעוד);
• כדי ליצור אינטראקציה עם ה-API של Yandex.Cloud, מנהל ההתקן של CSI משתמש בחשבון שירות. במניפסט, סוד חייב לעבור מפתחות מורשים מחשבון השירות. בתיעוד מְתוּאָר, כיצד ליצור חשבון שירות ולקבל מפתחות.

הכל מהכל - נסה את זה, ונשמח לקבל משוב ו נושאים חדשיםאם אתה נתקל בבעיות כלשהן!

תמיכה נוספת

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

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

נ.ב.

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

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

מקור: www.habr.com