هر سرویس مدیریت شده Kubernetes، EKS، GKE، AKS، در سطح فلز خالی اجرا می شود. هواپیمای کنترل روی سخت افزار فیزیکی کار می کند. گره‌های کارگر شما یا ماشین‌های مجازی هستند که بخش‌هایی از سرورهای فیزیکی را اجاره می‌کنند، یا نمونه‌های فلزی خالی هستند که لایه VM را به طور کامل حذف می‌کنند. ارزش یک سرویس مدیریت شده در اتوماسیون هواپیمای کنترل و ادغام اکوسیستم است، نه در مزیت زیرساختی اساسی.
اجرای K8 بر روی فلزی خالی یا سرورهای اختصاصی InMotion به این معنی است که پادهای شما مستقیماً روی سخت‌افزار فیزیکی بدون سربار هایپروایزر، ذخیره‌سازی NVMe قابل پیش‌بینی برای حجم‌های ثابت، و قیمت ماهانه ثابت که با ساعت‌های گره یا حجم تماس API مقیاس نمی‌شود، اجرا می‌شوند.
مشکل Hypervisor در Cloud K8s
گره‌های کارگر ابری Kubernetes ماشین‌های مجازی هستند. KVM، Xen یا Hyper-V بین کانتینرهای شما و سخت افزار فیزیکی قرار دارند. این دو مالیات عملکرد را معرفی می کند که فلز برهنه حذف می کند:
- مصرف CPU: هایپروایزرها معمولاً 5 تا 15 درصد سربار CPU را برای تماس های سیستمی و سوئیچ های زمینه اضافه می کنند. برای بارهای کاری که فعالیت تماس های سیستمی سنگین انجام می دهند (سرویس های فشرده شبکه، برنامه های کاربردی I/O-Bound)، این یک تاخیر قابل اندازه گیری است.
- مصرف حافظه: هایپروایزرها ساختار حافظه خود را همراه با حافظه VM حفظ می کنند. یک گره 16 گیگابایتی ابر کارگر کمتر از 16 گیگابایت برای اجزای سیستم و پادهای Kubernetes بعد از سربار هایپروایزر و سیستم عامل مهمان دارد.
در سطح فلزی خالی، یک سرور 192 گیگابایتی به Kubernetes 192 گیگابایت کامل منهای هسته سیستم عامل (تقریباً 2-4 گیگابایت) می دهد. ظرفیت هر گیگابایت در هر گره واقعی است، نه اسمی.
گزینه های معماری خوشه ای
K8 با یک گره برای توسعه و مرحله
یک سرور InMotion Hosting Extreme که k3s یا kubeadm را اجرا می‌کند با نقش‌های Master و Worker ترکیبی یک محیط سناریویی عملی است. k3s به ویژه در اینجا مرتبط است: توزیع Kubernetes درجه تولید را با یک باینری واحد، SQLite (یا etcd خارجی برای HA) اجرا می‌کند، و با حداقل ردپایی که منابع بیشتری را برای بارهای کاری باقی می‌گذارد.
K8 های تک گره برای تولید برای بارهای کاری که نیاز به در دسترس بودن بالا دارند مناسب نیستند (یک شکست یک گره همه چیز را از بین می برد)، اما برای انعکاس پیکربندی های تولید مرحله بندی بدون پرداخت هزینه برای چندین سرور عالی است.
خوشه های تولید چند گره
یک خوشه Kubernetes تولیدی به حداقل 3 گره صفحه کنترل برای نصاب etcd نیاز دارد. در عمل، بسیاری از تیم ها 1 سرور هواپیمای کنترل اختصاصی به اضافه 2-3 گره کارگر را اجرا می کنند. با سرورهای اختصاصی InMotion:
- هواپیمای کنترل: سطح پیشرفته (149.99 دلار در ماه)، 64 گیگابایت رم برای اجزای هواپیمای کنترل K8s در خوشه های زیر 100 گره کافی است.
- گره های کاری: سطح فوق العاده (349.99 دلار در ماه) به ازای هر کارگر برای حجم کاری فشرده. ضروری یا پیشرفته برای پروفایل های کپسول سبک تر
- شبکه: پورت 10 گیگابیت بر ثانیه بر روی گره های کارگر برای ترافیک بین ماژول ها در شبکه های مش با توان بالا
برنامه ریزی تراکم کف بر روی سخت افزار 192 گیگابایتی / 16 هسته ای
چگالی غلاف Kubernetes به درخواست های منابع و محدودیت های تعریف شده در مشخصات غلاف بستگی دارد. چارچوب برنامه ریزی خشن:
| زیر نمایه | درخواست CPU | درخواست حافظه | طبقات در هر گره 192 گیگابایت |
| میکروسرویس (معمولی) | 100 متر | 256 مگابایت | ~ 600 کپسول (حافظه محدود) |
| برنامه وب تحت | 250 متر | 512 مگابایت | ~ 300 کپسول (حافظه محدود) |
| سرویس API تحت | 500 متر | 1 گیگابایت | ~ 160 کپسول (حافظه محدود) |
| اپراتور ماشین / پایگاه داده | 1 هسته | 4 گیگابایت | ~40 کپسول (حافظه محدود) |
در عمل، Kubernetes منابع را برای پادهای سیستم (kube-system namespace)، سیستم عامل گره و فضای تخلیه ذخیره می کند. حافظه قابل تخصیص در یک گره 192 گیگابایتی معمولاً پس از این رزروها حدود 175-180 گیگابایت است. اعداد بالا بیانگر حداکثرهای نظری هستند. خوشه های واقعی در 60-70 درصد حداکثر چگالی اجرا می شوند تا آزادی زمان بندی را حفظ کنند.
پردازنده 16 هسته ای EPYC به راحتی برنامه ریزی ماژول تا حدود 500 ماژول فعال را قبل از اینکه CPU تبدیل به یک گلوگاه شود، کنترل می کند. اکثر خوشه های واقعی با 100-300 غلاف به هیچ وجه به این حد نزدیک نیستند.
ذخیره سازی: حجم های پایدار NVMe
تامین کننده جاده های محلی
ساده‌ترین راه‌اندازی حجم ذخیره‌سازی دائمی روی یک گره یا هر گره، از ارائه‌دهنده مسیر محلی استفاده می‌کند (پشتیبانی شده توسط Rancher، به طور پیش‌فرض در k3s موجود است). این باعث ایجاد PersistentVolumeClaims می شود که توسط دایرکتوری ها در سیستم فایل NVMe گره پشتیبانی می شود.
برای بارهای کاری که برای زنده ماندن از خرابی گره ها نیازی به ذخیره سازی ندارند (برنامه های بدون حالت با پایگاه های داده خارجی، کارهایی که از فضای خالی استفاده می کنند)، مسیر NVMe محلی حداکثر توان ذخیره سازی ممکن را با سربار شبکه صفر فراهم می کند. یک غلاف PostgreSQL در یک مسیر NVMe محلی مانند PostgreSQL که مستقیماً روی همان حجم NVMe اجرا می شود یکسان عمل می کند.
Longhorn برای ذخیره سازی تکراری
Longhorn (همچنین از Rancher) یک راه حل Cloud Native Storage است که حجم ها را در چندین گره خوشه ای تکرار می کند. برای خوشه‌های چند گره‌ای که زمان‌بندی طبقه باید مستقل از محل ذخیره‌سازی باشد، Longhorn داده‌های PVC را روی ۲ یا ۳ گره تکرار می‌کند.
سربار تکرار NVMe قابل قبول است: مسیر داده Longhorn تقریباً 10-20٪ تأخیر را در مسیر محلی اضافه می کند که هنوز سریعتر از ذخیره سازی بلوک ابری متصل به شبکه است. برای پایگاه های داده تولید در Kubernetes، Longhorn انعطاف پذیری را فراهم می کند که مسیر محلی نمی تواند.
انتخاب یک کلاس ذخیره سازی با توجه به بار
- مسیر محلی: طبقه بدون حالت، حافظه پنهان ساخت CI/CD، حجم های خراش برای کارهای دسته ای. حداکثر کارایی، بدون تکرار.
- Longhorn (1 ماکت): استقرارهای تک گره ای که مدیریت پی وی سی را بدون رفع میل گره می خواهند.
- لانگ هورن (2-3 نشانه): پایگاه های داده تولید، سرویس های حالت دار که در صورت خرابی گره ها به دسترسی بالا نیاز دارند.
Cloud Kubernetes از پلاگین‌های CNI مخصوص فروشنده (VPC CNI برای EKS و غیره) استفاده می‌کند که با اولیه‌های شبکه ابری که در دستگاه‌های فلزی موجود نیستند یکپارچه می‌شوند. برای K8 های فلزی لخت، سه افزونه بیشتر موارد استفاده را پوشش می دهند:
- فلانل: روکش ساده VXLAN، ساده ترین کارکرد، عملکرد قابل قبول برای اکثر بارهای کاری. به طور پیش فرض در k3s. عدم اجرای خط مشی شبکه
- کالیکو: شبکه مبتنی بر BGP با پشتیبانی کامل از NetworkPolicy. برای خوشه های تولیدی که نیاز به جداسازی ترافیک طبقه به طبقه بین فضاهای نام دارند، توصیه می شود.
- گل مژه: بر اساس eBPF، کمترین سربار از این سه مورد، iptable ها را با پردازش بسته در سطح هسته جایگزین می کند. بهترین عملکرد برای خدمات شبکه با کارایی بالا. از نظر عملیاتی پیچیده تر است.
برای اکثر تیم‌هایی که با K8های فلزی لخت شروع می‌کنند، Calico تعادل مناسب را فراهم می‌کند: پشتیبانی کامل از NetworkPolicy برای تقسیم‌بندی امنیتی، عملکرد پایدار و مستندات خوب. وقتی این خوشه به ترافیک شرقی-غربی با توان عملیاتی بالا خدمت می‌کند که در آن سربار iptables در Calico قابل اندازه‌گیری می‌شود، سیلیوم ارزش ارزیابی را دارد.
وقتی سرویسی از نوع LoadBalancer ایجاد می کنید، Cloud Kubernetes به طور خودکار یک متعادل کننده بار ابری ارائه می دهد. در سطح فلز خالی، هیچ ارائه دهنده ابری وجود ندارد که این متعادل کننده بار را ارائه دهد. خدمات به طور نامحدود در حالت معلق باقی می مانند.
MetalLB این را حل می کند. به عنوان یک کنترل کننده در خوشه کار می کند و آدرس های IP را از یک مجموعه پیکربندی شده از خدمات LoadBalancer اختصاص می دهد. در حالت L2 (ساده تر)، MetalLB به درخواست های ARP برای آدرس های IP سرویس از گره ای که نقطه پایانی سرویس در آن قرار دارد، پاسخ می دهد. در حالت BGP، مسیرها را مستقیماً به روترهای بالادست برای متعادل کردن بار مناسب تبلیغ می کند.
برای اکثر استقرار سرورهای اختصاصی InMotion که K8s را اجرا می کنند، MetalLB در حالت L2 با یک مخزن IP کوچک (حتی یک زیرشبکه /30 آدرس IP اضافی) برای افشای خدمات خارجی کافی است. یک کنترلر ورودی Nginx را در بالای MetalLB اضافه کنید تا مسیریابی HTTP/HTTPS را بدون ثبت IP اختصاصی برای هر سرویس انجام دهد.
| عامل | بره متال K8 | EKS / GKE / AKS |
| قیمت گره کار در ماه | 99-350 دلار (جدا) | 100-800 دلار + (گره های VM) |
| کنترل هزینه های هواپیما | خود رانندگی (رایگان) | 72-150 دلار در ماه (هزینه مدیریت شده) |
| تاخیر در ذخیره سازی | NVMe مستقیم (~0.1 میلی ثانیه) | بلوک شبکه (~1-5ms) |
| مقیاس بندی خودکار | Autoscaler دستی یا کلاستر | ابزار مقیاس خودکار ابر داخلی |
| مناطق جهانی | لس آنجلس، آمستردام | بیش از 30 منطقه جهانی |
| سربار مدیریت | متوسط (kubeadm/k3s) | پایین (هواپیما کنترل کنترل شده) |
| هزینه های ماهانه قابل پیش بینی | بله | متغیر (بر اساس استفاده) |
فلزی لخت K8s برنده عملکرد هزینه و ذخیره سازی برای بارهای کاری قوی است. K8s با سادگی کار و توزیع جهانی، برنده های ابری را مدیریت کرد. انتخاب صحیح بستگی به این دارد که آیا حجم کاری شما الزامات توزیع جغرافیایی دارد و آیا تیم شما می تواند یک هواپیمای کنترلی را مدیریت کند یا خیر.
Docker Swarm به عنوان یک جایگزین ساده تر
هر بار کاری کانتینری به Kubernetes نیاز ندارد. Docker Swarm روی یک سرور اختصاصی، ده‌ها سرویس را در کانتینرهایی با کسری از پیچیدگی عملیاتی K8 انجام می‌دهد. اگر معماری شما کمتر از 10 تا 15 سرویس جداگانه دارد و به ویژگی‌های خاص K8s نیاز ندارد (تعریف منابع سفارشی، محدودیت‌های زمان‌بندی پیچیده، ابزارهای اکوسیستم Helm)، Swarm در سرور اختصاصی InMotion در یک بعد از ظهر مستقر می‌شود.
مدل شبکه تک‌گره Docker Swarm ساده‌تر از K8 است: شبکه‌های همپوشانی برای کشف سرویس، پورت‌های منتشر شده برای دسترسی خارجی، Traefik یا Nginx برای ورود. بدون مکمل های CNI بدون MetalLB. برای تیم هایی که احساس می کنند هزینه های عملیاتی K8 ها بیشتر از مزایای معماری حجم کاری آنها است، Swarm یک انتخاب تولید معتبر است.
اولین قدم ها
- سرور فلزی یا اختصاصی، سطح فوق العاده برای ایستگاه های کاری تولیدی K8s را سفارش دهید
- k3s را برای خوشه های تک گره یا خوشه های چند گره سبک وزن نصب کنید. kubeadm برای کنترل کامل بر پیکربندی کلاستر
- Calico CNI را برای پشتیبانی از NetworkPolicy از روز اول پیکربندی کنید
- برای پشتیبانی از سرویس LoadBalancer، MetalLB را در حالت L2 نصب کنید
- یک ارائه دهنده مسیر محلی برای توسعه PVC راه اندازی کنید. Longhorn برای بارهای کاری تولید دولتی
- Premier Care را برای مدیریت سطح سیستم عامل در میزبان اصلی اضافه کنید
تیم هایی که در حال حاضر 800 دلار یا بیشتر در ماه برای بارهای کاری مدیریت شده Kubernetes پرداخت می کنند، معمولاً این هزینه را در اولین چرخه صورتحساب پس از انتقال بارهای کاری حالت ثابت به فلز لخت جبران می کنند. سرمایه گذاری عملیاتی در مدیریت هواپیمای کنترل واقعی است، اما هزینه پیکربندی یکباره است، نه یک سربار مستمر متناسب با هزینه های محاسبه شما.
