TL;DR: برای ما بسیار خوب کار می کند، با حداقل سرمایه گذاری اولیه و سربار توسعه. اگر می‌توانستیم راه‌اندازی مجدد را انتخاب کنیم، دوباره این کار را انجام می‌دادیم.
Kubernetes یک پلتفرم ارکستراسیون کانتینر منبع باز است که برای مدیریت و خودکارسازی استقرار و مقیاس‌بندی برنامه‌های کانتینری استفاده می‌شود. در سال های اخیر به دلیل توانایی آن در ارائه یک تجربه ثابت در ارائه دهندگان مختلف ابر و محیط های داخلی، محبوبیت پیدا کرده است.
عملکرد Kubernetes ممکن است ترسناک به نظر برسد. عدم قطعیت Kubernetes در ارائه دهندگان ابر غیر بزرگ فناوری تا سطح بالاتر ترسناک است. بنابراین، مخلوط کردن ارائه‌دهندگان Kubernetes با استفاده از AWS و OVH، آیا فراخوانی است که آخرالزمان بر سر ما بیفتد؟ نه آنقدر که تصور می‌کردیم، تأثیرات شگفت‌انگیز کمتری بر توسعه از آنچه که حدس می‌زنید وجود دارد.
خدمات مورد نیاز برای پروژه چیست؟
البته Kubernetes، اما همچنین سایر خدمات مدیریت شده:
- پایگاه داده PostGreSQL
- سرویس فایل S3
- رجیستری داکر
- متعادل کننده بار
چرا OVH؟
برنامه ای که ما می ساختیم باید در اروپا، روی یک ابر مستقل مستقر می شد.
در زمان تصمیم گیری، OVH بالغ ترین ارائه دهنده ابر اروپایی بود که Kubernetes مدیریت شده را با استفاده از Terraform ارائه می کرد، تا آنجا که ما می دانستیم. بزرگترین ارائه دهنده هاست در اروپا است
Scaleway که همچنین Kubernetes مدیریت شده را با استفاده از Terraform ارائه می دهد، در مراحل اولیه پروژه آزمایش شده بود. اما این محدودیت ها (باز هم در آن زمان) برای موارد استفاده ما مسدود کننده بودند:
- برخی از عوارض جانبی پوشش های مدیریتی Kubernetes (به ویژه برخی مشکلات در استفاده از Traefik)
- بدون Kubernetes در شبکه خصوصی
- در دسترس بودن ناموفق رجیستری docker
هر گونه بازخوردی در مورد این یا سایر ارائه دهندگان ابر اروپایی استقبال می شود 🤓
چرا OVH از برنامه نویس تا تولید کننده نه؟
در گذشته، ما مشکلات عملکردی در Kubernetes مدیریت شده OVH داشتیم. ما نمی خواستیم تیم توسعه را با مشکلات زیرساختی کند کنیم. مهمترین چیز این است که یک مرحله توسعه بهینه داشته باشید، که در آن حاکمیت داده موضوعی نیست، زیرا هیچ داده مشتری در محیط های توسعه دهنده وجود ندارد. ارائه‌دهنده Cloud باید با نیاز پروژه سازگار می‌شد، نه برعکس.
چرا AWS برای توسعه دهنده؟
دانستن هزینه روزانه یک تیم توسعه در مقایسه با زیرساخت برنامه نویس، باید یک تجربه بهینه توسعه دهنده باشد. ممکن است GCP نیز باشد. اما تجربه من در مورد AWS عمیق‌تر بود و در حال حاضر، از نظر عملکرد تیم توسعه‌دهنده، ارائه‌دهنده Cloud انتخابی من است. ما تفاوت عملکرد قابل توجهی را بین AWS و OVH تجربه می کنیم. ما تصمیم گرفتیم که برای عملکرد تولید خود را خسته نکنیم، زیرا بار تولید در حال حاضر قابل توجه است اما کاملاً منطقی است. و ما هنوز باید با اندازه های مختلف OVH VM به عنوان گره های Kubernetes آزمایش کنیم.
حالا که تیم از چیدمان ما راضی است، در اینجا تفاوت های اصلی وجود دارد.
Terraform را می توان در AWS و OVH برای استقرار کل پشته استفاده کرد. اما، مانند همیشه، پیکربندی Terraform مربوط به ارائه دهنده است. اگر علاقه مند هستید، مانیفست های Terraform ما در پست های وبلاگ، برای AWS و برای معادل OVH به اشتراک گذاشته شده است.
برای جمع بندی تفاوت ها:
- OVH به ارائه دهنده OpenStack Terraform وابسته است، بنابراین باید دسترسی به هر دو ارائه دهنده را پیکربندی کنید.
- OVH سطل های سازگار با S3 را ارائه می دهد، اما از پیکربندی AWS Terraform برای آن استفاده می کند، بنابراین باید این ارائه دهنده را نیز پیکربندی کنید.
- OVH تنها به یک رجیستری Docker برای چندین تصویر نیاز دارد، اما از سوی دیگر و شما یک اقدام دستی برای ایجاد یک فضای “خصوصی” در رجیستری دارید.
- یافتن اسناد AWS در اینترنت آسان‌تر است و تا حد زیادی در Stackoverflow مورد بحث قرار می‌گیرد
- AWS/EKS به طور یکپارچه با رجیستری داکر AWS/ECR در همان پروژه یکپارچه می شود. برای OVH، باید اسرار را با اعتبار در خوشه ایجاد کنید
ما از برخی ابزارهای درون خوشه ای استفاده می کنیم و تفاوت زیادی بین AWS و OVH Kubernetes در این سمت وجود ندارد.
کنترل کننده ورودی
AWS/EKS و OVH به طور کامل از NGINX Ingress Controller پشتیبانی می کنند. از جمله تامین خودکار بار متعادل کننده.
ما تصمیم گرفتیم یک DNS برای محیط‌های توسعه‌دهنده داشته باشیم که توسط AWS مدیریت می‌شود و یک DNS برای محیط‌های مرحله‌بندی/تولیدکننده، که توسط OVH مدیریت می‌شود. بنابراین ما می توانیم به راحتی از یکی از این ارائه دهندگان Cloud انصراف دهیم.
تفاوت ها در رسیدگی به گواهی TLS است. ما از یک گواهی واحد با موارد زیر استفاده می کنیم:
- خاتمه در بار متعادل کننده برای AWS (که به نظر نمی رسد با OVH امکان پذیر باشد)
- پایان کنترل ورودی NGINX برای OVH به عنوان یک بازگشت، با همچنین
– LetsEncrypt با ClusterIssuer که DNS01 را در نقطه پایانی DNS مدیریت شده OVH مدیریت می کند
سرور متریک
Metrics-Server به طور پیش فرض روی OVH نصب می شود و باید به صورت دستی روی خوشه AWS/EKS نصب شود.
مقیاس خودکار
مقیاس خودکار قبلاً در OVH ارائه شده است، اما فعلاً از آن استفاده نمی کنیم. Autoscaler باید به صورت دستی روی خوشه AWS/EKS نصب شود.
پشته الاستیک
Elastic Stack چاقوی ارتش سوئیس ما روی خوشه است. کل Elastic Stack در نسخه 8.5.1 در داخل کلاستر نصب شده است. ما می دانیم که داشتن برنامه های دولتی در Kubernetes توصیه نمی شود، اما در مراحل اولیه تولید خود هستیم.
ما نصب کرده ایم:
- Elasticsearch: داده ها و موتور جستجو
- Kibana: رابط کاربری همه کاره
- Metricbeat: گردآورنده معیارهای Kubernetes (تا جایی که به ما مربوط می شود)
- Filebeat : جمع کننده سیاهههای کانتینرها
- Logstash: ابزار تبدیل داده که برای پلاگین PostGres استفاده می شود و به ما امکان می دهد محتوای پایگاه داده را به خوبی نمایش دهیم.
اکثر آنها بدون هیچ تفاوتی نصب شده اند، به جز مواردی که در زیر توضیح داده شده است.
متریک بیت
Metricbeat معیارهای Kubernetes را جمع آوری می کند. برخی از معیارها از طریق Kubernetes API در یک جمع آوری می شوند گسترش، و دیگران از طریق Kubelet در یک دیمونست (یک گره روی غلاف).
برای اینکه پادهای دیمون ست با گره های مربوطه خود ارتباط برقرار کنند، به طور پیش فرض از آن استفاده می کنند HOST_NAME متغیر. در AWS/EKS مانند یک طلسم عمل می کند. متأسفانه، در خوشه‌های OVH، نام میزبان به IP داخل پادها قابل حل نیست.
راه حل این است که این غلاف های دیمون ست را به شبکه میزبان متصل کنید تا بتوانید از آن استفاده کنید HOSTNAME متغیر.
این برای یک elasticsearch فراخوشه ای، که معماری توصیه شده است، به خوبی کار می کند. اما برای یک elasticsearch درون خوشه ای (بدون ورود)، ما باید به یک سرویس elasticsearch kubernetes تکیه کنیم… که از پادهای شبکه میزبان قابل دسترسی نیست. سپس یک سرویس elasticsearch nodeport برای تکمیل معماری راه حل ایجاد کردیم.
اگر کسی علاقه مند باشد، این بخش را در مقاله دیگری مستند خواهیم کرد.
فایل بیت
Filebeat جمع‌آور و تشریح کننده سیاهههای ظروف ما است.
برای داشتن قابلیت های پیشرفته، Filebeat باید در حالت کشف خودکار استفاده شود. هر دو docker یا kubernetes ارائه دهنده. Docker قبلا یک گزینه بود، اما اکنون، سیستم پیش‌فرض زمان اجرای کانتینر نیست.
پس فقط kubernetes ارائه دهنده باقی می ماند برای شناسایی پادها به API kubernetes متکی است. پیکربندی پیش فرض روی AWS به خوبی کار می کند.
از آنجایی که OVH قدرت API Kubernetes کمتری را ارائه می‌کند (من گمان می‌کنم که OVH تعداد گره‌های اصلی را ثابت کرده و AWS آنها را به صورت خودکار مقیاس‌بندی می‌کند)، پیکربندی پیش‌فرض تمایل دارد آن را پر کند، که منجر به اجرای بسیار کند، حتی گاهی اوقات خرابی کامل می‌شود.
راه حل این بود که برخی از گزینه های پیکربندی را برای کاهش فشار تغییر دهید. الان مثل یه طلسم داره کار میکنه 😊.
اگر کسی علاقه مند باشد، این بخش را در مقاله دیگری مستند خواهیم کرد.
سایر ابزارها: تفاوت قابل توجهی وجود ندارد
ما این ابزارها را دقیقاً به روشی مشابه در هر دو ارائه دهنده نصب کردیم:
چیز زیادی برای گفتن نیست، این زیبایی Kubernetes است: مانیفست ها به همین ترتیب کار می کنند. ما تفاوت‌های برنامه‌نویس/پروید داریم که به ارائه‌دهندگان Cloud مربوط نمی‌شوند، بنابراین در اینجا به جزئیات آنها نمی‌پردازیم.
ما هنوز باید گواهی‌ها را برای رسیدگی در OVH مدیریت کنیم، زیرا خاتمه TLS روی کنترل‌کننده ورودی NGINX است.
در سمت توسعه، تیم با استفاده از S3 در AWS و OVH تفاوت هایی را تجربه کرد. انتظار می رفت، این تنظیم پیش فرض برای هدف قرار دادن OVH نیست. اما پس از اعمال مستندات و انجام تست های OVH، استفاده یکسان است. ما تصمیم گرفتیم فایل‌ها را با استفاده از یک کتابخانه ابری-آگنوستیک رمزگذاری کنیم، بنابراین به یک ویژگی خاص Cloud وابسته نیستیم.
OVH هنوز در حال توسعه برای مطابقت است فناوری بزرگ خدمات. ما در مقایسه با AWS، در این جنبه‌ها تجربه ضعیف‌تری را تجربه می‌کنیم:
- عملکرد گره های اصلی
- عملکرد گره های کارگر
- پشتیبانی فنی رسمی
- پشتیبانی فنی غیر رسمی (حل مشکلات با استفاده از جستجوی اینترنتی)
اما در مقایسه سرمایه‌گذاری‌ها روی این محصولات، این مورد انتظار می‌رود، و این بهایی است که ما حاضریم بپردازیم، تا زمانی که با محدودیت‌ها و تمایل ما برای رفتن به ارائه‌دهندگان جایگزین Cloud مطابقت داشته باشد.
در نتیجه، سرویس‌های Kubernetes مدیریت شده راهی ساده برای استقرار و مدیریت خوشه‌های Kubernetes ارائه می‌دهند. این سرویس ها با حذف پیچیدگی های Kubernetes، توسعه دهندگان را قادر می سازند تا به جای مدیریت زیرساخت، بر برنامه های خود تمرکز کنند. با توانایی استقرار یک برنامه مشابه برای چندین ارائه دهنده ابر با استفاده از یک رویکرد اعلامی، تیم ها می توانند ثبات و کارایی بیشتری را در فرآیندهای استقرار خود به دست آورند. بنابراین، چه از Big Tech استفاده می‌کنید یا نه، OVH می‌تواند ارائه‌دهنده Cloud انتخابی شما باشد اگر با محدودیت‌های شما مطابقت داشته باشد.
آیا تجربه ای در چند ابری Kubernetes دارید؟ لطفاً بینش خود را به اشتراک بگذارید، به خصوص اگر از ارائه دهندگان دیگری برای همان شرایط استفاده می کردید!
تصاویر تولید شده به صورت محلی توسط DiffusionBee با استفاده از مدل ToonYou
