در ادامه اخیر برای Yandex.Cloud ما در حال انتشار پروژه منبع باز دیگری برای این ابر هستیم - . CCM نه تنها برای کلستر، بلکه برای خود درایور CSI نیز مورد نیاز است. جزئیات در مورد هدف آن و برخی از ویژگی های پیاده سازی در زیر برش است.
معرفی
چرا این هست؟
انگیزه هایی که ما را بر آن داشت تا CCM را برای Yandex.Cloud توسعه دهیم، کاملاً با مواردی که قبلاً در توضیح داده شد مطابقت دارد. درایورهای CSI ما بسیاری از خوشه های Kubernetes را از ارائه دهندگان ابری مختلف نگهداری می کنیم که برای آنها از یک ابزار استفاده می کنیم. این تسهیلات متعددی را با "دور زدن" راه حل های مدیریت شده این ارائه دهندگان پیاده سازی می کند. بله، ما یک مورد و نیاز نسبتاً خاص داریم، اما پیشرفت های ایجاد شده به دلیل آنها ممکن است برای سایر کاربران مفید باشد.
CCM دقیقا چیست؟
به طور معمول، ما محیط اطراف خود را برای خوشه آماده می کنیم از بیرون - به عنوان مثال، با استفاده از Terraform. اما گاهی اوقات نیاز به مدیریت محیط ابری اطرافمان وجود دارد از خوشه. این امکان فراهم شده است و این است که اجرا می شود .
به طور خاص، Cloud Controller Manager پنج نوع اصلی تعامل را ارائه می دهد:
- موارد - یک رابطه 1:1 بین یک شی گره در Kubernetes پیاده سازی می کند (
Node) و یک ماشین مجازی در ارائه دهنده ابر. برای این ما:- فیلد را پر کنید
spec.providerIDدر جسمNode. به عنوان مثال، برای OpenStack CCM این فیلد فرمت زیر را دارد:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. شما می توانید نام ارائه دهنده ابر و UUID منحصر به فرد سرور (ماشین مجازی در OpenStack) شی را ببینید. - متمم
nodeInfoدر جسمNodeاطلاعات در مورد ماشین مجازی به عنوان مثال، ما نوع نمونه را در AWS مشخص می کنیم. - ما وجود یک ماشین مجازی را در فضای ابری بررسی می کنیم. به عنوان مثال، اگر یک شی
Nodeبه حالتی رفتNotReady، می توانید بررسی کنید که آیا ماشین مجازی اصلاً در ارائه دهنده ابر وجود دارد یا خیرproviderID. اگر آنجا نیست، شی را حذف کنیدNode، که در غیر این صورت برای همیشه در خوشه باقی می ماند.
- فیلد را پر کنید
- مناطق - دامنه شکست را برای شی تعیین می کند
Node، به طوری که زمانبندی می تواند یک گره برای Pod با توجه به مناطق و مناطق در ارائه دهنده ابر انتخاب کند. - متعادل کننده بار - هنگام ایجاد یک شی
Serviceبا نوعLoadBalancerنوعی متعادل کننده ایجاد می کند که ترافیک را از خارج به گره های خوشه هدایت می کند. به عنوان مثال، در Yandex.Cloud می توانید استفاده کنیدNetworkLoadBalancerиTargetGroupبرای این اهداف؛ - مسیر – شبکه ای بین گره ها می سازد، زیرا طبق الزامات Kubernetes، هر پاد باید آدرس IP مخصوص به خود را داشته باشد و بتواند به هر پاد دیگری دسترسی داشته باشد. برای این منظور، می توانید از یک شبکه همپوشانی (VXLAN، GENEVE) استفاده کنید یا یک جدول مسیریابی را مستقیماً در شبکه مجازی ارائه دهنده ابر تنظیم کنید:
- حجم - امکان سفارش دینامیکی 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 خودتان کافی است پیاده سازی کنید .
И .
اجرا
چطور به این موضوع رسیدی
ما توسعه (یا بهتر است بگوییم، حتی استفاده) را با آن آغاز کردیم برای Yandex.Cloud یک سال پیش.
با این حال، در این پیاده سازی ما غایب بودیم:
- احراز هویت از طریق توکن JWT IAM؛
- پشتیبانی از کنترلر خدمات
در توافق با نویسنده (دلیسین) در تلگرام، yandex-cloud-controller-manager را فورک کردیم و توابع گمشده را اضافه کردیم.
ویژگی های اصلی
در حال حاضر CCM از رابط های زیر پشتیبانی می کند:
- موارد;
- مناطق;
- متعادل کننده بار.
در آینده، زمانی که 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 و همه kubelets.
تمام مراحل لازم برای خود نصب در اینجا توضیح داده شده است . نصب به ایجاد اشیاء در Kubernetes از مانیفست خلاصه می شود.
برای استفاده از CCM به موارد زیر نیز نیاز دارید:
- در مانیفست شناسه دایرکتوری (
folder-id) Yandex.Cloud؛ - حساب سرویس برای تعامل با Yandex.Cloud API. در مانیفست
Secretضروری است از حساب سرویس در مستندات ، نحوه ایجاد حساب سرویس و دریافت کلید.
ما خوشحال خواهیم شد که نظرات شما را دریافت کنیم و اگر با هر مشکلی مواجه شدید!
نمایش نتایج: از
ما طی دو هفته گذشته از CCM پیاده سازی شده در پنج خوشه Kubernetes استفاده کرده ایم و قصد داریم تعداد آنها را در ماه آینده به 20 افزایش دهیم. ما در حال حاضر استفاده از CCM را برای نصب های بزرگ و حیاتی K8 توصیه نمی کنیم.
همانطور که در مورد CSI، ما خوشحال خواهیم شد اگر توسعه دهندگان Yandex توسعه و پشتیبانی از این پروژه را بر عهده بگیرند - ما آماده هستیم تا به درخواست آنها مخزن را انتقال دهیم تا با وظایفی که بیشتر مربوط به ما هستند مقابله کنیم.
PS
در وبلاگ ما نیز بخوانید:
- «"؛
- «"؛
- «'.
منبع: www.habr.com