היכרות עם Kubernetes CCM (מנהל בקר ענן) עבור Yandex.Cloud

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

מבוא

למה זה?

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

מה זה בדיוק CCM?

בדרך כלל, אנו מכינים את הסביבה סביבנו לאשכול מבחוץ - למשל, באמצעות Terraform. אבל לפעמים יש צורך לנהל את סביבת הענן שסביבנו מאשכול. אפשרות זו ניתנת, והיא מיושמת CCM.

באופן ספציפי, Cloud Controller Manager מספק חמישה סוגים עיקריים של אינטראקציה:

1. מקרים - מיישמת קשר של 1:1 בין אובייקט צומת ב-Kubernetes (Node) ומכונה וירטואלית בספק הענן. בשביל זה אנחנו:
   • למלא את השדה spec.providerID בחפץ Node. לדוגמה, עבור OpenStack CCM לשדה זה יש את הפורמט הבא: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. אתה יכול לראות את השם של ספק הענן ואת ה-UUID הייחודי של השרת (מכונה וירטואלית ב-OpenStack) של האובייקט;
   • מַשׁלִים nodeInfo בחפץ Node מידע על המכונה הוירטואלית. לדוגמה, אנו מציינים סוג מופע ב-AWS;
   • אנו בודקים נוכחות של מכונה וירטואלית בענן. לדוגמה, אם חפץ Node נכנסה למדינה NotReady, תוכל לבדוק אם המכונה הוירטואלית קיימת בכלל בספק הענן על ידי providerID. אם הוא לא קיים, מחק את האובייקט Node, שאחרת יישאר באשכול לנצח;
2. אזורים – מגדיר את תחום הכשל עבור האובייקט Node, כך שהמתזמן יוכל לבחור צומת עבור הפוד לפי האזורים והאזורים בספק הענן;
3. LoadBalancer - בעת יצירת אובייקט Service עם סוג LoadBalancer יוצר מעין איזון שיכוון תנועה מבחוץ לצמתי האשכולות. לדוגמה, ב- Yandex.Cloud אתה יכול להשתמש NetworkLoadBalancer и TargetGroup למטרות אלו;
4. מסלול – בונה רשת בין צמתים, כי על פי דרישות Kubernetes, לכל פוד חייב להיות כתובת IP משלו ולהיות מסוגל להגיע לכל פוד אחר. למטרות אלו, ניתן להשתמש ברשת שכבת-על (VXLAN, GENEVE) או להגדיר טבלת ניתוב ישירות ברשת הווירטואלית של ספק הענן:

   

5. תכולה - מאפשר הזמנה דינמית של PV באמצעות PVC ו-SC. בתחילה, פונקציונליות זו הייתה חלק מ-CCM, אך בשל מורכבותה הרבה היא הועברה לפרויקט נפרד, Container Storage Interface (CSI). דיברנו על CSI יותר מפעם אחת писали וכפי שכבר הוזכר, אפילו מְשׁוּחרָר מנהל התקן CSI.

בעבר, כל הקוד המקיים אינטראקציה עם הענן היה ממוקם במאגר Git הראשי של פרויקט Kubernetes בכתובת k8s.io/kubernetes/pkg/cloudprovider/providers, אבל הם החליטו לנטוש את זה בגלל אי ​​הנוחות בעבודה עם בסיס קוד גדול. כל ההטמעות הישנות הועברו אל מאגר נפרד. לנוחות התמיכה והפיתוח, הועברו גם כל הרכיבים הנפוצים מאגר נפרד.

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

כדי לכתוב יישום משלך של CCM, מספיק ליישם ממשקי Go נדרשים.

И זה מה שקיבלנו.

Реализация

איך הגעת לזה

התחלנו בפיתוח (או ליתר דיוק, אפילו להשתמש) עם מוכן(!) CCM עבור Yandex.Cloud לפני שנה.

עם זאת, ביישום זה היה חסר לנו:

• אימות באמצעות אסימון JWT IAM;
• תמיכה בבקר שירות.

בהסכמה עם המחבר (דליסין) בטלגרם, חילקנו את yandex-cloud-controller-manager והוספנו את הפונקציות החסרות.

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

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

• מקרים;
• אזורים;
• LoadBalancer.

בעתיד, כאשר Yandex.Cloud יתחיל לעבוד עם יכולות VPC מתקדמות, נוסיף ממשק מסלולים.

LoadBalanacer כאתגר עיקרי

בתחילה, ניסינו, כמו יישומי CCM אחרים, ליצור זוג LoadBalancer и TargetGroup עבור כל אחד Service עם סוג LoadBalancer. עם זאת, Yandex.Cloud גילה מגבלה מעניינת אחת: אתה לא יכול להשתמש TargetGroups עם מצטלבים Targets (זוג SubnetID - IpAddress).

לכן, בתוך ה-CCM שנוצר, מופעל בקר, שכאשר אובייקטים משתנים Node אוסף מידע על כל הממשקים בכל מכונה וירטואלית, מקבץ אותם לפי השתייכותם לחלק מסוים NetworkID, יוצר על ידי TargetGroup על NetworkID, וגם עוקב אחר הרלוונטיות. לאחר מכן, בעת יצירת אובייקט Service עם סוג LoadBalanacer אנחנו פשוט מצרפים פריט שנוצר מראש TargetGroup לחדש NetworkLoadBalanacerאני.

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

CCM תומך ב-Kubernetes גרסה 1.15 ומעלה. באשכול, כדי שזה יעבוד, זה דורש את הדגל --cloud-provider=external הוגדר ל true עבור kube-apiserver, kube-controller-manager, kube-scheduler וכל הקובלטים.

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

כדי להשתמש ב-CCM תצטרך גם:

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

נשמח לקבל את המשוב שלך ו נושאים חדשיםאם אתה נתקל בבעיות כלשהן!

תוצאות של

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

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

נ.ב.

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

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

מקור: www.habr.com