‏مدیریت چندین کلاستر Kubernetes روی OpenStack با k0rdent و HCP

یکی از چالش‌های اصلی تیم‌های DevOps اینه که وقتی تعداد کلاسترهای Kubernetes زیاد می‌شه، هزینه و پیچیدگی به‌سرعت از کنترل خارج می‌شه. توی یه ستاپ معمولی، هر کلاستر حداقل به ۳ نود مستقل برای کنترل‌پلن نیاز داره. حالا این رو ضربدر محیط‌های dev، staging و production کن، می‌بینی که قبل از اجرای اولین workload واقعی، منابع زیادی داری می‌سوزونی.

اینجاست که Hosted Control Planes یا HCP وارد می‌شه. ایده اصلیش اینه که به‌جای اجرای API server، etcd و controllerها روی نودهای اختصاصی هر کلاستر، همه این‌ها داخل یه کلاستر مدیریتی مرکزی اجرا بشن. نتیجه؟ VM کمتر، هزینه پایین‌تر، آپگرید ساده‌تر و یه داشبورد واحد برای کل فلیت.

این مقاله روی ترکیب سه ابزار تمرکز داره: k0s که یه توزیع سبک و ساده Kubernetes هست، k0rdent که مسئول orchestration چند کلاستره، و OpenStack که زیرساخت ابر خصوصی رو فراهم می‌کنه. این سه‌تا با هم یه استک قدرتمند برای platform engineering می‌سازن.

روند کلی اینطوریه که ابتدا یه VM لینوکسی با مشخصات مناسب آماده می‌کنی و k0s رو روش نصب می‌کنی تا کلاستر مدیریتی بسازی. بعد k0rdent رو از طریق Helm روی این کلاستر می‌نشونی. k0rdent به‌عنوان یه کنترلر داخل کلاستر اجرا می‌شه و چرخه حیات کلاسترهای دیگه رو مدیریت می‌کنه.

مرحله بعدی اینه که اطلاعات دسترسی OpenStack رو به‌صورت یه Secret در Kubernetes ذخیره کنی تا k0rdent بتونه به‌جای تو VM بسازه. فرمت مورد نیاز یه فایل clouds.yaml استاندارده که توش اطلاعات auth، پروژه و region رو تعریف می‌کنی. بعد از اون یه شیء Credential در k0rdent تعریف می‌کنی که این Secret رو بهش لینک می‌کنه.

قلب ماجرا ClusterDeployment هست؛ یه فایل YAML که توش به‌صورت declarative مشخص می‌کنی چند worker node می‌خوای، از چه image و flavor ای استفاده بشه و به کدوم شبکه وصل بشن. وقتی این فایل رو apply می‌کنی، k0rdent شروع می‌کنه به ساختن VM در OpenStack، اما نکته جالب اینه که فقط worker nodeها توی OpenStack ساخته می‌شن؛ کنترل‌پلن همچنان داخل کلاستر مدیریتی مرکزیه.

بعد از آماده شدن کلاستر جدید، k0rdent یه Secret حاوی kubeconfig می‌سازه که می‌تونی باهاش مستقیم به کلاستر worker دسترسی داشته باشی. تست scale کردن هم به همین سادگیه؛ فقط کافیه workersNumber رو توی ClusterDeployment تغییر بدی، k0rdent خودش reconcile می‌کنه و VM جدید توی OpenStack می‌سازه.

مهم‌ترین تفاوت این معماری با ستاپ‌های سنتی اینه که دیگه هر کلاستر یه جزیره مستقل نیست. همه کنترل‌پلن‌ها یه جا زندگی می‌کنن، یه جا state نگه داری می‌شه و وقتی مشکلی پیش میاد یه جا رو بررسی می‌کنی. این یعنی به‌جای صرف وقت برای زنده نگه داشتن کلاسترها، می‌تونی روی کارهای واقعی تمرکز کنی.

نکات کلیدی:

• HCP کنترل‌پلن همه کلاسترها رو داخل یه کلاستر مرکزی اجرا می‌کنه و منابع رو بهینه می‌کنه
• فقط worker nodeها توی OpenStack ساخته می‌شن، نه کنترل‌پلن
• k0rdent از طریق ClusterDeployment کل چرخه حیات کلاستر رو به‌صورت declarative مدیریت می‌کنه
• scale کردن کلاستر به همین سادگیه: عدد workersNumber رو عوض کن
• این رویکرد برای تیم‌هایی که روی OpenStack کار می‌کنن و باید ده‌ها کلاستر مدیریت کنن ایده‌آله
• قبل از شروع باید quota کافی در OpenStack (instance، volume، floating IP) داشته باشی