پلتفرم Kubernetes-as-a-Service

زمینه: معماری پلتفرم داخلی
نقش: مهندسی پلتفرم
چالش: انتزاع آماده‌سازی منابع کلاد و عملیات چرخه عمر Kubernetes در یک جریان تکرارپذیر، بدون پنهان‌کردن محدودیت‌های زیرساخت.

چرخه ساخت · مقیاس‌دهی · حذف از طریق APIهای زیرساخت

معماری

جریان تأییدشده پلتفرم چنین بود: پرتال داخلی ← لایه ارکستریشن FastAPI ← آماده‌سازی Project و منابع OpenStack ← Cluster API ← CAPO ← ساخت کلاستر Kubernetes.

لایه FastAPI عملیات زیرساخت و چرخه عمر را هماهنگ می‌کرد تا تمام جزئیات کلاد مستقیماً در معرض پرتال قرار نگیرند.

قابلیت‌های پلتفرم

توپولوژی قابل پیکربندی برای Control Plane و Worker.
انتخاب Flavor برای نودهای Control Plane و Worker.
جداسازی Project و آماده‌سازی منابع OpenStack.
جریان‌های ساخت، مقیاس‌دهی و حذف کلاستر.
یکپارچه‌سازی Octavia برای توزیع بار.
مدیریت Floating IP و شبکه Calico.

منطق معماری

Cluster API و CAPO یک مدل اعلانی برای چرخه عمر روی زیرساخت OpenStack فراهم کردند. به این ترتیب عملیات کلاستر به APIهای زیرساخت متصل ماند و انتخاب‌های توپولوژی شفاف بود، در حالی که پرتال داخلی با یک رابط سرویس محدودتر کار می‌کرد.

Magnum، Kamaji و Gardener نیز به‌عنوان رویکردهای مرتبط ارزیابی شدند. اشاره به این ارزیابی به معنی استفاده تولیدی از همه گزینه‌ها نیست. Kamaji همچنین در ارتباط با معماری Control Plane بررسی شد.

این کار مهندسی پلتفرم را از مسیر انتزاع، ارکستریشن، تکرارپذیری و مالکیت چرخه عمر نشان می‌دهد؛ نه صرفاً نصب اجزای Kubernetes.