چگونه Kubernetes موفق شد

Kubernetes به عنوان یکی از ابزارهای متعدد برای ارکستراسیون کانتینر شروع شد. ده سال بعد این پلتفرم پیشرو برای برنامه های کاربردی ابری است.

۶ ژوئن، دهمین سالگرد رسمی راه اندازی Kubernetes است. Kubernetes به عنوان یک پلتفرم مدیریت کانتینر و هماهنگ‌سازی ساخته شد که مدیریت همه کانتینرهای نرم‌افزار را در برنامه‌های microservices آسان‌تر می‌کند. بر اساس Borg، مدیریت کانتینر داخلی Google سرویسی که هزاران نمونه را مدیریت می کرد، سرانجام Kubernetes به عنوان منبع باز برای دیگران منتشر شد تا از آن برای اجرای کانتینرها استفاده کنند.

ارزش این را دارد که به سال ۲۰۱۴ فکر کنیم، زمانی که Kubernetes یکی از بسیاری از رویکردهای مختلف برای مدیریت کانتینرهایی بود که در حال راه اندازی بود. پروژه‌های منبع باز بزرگ‌تر مانند Apache Mesos قبلاً وجود داشتند، در حالی که شرکتی که کانتینری‌سازی را آغاز کرد، Docker، گزینه‌ای عالی با Docker Swarm خود ارائه کرد. شرکت‌ها همچنین به رویکردهایی مانند ابزارهای مدیریت AWS ECS و نحوه استفاده از آن‌ها برای مدیریت کانتینر خاص نگاه می‌کردند.

پس چرا Kubernetes برنده شد؟ آیا همیشه این احتمال وجود داشت که به Kubernetes به عنوان پلتفرم برای برنامه‌های ابر بومی برسیم؟ یا موانعی در این راه وجود داشت؟

از حجم کاری بدون تابعیت تا حجم کاری حالت دار

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

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

StatefulSets از شناسه‌های شبکه پایدار و منحصر به فرد و ذخیره‌سازی پایدار و پایدار پشتیبانی می‌کند. همچنین امکان استقرار و مقیاس‌بندی منظم‌تر، زیباتر و به‌روزرسانی‌های خودکار و منظم‌تر را فراهم کرد. علاوه بر این، راه اندازی Kubernetes Operators به ​​توسعه دهندگان این امکان را داد تا پیچیدگی استفاده از Kubernetes primitives را با سایر برنامه ها پنهان کنند. بدون این دو افزوده، اجرای بارهای کاری حالتی در Kubernetes نیاز به هک جدی هسته Kubernetes دارد تا همه چیز کار کند.

علاوه بر این، یک فشار جامعه برای ایجاد بارهای کاری stateful به طور موثر در Kubernetes وجود داشت. در حالی که مکالمات در مورد اجرای پایگاه‌های داده مانند MySQL و PostgreSQL در مانند Reddit و Stack Overflow شروع شد، برای تبدیل این ایده‌ها به پروژه‌های واقعی و پایدار به همکاری رسمی‌تری نیاز بود. سازمان‌هایی مانند انجمن داده‌ها در Kubernetes گرد هم آمدند تا چارچوب مناسبی را برای این همکاری فراهم کنند و شرکت‌ها و افراد را راحت‌تر کنند. مشارکت کنید.

این کار ضروری بود، زیرا برای شروع، فشارهای زیادی در مورد اجرای پایگاه داده در Kubernetes وجود داشت. برای کسانی که با رویکرد ۱۲ عامل در طراحی برنامه‌های کاربردی آشنا هستند، خدمات back-end باید به عنوان منابع پیوست تلقی شوند. در آن زمان، این برای توسعه‌دهندگانی که می‌خواستند در کانتینرها اجرا شوند، اما پس از آن مجبور بودند تعامل با پایگاه‌های داده یا سیستم‌های ذخیره‌سازی را که در محیط‌های مختلف میزبانی می‌شوند، مدیریت کنند، مشکل‌ساز بود. رویکرد ایده‌آل – و چیزی که امروزه داریم – این است که پایگاه‌های داده باید دقیقاً به همان روشی که اجزای برنامه اجرا می‌کنند در خوشه‌ها اجرا شوند، زیرا این امر کنترل و مدیریت زیرساخت در کل سرویس را از یک نقطه آسان‌تر می‌کند.

نقش منبع باز

یکی از دلایل اصلی موفقیت Kubernetes این بود که منبع باز بود. Kubernetes اهدا شد به Cloud Native Computing Foundation تا بتواند توسط یک سازمان بزرگتر پشتیبانی شود. بیش از یک فروشنده کنترل کننده این به گسترش بار از نظر مشارکت و افزایش پذیرش کمک کرد. هنگامی که به نحوه شرط بندی در یک پلتفرم برای رایانش ابری نگاه می کنید، انتخاب یک پلتفرم که به ارائه دهنده ابر خاصی وابسته نیست و می تواند کانتینرها را به طور مستقل روی هر یک از آنها اجرا کند، انتخاب هوشمندانه تری تلقی می شود.

این به جامعه ای نیاز داشت که مایل به حمایت از Kubernetes به عنوان یک پروژه باشد و آنها باید برای موفقیت آن سرمایه گذاری کنند. همانطور که برندان برنز، یکی از خالقان کوبرنتس توضیح داد که برای ایجاد آن جامعه، Kubernetes باید منبع باز باشد. پادکست Dev Interrupted. بدون منبع باز بودن، انگیزه کمتری برای توسعه دهندگان وجود خواهد داشت که کوبرنتیس را به عنوان ابزار مدیریت کانتینر خود انتخاب کنند یا مشارکت کنند.

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

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

Sergey Pronin مدیر محصول گروه در Percona است.

—

انجمن فناوری جدید مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.