KlaudiaAI — ШІ для роботи з Kubernetes. Що в ньому цікавого

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Так як масштабне впровадження Kubernetes — це виклик, що вимагає значних зусиль, а звичні ШІ, такі як ChatGPT чи Gemini не здатні впоратися з подібними задачами, адже вони створені для зовсім інших завдань, компанія Komodor випустила свого ШІ-агента KlaudiaAI, якого спеціально навчали на даних про операційні проблеми Kubernetes.

Чому звичні ШІ не підходять для таких речей

Загалом все дуже просто. Звичайні LLM хоч і вчаться на величезному обсязі даних, але так як їхньою цільовою аудиторією є всі люди, то вони є більш загальними та не підходять для такого вузького профілю, як DevOps.

В такому випадку, на мою думку, було б краще створити більш вузьку модель, яка навчалася б лише на журналах, документаціях, репозиторіях, пов’язаних з цією технологією.

І, як не дивно, людей в світі багато, тому думки мають властивість повторюватися. Саме так і сталося,

Головними плюсами KlaudiaAI є:

Вища точність відповідей завдяки вузькому вектору спеціалізації.
Полегшення масштабування у великих проєктах.
Прискорення усунення несправностей завдяки зниженню кількості так званих «галюцинацій».

Але Komodor не єдині хто до такого додумався. Загалом є досить багато таких рішень, але найпопулярнішими з них є K8sGPT, Robusta та Cast AI.

Також зараз досить часто можна почути як хмарні платформи все більше і більше інтегрують ШІ в свої технології, зокрема як AWS додали Chatbot для діагностики та налаштування ресурсів Kubernetes, або як Google оптимізує Google Kubernetes Engine для AI/ML навантажень.

Реальний кейс використання KlaudiaAI

Уявимо, що сталася помилка Pod`a через пошкоджений ключ у зміненій ConfigMap.

Хоча ConfigMap було належним чином змонтовано, вона містила некоректні дані. Це було неочевидно і вимагало глибокого аналізу для діагностики.

Агент KlaudIA витратив лише кілька секунд на аналіз логів, історичних змін та подій Kubernetes, щоб виявити основну причину.

Він також надав чіткі інструкції для усунення проблеми, включно з прямим посиланням на відповідну ConfigMap.

Неймовірно, правда? Здавалось би, така дрібна проблема, а вирішена за лічені секунди. А Ви як думаєте: чи потрібні DevOps такі інструменти чи це все фікція?