معماری High Availability در Kubernetes Bare-metal با kube-vip

یکی از بزرگترین چالش‌های راه‌اندازی کلاستر Kubernetes در محیط‌های On-premise یا Bare-metal، مدیریت Control Plane HA و سرویس‌های Load Balancer است. در کلاودهای عمومی، این وظیفه بر عهده Cloud Provider است، اما در دیتاسنتر شخصی شما، داستان متفاوت است.
ابزار kube-vip راهکاری که برخلاف روش‌های سنتی، مستقیماً داخل کلاستر و به صورت Cloud-Native زیست می‌کند.

معماری و چرایی تفاوت kube-vip
تا پیش از این، استاندارد طلایی استفاده از ترکیب Keepalived و HAProxy بود. اما kube-vip پارادایم را تغییر داد. این ابزار از قابلیت‌های خود کوبرنتیز برای مدیریت دسترسی‌پذیری استفاده می‌کند.
معماری در سطح Control Plane:
در این سطح، kube-vip به عنوان یک Static Pod یا DaemonSet روی گره‌های Control Plane قرار می‌گیرد. با استفاده از پروتکل ARP (در لایه ۲) یا BGP (در لایه ۳)، یک Virtual IP (VIP) ایجاد می‌کند که ترافیک API Server را مدیریت می‌کند.
اگر گره Leader از دسترس خارج شود، kube-vip از طریق Raft-based election یا مکانیزم‌های بومی خود، VIP را در میلی‌ثانیه به گره دیگر منتقل می‌کند.

جایگزین هوشمند برای LoadBalancer Service:
بزرگترین جذابیت kube-vip برای من، قابلیت Service Type LoadBalancer است. این ابزار می‌تواند به صورت خودکار Watcher روی سرویس‌های کوبرنتیز ست کند و به محض ایجاد یک سرویس از نوع LoadBalancer، یک IP از رنج تعیین شده به آن اختصاص داده و آن را در شبکه Advertise کند.

چرا به عنوان یک معمار سیستم باید به آن توجه کنید؟
حذف وابستگی‌های خارجی:
شما دیگر نیازی به مدیریت یک Load Balancer خارجی یا تنظیمات پیچیده لایه ۳ خارج از کلاستر ندارید. همه چیز در قالب Manifestهای کوبرنتیزی مدیریت می‌شود.

پشتیبانی دوگانه (L2 & L3):
در L2 Mode، از Leader Election و پروتکل ARP استفاده می‌کند (مناسب برای شبکه‌های ساده و کوچک).
در L3 Mode، با استفاده از پروتکل BGP با سوئیچ‌های فیزیکی صحبت می‌کند (مناسب برای محیط‌های Enterprise و سناریوهای Multi-rack).

یکپارچگی با کلاستر API (CAPI):
به خوبی با پروژه‌هایی مثل Cluster API هماهنگ است و فرآیند Provisioning کلاستر را کاملاً خودکار می‌کند.

در پیاده‌سازی kube-vip، دقت به Interface Names حیاتی است. از آنجایی که kube-vip مستقیما با کارت شبکه میزبان درگیر می‌شود، در محیط‌های ناهمگون که نام اینترفیس‌ها متفاوت است (مثلا یکی eth0 و دیگری ens192)، حتماً از قابلیت تشخیص خودکار یا تنظیمات دقیق در درایور استفاده کنید تا با مشکل Bind نشدن VIP مواجه نشوید.

جمع‌بندی: چه زمانی kube-vip انتخاب نهایی ماست؟
انتخاب بین ابزارهای مدیریت ترافیک در کوبرنتیز، همیشه یک توازن (Trade-off) است. اگر بخواهم در سه خط خلاصه کنم:
در واقع kube-vip برای کسانی است که به دنبال سادگی عملیاتی هستند. برخلاف MetalLB که تمرکز اصلی‌اش فقط روی LoadBalancer Service است، kube-vip یک راهکار دو منظوره (Hybrid) ارائه می‌دهد: هم لایه Control Plane را High Available می‌کند و هم نقش Load Balancer را برای سرویس‌ها ایفا می‌کند.
در نهایت، معماری موفق معماری‌ای نیست که پیچیده‌ترین ابزار را انتخاب کند، بلکه معماری‌ای است که نقاط شکست (Single Points of Failure) را با کمترین سربار مدیریتی حذف کند. kube-vip دقیقاً در همین نقطه ایستاده است.


@DevTwitter | <Vahid Aghazadeh/>