لینک کوتاه مطلب : https://hsgar.com/?p=3352

هنوز از Kubernetes استفاده نکنید

استارت‌آپ‌های در مراحل اولیه هنوز نباید روی Kubernetes اجرا شوند.

اما در نهایت، مرحله رشد و شرکت های بزرگ باید به شکلی در Kubernetes اجرا شود. ماکسیمالیسم Kubernetes به معنای یک اندازه مناسب نیست.

زیرساخت باید به تدریج با حجم کاری و تیم شما رشد کند. چگونه می توانید فناوری مناسب را انتخاب کنید اکنون تا بتوانید رشد را به حداکثر برسانید و درد را به حداقل برسانید بعد زمانی که شما به ناچار از آن بیشتر می شوید؟

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

  • Code-to-Container-to-Deploy (AWS App Runner، Google App Engine)
  • زمان اجرای کانتینر بدون سرور (Fargate در ECS، Google Cloud Run)
  • Kubernetes مدیریت شده ({A,E,G}-KS)
  • Kubernetes خود میزبان

راهنمای انتخاب انتزاع‌های کانتینری مناسب که توسط تیم‌های مهندسی که مهندسین 1e0، 1e1، 1e2 و 1e3+ هستند، تفکیک شده‌اند.

1e0 ≤ team_size ≤ 1e1

بیایید مثال a را در نظر بگیریم تیم کوچک. توسعه‌دهندگان ممکن است تجربه‌ای از DevOps داشته باشند، اما همه در اصل یک SRE هستند. ممکن است یک خط لوله ساده CI/CD وجود داشته باشد اما تمرکز محدودی بر تکرارپذیری یا محیط‌های دارای شکاف هوا باشد. با توابع بدون سرور و معماری‌های رویداد محور می‌توانید جلوتر بروید، اما احتمالاً در برخی مواقع به یک دیمون طولانی‌مدت نیاز خواهید داشت.

من در مورد گزینه های همه کاره مانند AWS App Runner یا هر سرویسی که قول می دهد کد به کانتینر به کانتینر استقرار یابد، مراقب باشم. برای هر تیمی که چیزی غیر از یک وب سرویس ساده بسازد، با این سرویس ها به سرعت به دیواری برخورد خواهید کرد.

مواظب سادگی باشید که بهینه سازی بیش از حد مبتنی بر نظر است – بهینه سازی شکننده است.

توصیه من برای این تیم: با زمان اجرا کانتینر بدون سرور شروع کنید. در AWS، Fargate در ECS یا در Google Cloud، Google Cloud Run خواهد بود.

  • استقرارها شبیه یک نسخه ساده شده از آنچه در Kubernetes استقرار خواهید داشت.
  • هنگامی که به مقیاس کمی بیشتر برسید، روشن کردن مقیاس خودکار اولیه به اندازه کافی آسان است.
  • شما نیازی به مدیریت سرورها، پوشش های شبکه، ورود به سیستم یا سایر میان افزارهای ضروری ندارید.

نقاط ضعف این است که شما باید تصاویر کانتینر را بسازید و آپلود کنید. در حالی که بسیاری از سرویس های سطح بالاتر کد شما را بسته بندی کرده و به یک ظرف تبدیل می کنند، من استفاده از آنها را پیشنهاد نمی کنم. هنگامی که به صخره پیکربندی برخورد کردید (مثلاً، نیاز به تغییر چیزی که سازنده انتزاع می‌کند)، همه پیچیدگی‌هایی را که فکر می‌کردید از آن اجتناب کرده‌اید، به یکباره بر عهده می‌گیرید.

در تجربه من، در صورت استفاده از UI، کار با این سرویس ها می تواند دشوار باشد. من پیشنهاد می کنم آنها را به صورت کد با چیزی مانند Pulumi یا AWS CDK تهیه کنید.

شما نیازی به خط لوله CI/CD کاملاً پخته ندارید. ایجاد و استقرار کانتینرها به صورت محلی یا با یک اسکریپت ساده در اقدامات GitHub مشکلی ندارد. در طیف تکرارپذیری فقط به ضمانت های ضعیف نیاز دارید. تصاویر Docker در حالی که قابل تکرار نیستند و تعداد زیادی تفنگ پا دارند، برای تیم های کوچک به اندازه کافی خوب هستند.

1e1 ≤ team_size ≤ 1e2

پیشنهاد می‌کنم تیم‌هایی که Kubernetes (حتی نسخه‌های مدیریت‌شده) را اتخاذ می‌کنند، یک تیم SRE یا حداقل یک مهندس SRE اختصاصی داشته باشند.

دلایلی که ممکن است از زمان اجرای کانتینر بدون سرور بیشتر شوید

  • نیاز به منابع غیر استاندارد داشته باشید. ذخیره سازی، شبکه و پیکربندی ماشین در زمان اجرا بدون سرور محدود است. اگر نیازمندی‌های خاص (رم بالا، CPU کم) یا فضای ذخیره‌سازی IOP بالا دارید، ممکن است از یک پیشنهاد مدیریت‌شده Kubernetes استفاده کنید.
  • بارهای کاری Stateful که به اپراتور نیاز دارند. ایجاد بارهای کاری Stateful در زمان های اجرا بدون سرور دشوار است، زیرا گزینه های ذخیره سازی محدود هستند. ممکن است به انتزاعات اضافی در شبکه (مانند کشف سرویس یا همتاسازی) نیاز داشته باشید که با زمان های اجرا بدون سرور سخت تر باشند.
  • مدیریت ترتیب بزرگی خدمات. اجرای چند سرویس در Fargate در ECS یا Cloud Run به این معنی است که به راحتی می توانید با یک اسکریپت یا مداخله دستی از رویدادهای خودکار اما نادر مراقبت کنید. داشتن صدها سرویس زودگذر که به گواهی‌های TLS و DNS خارجی نیاز دارند به این معنی است که شاید GKE یا EKS گزینه بهتری به عنوان مبنایی برای اتوماسیون باشد.

نکته ای که در مورد ابزارسازی Kubernetes وجود دارد این است که: (1) API های زیادی برای ایجاد وجود دارد، (2) که منجر به انفجار کامبرین از ابزارهایی می شود که (3) همه آنها مفید نیستند.

1e2 ≤ team_size ≤ ??

ممکن است تیم‌های مهندسی بزرگ بخواهند Kubernetes را بر روی فلز خالی یا ابر اجرا کنند.

احتمالاً به یک دستگاه اختصاصی نیاز خواهید داشت 1e2 اگر این مسیر را دنبال می کنید، تیم DevOps. یا ممکن است شرکتی باشید که Kubernetes را به نحوی در معرض دید مشتریان خود قرار می دهد (به عنوان مثال، یک سرویس پلت فرم یا ارائه دهنده IaaS-مانند).

برخی از دلایلی که ممکن است بخواهید خودتان Kubernetes را اجرا کنید.

  • هزینه: استفاده از سخت‌افزار پیش‌فرض یا قدیمی، سخت‌افزار تخصصی برای برنامه‌های خاص (مانند GPU فشرده)
  • عملکرد: برنامه هایی که در آنها عملکرد فلز لخت حیاتی است (مانند FPGA، GPU و غیره)
  • محیط غیر ابری: اجرای Kubernetes در لبه، مانند فروشگاه های خرده فروشی (به عنوان مثال، فیله مرغ)

توصیه من: مراقب پلتفرم‌های داخلی و انتزاعی‌هایی که بر روی Kubernetes می‌سازید، باشید. حتی بهترین زیرساخت‌های دانه‌های برف نیز در نهایت از عدم صرفه‌جویی در مقیاس رنج می‌برند (به «عدم‌اقتصاد مقیاس در Google» مراجعه کنید. شما نباید چرخه های مهندسی را در رقابت با یا بازآفرینی محصولاتی که قبلاً توسط hyperscalers ابر ارائه شده اند، تلف کنید.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.