آیا کبرنتیز روزی ساده‌تر خواهد شد؟

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

Kubernetes به‌ندرت به معرفی نیاز دارد. پس از لینوکس، این دومین پروژه با بیشترین شتاب منبع باز در جهان است. در طول سال‌ها، هزاران شرکت به این پلتفرم کمک کرده‌اند. در قلب اکوسیستم پررونق ابری‑بومی، Kubernetes به‌عنوان یک پلتفرم همه چیز تبدیل شده است، بنیان برای همه چیز از خطوط لوله CI/CD، تا خوشه‌های آموزش یادگیری ماشین، تا پایگاه‌های داده توزیع‌شده با مقیاس سیاره‌ای.

Kubernetes که به‌تازگی سالگرد ۱۰ سالگی خود را جشن گرفته است، بیش از پیش انعطاف‌پذیر است. اکنون به‌صورت پیش‌فرض بسیاری از نوع‌های بارکاری را پشتیبانی می‌کند — بارکاری‌های بی‌وضعیت، وضعیت‌دار و پردازش داده، کارهای دسته‌ای خودکار، بارکاری‌های مقیاس‌پذیری خودکار بر پایه رویداد، و موارد دیگر. تعاریف سفارشی منابع و اپراتورها اکنون به‌سرعت ویژگی‌های اضافی مانند قابلیت مشاهده، شبکه‌بندی، پشتیبان‌گیری و بازیابی، و مدیریت سیاست‌ها را ارائه می‌دهند.

جامعه ابزارهایی را برای حل بسیاری از موانع ایجاد کرده است، مانند مدیریت چند خوشه‌ای، انتقال ماشین‌های مجازی ارثی، استقرار در لبه یا محیط‌های سخت‌افزار خالص، و استفاده از Kubernetes برای توسعه هوش مصنوعی — که به رفع نیازهای روزافزون کمک می‌کند، در حالی که برای پروژه‌های جدید در ‌منظرهٔ ابری‑بومی نمادهای جذابی می‌آفریند.

تمام این پیشرفت‌های راحت‌زا، Kubernetes را در مرکز آیندهٔ زیرساخت‌های ابر سازمانی قرار داده است. بنیاد محاسبات ابری بومی (CNCF) می‌گوید ۸۴٪ از سازمان‌ها یا از Kubernetes در تولید استفاده می‌کنند یا در حال ارزیابی آن هستند، طبق نظرسنجی سالانهٔ CNCF ۲۰۲۳. اما، هنگامی که Kubernetes عملکردهای بیشتری اضافه می‌کند و بارکاری‌های بیشتری را در بر می‌گیرد، آیا استفاده از آن آسان‌تر می‌شود؟

پیشرفت‌های چشمگیر

«Kubernetes به‌طور قطع آسان‌تر و پایدارتر شده است»، می‌گوید مورلی تروماله، مدیر عمومی Portworx، واحد کسب‌وکار ابری‑بومی Pure Storage. او این را به این دلیل می‌داند که Kubernetes در «جنگ‌های زمان‌بندی‌کنندهٔ کانتینرها» در دههٔ ۲۰۱۰، که Kubernetes را در برابر Docker Swarm، Apache Mesos، HashiCorp Nomad و دیگران قرار داد، پیروزی یافت. پس از رسیدن به اجماع، صنعت برای بهبود استقرار پایه و ساختن راه‌حل‌ها روی آن هماهنگ شد، که منجر به توزیع پایدارتر و تجمیع فروشندگان برای عملکردهای اصلی شد.

امروزه‌ها، هایپر‌اسکالرها توزیع‌های مدیریت‌شدهٔ Kubernetes را ارائه می‌دهند، مانند Amazon Elastic Kubernetes Service (Amazon EKS)، Azure Kubernetes Service (AKS) و Google Kubernetes Engine (GKE). این‌ها، همراه با گزینه‌های فراوان، گزینه‌های مبتنی بر رابط کاربری گرافیکی برای مدیریت خوشه‌ها را فراهم می‌کنند.

در نتیجه، ۸۴٪ از سازمان‌ها از Kubernetes خود‌ میزبانی‌شده به سمت سرویس‌های مدیریت‌شده حرکت می‌کنند، طبق نظرسنجی وضعیت Kubernetes ۲۰۲۳. اما این به این معنی نیست که نوآوری به هر شکل متوقف شده است.

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

ابزارهای متمرکز بر سازمان نیز حوزه‌های پیرامونی را پوشش می‌دهند، استفاده از آنها برای پشتیبان‌گیری و بازیابی پس از حادثه را آسان می‌کند. «گزینه دیگر این است که خودتان اسکریپت‌نویسی کنید با قطعه‌های متعدد منبع باز و آن‌ها را به‑هم بزنید»، می‌گوید گاور ریشی، معاون رئیس محصول و مشارکت‌های ابری‑بومی در Kasten by Veeam. «امور خیلی آسان‌تر شده‌اند، از جمله امنیت. حتی پنج سال پیش، سازمان‌ها خوشحال نبودند که خوشه‌ها را به‌عنوان محصول ارائه دهند زیرا امنیت یک نگرانی بود»، او می‌افزاید.

Kubernetes با یک API REST قوی آغاز شد که اجازه می‌داد تمام منابع با فراخوانی به اشیای API مدیریت شوند. در طول یک دهه، ما شاهد هم‌راستایی چشمگیر در صنعت ابری‑بومی بودیم و جامعهٔ پیرامون به‌طور قابل توجهی بالغ شد. به‌عنوان مثال، CNCF گواهینامه برای بیش از ۱۰۰ توزیع و نصب‌کنندهٔ Kubernetes از فروشندگان ارائه می‌دهد تا اطمینان حاصل شود که واقعاً با APIهای مورد انتظار هم‌خوانی دارند.

پیچیدگی رو به افزایش

با این حال، نکات مشکل‌زا همچنان باقی مانده‌اند. ۷۵٪ از کاربران Kubernetes با مسائلی مواجه می‌شوند که اجرای خوشه‌هایشان را تحت‌ تاثیر قرار می‌دهد، که نسبت به ۶۶٪ در سال ۲۰۲۲، طبق گزارش «وضعیت تولید Kubernetes ۲۰۲۳» از Spectro Cloud است. معمول است که ۱۰ یا بیشتر خوشه داشته باشید و بخشی از توسعه‌دهندگان (۳۳٪) مجبور شوند کارهای پلتفرمی انجام دهند.

بسیاری از کاربران می‌گویند که انتزاع بیشتر لازم است، زیرا هنوز هدر زیاد برای راه‌اندازی Kubernetes وجود دارد، از تأمین منابع تا پیکربندی امنیت، اتصال به مانیتورینگ و غیره. اگرچه پیشرفت‌هایی برای کسب‌وکارهای کوچک‑متوسط صورت گرفته، Kubernetes هنوز برای پروژه‌ها و شرکت‌های کوچک که فاقد مهارت‌ها و منابع هستند، گاهی بیش از حد بزرگ می‌شود. جالب است که یک نظرسنجی ۲۰۲۲ از D2iQ نشان داد تنها ۴۲٪ از برنامه‌های اجرا شده بر روی Kubernetes در واقع به تولید می‌رسند.

«امروز شروع کار با Kubernetes ساده‌تر است»، می‌گوید ایتل شوارتز، هم‌بنیان‌گذار و CTO Komodor. «اکنون یک نوع ابر خود است و انتظار می‌رود سرویس‌هایی مانند پایگاه داده، ارائه‌دهنده گواهینامه و لودر بار همه زیر Kubernetes اجرا شوند. تولید در مقیاس بزرگ‌تر پیچیده‌تر شده است.»

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

جایی که کاربران به مشکلات برمی‌خورند

کاربران Kubernetes اغلب در چند حوزه با مشکلاتی روبه‌رو می‌شوند. یک مانع ساده همان تعداد وسیع ابزارهای موجود است. منظرهٔ ابری‑بومی CNCF اکنون ۲۰۹ پروژه با ۸۸۹ مخزن کل دارد که می‌تواند منجر به تجزیه و تحلیل بی‌پایان شود.

در حالی که ابزارهایی مانند Helm و Argo CD مدیریت افزونه‌ها را ساده می‌کنند، هر ابزار نیازهای پیکربندی منحصر به‌فردی دارد که می‌تواند اصطکاک ایجاد کند، می‌گوید شوارتز از Komodor. «افزونه‌ها در محیط‌های Kubernetes به‌طور نامنظمی دشوار برای مدیریت هستند، زیرا لایه‌های پیچیدگی را اضافه می‌کنند و نیاز به تخصص‌های متنوع دارند.»

همه ابزارهای ابری‑بومی برابر نیستند، می‌افزاید تروماله از Portworx. او می‌بیند این موضوع برخی سازمان‌ها را به سمت انتخاب فروشندگان بزرگ و معتبر به‌جای نوآوران کوچک‌تر سوق می‌دهد، به‌ویژه در حوزه‌های پرریسک مانند هوش مصنوعی یا مجازی‌سازی که هزینهٔ شکست بالا است.

«Kubernetes تنها ۱۰ سال دارد»، می‌گوید ریشی. نوآوری فراوانی وجود دارد، اما او تأیید می‌کند که اکوسیستم پیچیده می‌تواند برای درک دشوار باشد. علاوه بر این، خطرات امنیتی که هنوز بر کانتینرها سایه انداخته‌اند و بسیاری از سازمان‌ها برای مطابقت با الزامات امنیتی سخت‌گیرانه باید موانع متعددی را پشت سر بگذارند.

به عنوان مثال، این می‌تواند شامل سخت‌سازی پردازش داده‌ها با الگوریتم‌های مناسب برای برآورده کردن استانداردهای پردازش اطلاعات فدرال (FIPS) یا اتخاذ روش‌های اسکن مداوم کانتینر برای برآورده کردن نیازهای اسکن آسیب‌پذیری FedRAMP برای کانتینرها. «از یک سو، بردارهای تهدید در حال افزایش هستند، اما از سوی دیگر اکوسیستم رشد کرده است»، می‌گوید ریشی از Kasten.

مشکلات رایج دیگر شامل تنظیم پروب‌ها برای بررسی سلامت برنامه‌ها، تعیین درخواست‌ها و محدودیت‌های صحیح، و پیکربندی سیاست‌های شبکه است. «پیکربندی نامناسب محدودیت‌های منابع می‌تواند منجر به اخراج پادها، بارکاری نامتعادل و شکست‌های ناخواستهٔ برنامه‌ها شود»، می‌گوید شوارتز.

یک دیگر، کمبود دانش گسترده دربارهٔ نحوهٔ استفاده از Kubernetes است، می‌گوید اسچپانیاک از Percona. در حالی که ماشین‌های مجازی بیش از دو دهه وجود دارند، Kubernetes هنوز در ذهن سازمان‌ها جایگاهی پیدا نکرده است. «من با تیم‌های DevOps زیادی صحبت کرده‌ام که به‌محض معرفی فناوری جدید، اگر نیاز به دانش Kubernetes در سازمان داشته باشد، مقاومت فوری می‌بینند.»

کار با بارکاری‌های ارثی

در همین زمان، مقاومت تیم‌های DevOps در برابر Kubernetes سخت‌تر می‌شود. به عنوان «سیستم‌عامل ابر» توصیف می‌شود، Kubernetes هم‌اکنون به‌منظور سقوط‌های فراوانی فراتر از زمان‌بندی‌کنندهٔ کانتینر خدمت می‌کند. دامنهٔ آن اکنون شامل شبکه و ذخیره‌سازی از طریق افزونه‌های CNI و CSI است. «از طریق این توسعه‌ها، Kubernetes تبدیل به یک کنترل‌پلان چند ابری برای زیرساخت شد»، می‌گوید تروماله.

Kubernetes برای مدیریت انواع بارکاری‌های قدیمی نیز استفاده می‌شود. ابزار نوظهور KubeVirt می‌تواند ماشین‌های مجازی (VM) را زمان‌بندی کند که اغلب برنامه‌های حیاتی ارثی را پشتیبانی می‌کنند. «این گامی بزرگ برای Kubernetes است»، می‌گوید تروماله که معتقد است Kubernetes موقعیت بهتری برای ورود به برنامه‌های موجود در حوزه‌های تراکنش‌های حجیم مانند خودروسازی، بانک‌ها و صنایع قدیمی پیدا کرده است.

دیگران نیز حمایت از مجازی‌سازی مدرن را به‌عنوان یک تحول مهم می‌دانند. «قبلاً دو مسیر متفاوت بود: ماشین‌های مجازی در طرف ارثی در مقابل بارکاری‌های ابری‑بومی Kubernetes»، می‌افزاید ریشی. «امروز می‌توانید بهترین‌های Kubernetes را در عملیات و توسعه همراه با سرعت بیشتر، حتی با ماشین‌های مجازی، داشته باشید.»

اعطای دسترسی به زیرساخت‌های ابری‑بومی برای بارکاری‌های ارثی نه تنها برای مدرن‌سازی استک‌های ارثی سازمانی جذاب است، بلکه برای اجتناب از افزایش هزینه‌ها به‌دلیل یکپارچه‌سازی پیشنهادات VMware توسط Broadcom نیز مهم است.

با این حال، بارکاری‌های ارثی نیازهای متفاوتی حول مهاجرت داده، پشتیبان‌گیری، بازیابی پس از حادثه و تأمین دسترسی ایمن دارند، می‌گوید تروماله. «ما عملکردهای جدیدی به مدیریت داده‌های Kubernetes اضافه می‌کنیم که برای کانتینرها لازم نبود ولی برای ماشین‌های مجازی ضروری است»، او می‌گوید. طبیعتاً پشتیبانی از این موارد استفادهٔ اضافی، پیچیدگی بیشتری برای کاربران به‌وجود می‌آورد.

پشتیبانی از بارکاری‌های هوش مصنوعی

یک حوزه دیگر که Kubernetes و قابلیت استفاده بهتر را می‌طلبد، توسعه هوش مصنوعی است. هوش مصنوعی به‌طرز طبیعی قابل کانتینره شدن است، می‌گوید تروماله، که Kubernetes را برای آموزش مدل‌ها و استنتاج مناسب می‌داند. «هوش مصنوعی و Kubernetes تقریباً ۹۰٪ هم‌پوشانی دارند»، او می‌گوید. «به‌طریق طبیعتی، هوش مصنوعی زیرساخت کشسانی می‌طلبد.»

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

«بارکاری‌های یادگیری ماشین باید در مکان‌های مختلف مستقر شوند، منابع دریافت کنند و بسیار کشسان باشند»، می‌گوید چیس کریستینسن، مهندس راه‌حل‌های TileDB. اگرچه Kubernetes پایهٔ محکمی برای هوش مصنوعی است، استفاده از آن به‌تنهایی برای این هدف به استقرار سرویس‌های اد‑هاک، ساخت اپراتورهای ویژه، ایجاد خط لوله و مدیریت الزامات زمان‌بندی خاص نیاز دارد. به عنوان مثال، کارهای طولانی‌مدت می‌توانند شبانه‌روزی شکست بخورند و بدون مکانیزم‌های بازآغاز یا استقامت داخلی، جریان کار را پیچیده می‌کند، می‌گوید کریستینسن.

Kubeflow، یک پروژهٔ در حال پرورش CNCF، این چالش‌ها را با آسان‌سازی استقرار و مدیریت مدل‌های یادگیری ماشین بر روی Kubernetes حل می‌کند. سازمان‌هایی مانند CERN، Red Hat و Apple از Kubeflow استفاده و به آن مشارکت می‌کنند تا اکوسیستمی برای آموزش مدل‌های هوش مصنوعی فراهم کنند که به‌طور یکپارچه با معماری ابری‑بومی ترکیب می‌شود.

زمانی که با Kserve برای استنتاج هوش مصنوعی بدون وابستگی به چارچوب ترکیب می‌شود، Kubeflow می‌تواند جریان کار دانشمندان داده را ساده کند. «این ابزارها هوش مصنوعی را بسیار آسان می‌کنند چون زیرساخت را انتزاع می‌کنند»، می‌گوید کریستینسون. «این تجربهٔ کاربری ایجاد مدل‌ها را بهبود می‌بخشد و نتایج تجاری را سرعت می‌بخشد.»

استنتاج هوش مصنوعی در لبه احتمالاً برای موارد خاص رایج می‌شود. با این حال، استقرارهای ابری‑کانتینری ادامه خواهند یافت و نیاز به لایهٔ کنترلی مشترک وجود دارد. «می‌خواهید بتوانید خوشه‌های متعدد را در هر مکانی مدیریت کنید، بدون قفل شدن در یک فروشنده خاص»، می‌گوید ریشی از Kasten.

انتقال Kubernetes به لبه

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

«موارد استفادهٔ Kubernetes در لبه قطاً در حال رشد است»، می‌گوید ریشی. این برای نصب‌های دولتی که نیاز به محیط‌های ایزوله و ایمن دارند یا برای خرده‌فروشی و دستگاه‌های اینترنت اشیا (IoT) با محدودیت پهنای باند یا شبکه جذاب است. به‌عنوان مثال، وزارت دفاع ایالات متحده به‌طور فعال Kubernetes را در مناطقی با صفر اتصال اینترنت، از کشتی‌های جنگی تا هواپیمای اف‑۱۶ مستقر می‌کند.

نسخه‌های سبک Kubernetes برای توزیع‌های لبهٔ سبک ظاهر شده‌اند. ریشی به K3s، توزیع سبک Kubernetes برای محیط‌های محدود، و Bottlerocket، سیستم‌عامل مبتنی بر لینوکس قابل حمل برای اجرای کانتینرها، اشاره می‌کند. ارائه‌دهندگان ابر بزرگ نیز گزینه‌هایی برای استقرارهای کوچک‌تر کانتینری ارائه می‌دهند، از Microshift، جایگزین کم‌حجم برای OpenShift در دستگاه‌های لبه، تا Fargate، محاسبهٔ بدون سرور AWS برای کانتینرها. گزینه‌هایی همچون Amazon Elastic Container Service (Amazon ECS) یا HashiCorp Nomad کاملاً Kubernetes را کنار می‌گذارند برای موارد استفادهٔ ساده‌تر.

«Kubernetes به‌دورانی آسان‌تر می‌شود»، می‌گوید راغو واتِه، CTO میدانی و معاون استراتژی در ZEDEDA. اما در لبه، ممکن است هزاران خوشهٔ کوچک را مدیریت کنید؛ برای این‌کار مکانیزمی متمرکز برای هماهنگی و استقرار کانتینرها با زمان‌اجرای همگنی لازم است. «نمی‌خواهید یک برنامه را فقط به‌دلیل استقرار در لبه بازنویسی کنید.»

لبه همچنین برای حوزه‌هایی مثل بازی یا بارکاری‌های فوق‌خصیص‌پذیر جذاب است که اغلب به تأخیرهای بسیار کم نیاز دارند. اما چگونه سازمان‌ها می‌توانند محاسبه را به‌سوی کاربر نزدیک‌تر کنند در حالی که استانداردهای استقرار در تمام محیط‌ها یک‌دست باقی می‌ماند؟ «دسترس‌پذیری و عدم وجود سرویس‌های مدیریت‌شده، آن قابلیت حمل‌پذیری را فراهم می‌کند»، می‌گوید ویل از Akamai.

برای قابل‌حمل‌کردن بارکاری‌های Kubernetes بین ابرها و مناطق مختلف، ویل توصیه می‌کند از بسته‌بندی‌های «مسیر طلایی» استفاده کنید که سازگاری با Kubernetes به‌صورت متن باز را حفظ می‌کنند و بر پایهٔ پروژه‌های پایدار CNCF مانند OpenTelemetry، Argo، Prometheus یا Flatcar ساخته می‌شوند. این می‌تواند اورکستراسیون بک‑اند را ساده کند، وابستگی به فروشندگان را کاهش دهد و انعطاف‌پذیری برای چند‑ابرا فراهم آورد.

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

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

کاهش مانع ورود به Kubernetes

یک دهه پس از پیدایش، Kubernetes هنوز پیچیده است، حتی با استفاده از سرویس‌های مدیریت‌شده. اما تلاش‌ها برای ساخت انتزاع‌هایی که تجربهٔ توسعه‌دهنده و دسترسی‌پذیری را بهبود می‌بخشد، در جریان است. «ابزارهای Kubernetes در حال پر کردن شکاف مهارتی‌اند با ارائه واسط‌های شهودی و بینش‌های از پیش‌ساخته که مانع ورود را کاهش می‌دهند»، می‌گوید شوارتز از Komodor.

ابزارها نیز در حال تحول برای دسترس‌پذیرتر کردن دید خوشه‌ها هستند، با نصب‌های تک‌مرحله‌ای برای عملکردهای مشاهده‌پذیری. «قبلاً باید کد برنامهٔ خود را به‌طور دستی تکمیل کنید و پیکربندی‌ها را با تغییر منیفست‌ها اضافه می‌کردید»، سیوس از New Relic توضیح می‌دهد. گزینه‌های مشاهده‌پذیری کاربرپسند اکنون به اپراتورها کمک می‌کند تا بهتر سلامت سیستم‌های خود را درک کنند و مشکلات عملکرد یا قابلیت اطمینان را با تلاش کمتر شناسایی نمایند.

هوش مصنوعی و یادگیری ماشین نیز در بهبود تجربهٔ کاربری مدیریت Kubernetes نقش دارند. به عنوان مثال، آندریاس گرا‌بنر، فعال‌گر DevOps در Dynatrace و سفیر CNCF، می‌گوید ابزارهای مبتنی بر هوش مصنوعی مولد مشاهده و تشخیص خوشه‌های Kubernetes را آسان کرده‌اند و با ارائه اطلاعات عملی برای بهینه‌سازی سیستم‌ها، به تجزیه‌وتحلیل ریشه‌ای کمک می‌کنند.

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

تا سال ۲۰۲۵، ۹۵٪ از برنامه‌ها بر روی پلتفرم‌های ابری‑بومی مستقر خواهند شد، طبق برآوردهای گارتنر. اما در حالی که اکوسیستم ابری‑بومی در اوج خود به نظر می‌رسد، هنوز بسیاری از شرکت‌ها به‌سوی کانتینرها قدم نگذاشته‌اند، که نشانگر فضای رشد بیشتری است.

فضای رشد هنوز برای Kubernetes فراوان است؛ نه تنها از نظر پذیرش، بلکه از نظر بستر پایه، ابزارها و افزونه‌ها و موارد استفاده. برای ارکستراسیون کانتینرها در مقیاس وسیع، وارث Borg گوگل به‌نظر می‌رسد الگوی استقرار استاندارد برای انواع بارکاری‌ها خواهد شد. به هر حال، مسابقه بین کاربری و پیچیدگی به‌نظر می‌رسد ادامه یابد.

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