Gestionarea clusterelor Kubernetes cu ajutorul LLM-urilor – Experiența VibeCoding Cognizant

Bogdan Marcu
DevOps Engineer @ Cognizant

VibeCoding este un eveniment global organizat de Cognizant, dedicat explorării și adoptării programării asistate de inteligență artificială. În cadrul acestei săptămâni tematice, mii de angajați din întreaga lume participă la workshopuri, hackathoane și sesiuni interactive, având ocazia să experimenteze cele mai noi tehnologii AI și să colaboreze la dezvoltarea de soluții inovatoare. Scopul principal al VibeCoding este de a accelera transformarea digitală și de a stimula creativitatea prin utilizarea instrumentelor moderne de generare de cod și automatizare.

În cadrul evenimentului VibeCoding 2025 am dezvoltat un proiect care demonstrează integrarea LLM-urilor cu infrastructura de Kubernetes prin utilizarea protocolului de standardizare MCP. Proiectul dorește să analizeze tranziția rolului dezvoltatorului către cel de supervizor al codului generat de AI și integrarea unei metode simplificate, bazată pe limbaj natural, pentru controlul clusterelor Kubernetes, folosind un stack modern ce include ReactJS, Java SpringBoot și LLM-ul Llama2.

În contextul global al creșterii influenței pe care AI-ul o are în viața noastră de zi cu zi dar și în domeniul IT, în speță modelele de tipul LLM, se pare că trecem printr-o serie de schimbări într-un ritm foarte alert. O dată la câteva luni apare un nou tool sau IDE cu agenți AI integrați pentru a genera cod. În ultimii doi ani am trecut de la a petrece câteva ore pe un research pe forumuri, de genul StackOverflow, la a găsi răspunsul la întrebare doar prin câteva prompturi pe un tool de AI.

Această accelerare în procesul de creare de software a produs o schimbare în modul în care un developer își desfășoară activitatea. De la a petrece timp scriind cod s-a făcut o tranziție la delegarea acestei responsabilități către AI, iar developerul a devenit un supervizor al agentului având responsabilitatea de decide dacă acel cod generat este de calitate, sigur și se potrivește cu problema pe care dorește să o rezolve.

Acest fenomen în comunitatea noastră a devenit cunoscut ca VibeCoding, iar, pentru moment, pare că acesta este modul cel mai eficient de a livra software.

Pentru compania noastră să rămânem mereu up-to-date și să folosim cele mai noi metode este un lucru esențial. În luna august 2025 a fost organizat un hackathon la nivelul întregii companii, iar scopul a fost să dăm frâu liber imaginației și creativității și să vibe-codăm ce idei avem în cap. La acest hackathon au participat peste 50,000 de colegi din întreaga lume. Anvergura acestui maraton Cognizant a fost premiată cu un record mondial, doborând recordul precedent pentru "Most participants in a generative AI hackathon".

Așadar, am decis că pentru mine este oportunitatea perfectă de a mă juca cu cele mai fierbinți subiecte din această vară și anume MCP servers.

MCP vine de la Model Context Protocol, fiind un protocol dezvoltat de Anthropic care a atacat unul dintre cele mai mari dezavantaje ale unui model de tip LLM și anume incapacitatea de a lucra cu date pe care nu a fost antrenat sau cu date în timp real.

Filozofia unui MCP sever se bazează pe transformarea unui simplu Chat LLM într-un agent care, prin definirea unor metode, reușește să își extindă contextul de date prin faptul ca poate interacționeze cu servicii de email, cu sistemul de fișiere al mașinii gazdă sau alte API-uri externe.

La nivel tehnic, un sistem bazat pe MCP este format din trei componente esențiale: serverul de MCP care găzduiește și execută metodele implementate, clientul pentru acest MCP și LLM-ul care este creierul care are puterea de a decide ce metodă să apeleze pentru a duce la bun sfârșit operațiunea cerută de utilizator.

Cu aceste aspecte în minte am decis ca aplicația mea pentru acest vibe-coding hackathon să fie un chat pentru controlul unui cluster de Kubernetes, scopul final fiind să ofere utilizatorilor de kubernetes o metodă mult mai simplă de a interacționa cu API-ul lui decât prin CLI. Pentru toolurile de generare de cod am avut de ales intre GitHub Copilot, Windsurf, Cursor, sau Lovable. Pentru proiectul meu, am mers mai departe și am ales GitHub Copilot, trecând mai departe la planificarea cerințelor pentru sistem.

Am decis ca pentru stadiul de POC totul să fie găzduit local. Tehnologiile folosite pentru Kubernetes au fost: MiniKube și Ollama cu modelul Llama2. Pentru partea de development, am decis ca acel client web să fie scris în ReactJs, iar partea de backend și MCP server să fie scrisă în Java SpringBoot.

Figura 1 - Componentele și fluxul de date

Capabilitățile serverului MCP pentru Kubernetes ar trebui să poată lista podurile care rulează în diferite namespace-uri, servicii, deploymenturi, să extragă logurile dintr-un pod și să creeze sau să șteargă un deployment sau serviciu.

Fluxul de date începe cu utilizatorul, care, pintr-un chat web, cere MCP serverului să execute o acțiune Kubernetes prin limbaj natural. Această cerere se face prin clientul web, care servește ca interfață a agentului. Clientul web transmite cererea către LLM pentru a afla ce intenționează utilizatorul să execute.

LLM-ul, cel cu puterea de decizie, procesează textul în limbaj natural pentru a determina dorința utilizatorului pentru acțiunea de kubernetes. Pe baza setului de metode pe care le cunoaște, LLM-ul selectează operațiunea necesară și generează un răspuns care, la rândul lui, este transformat într-un MCP Request, pasându-l mai departe controllerului MCP serverului.

Controllerul MCP primește cererea și o direcționează către Kubernetes Service. Acest serviciu interacționează cu Kubernetes Minikube, pentru a executa comanda dorită. După execuție, răspunsul în format JSON este transmis înapoi la Controller sub forma unui MCP Response. Acest răspuns este apoi returnat către WebClient. Fluxul se încheie când clientul web trimite MCP Response-ul înapoi la LLM pentru a fi sumarizat în limbaj natural, iar rezultatul final este afișat utilizatorului.

Fluxul de date pe care aplicația îl realizează este ilustrat în figura de componente.

Odată cu finalizarea pasului de planificare am trecut la partea de set-up și de implementare. Set-upul sistemului s-a folosit de servirea API-ului specific ollama și de instalarea MiniKube local. Pentru partea de implementare am creat primul prompt care să fie pasat agentului de GitHub Copilot pentru generarea de cod.

"I need to create a MCP applciation to query Kubernetes minikube locally, the applciation should have a frontend chat in ReactJS which interacts with a local OllamaAPI for the LLM part and passes it later to java sprginboot MCP server, the mcp should be able to perform the following opperations on the kubernetes side: list the namespaces, list the pods by namespace, list de deployments, list the services, extract the logs from pod."

Iar după cincisprezece minute de vibe-codat și mici schimbări am avut prima iterație a aplicației aproape funcțională.

Un prim aspect din implementarea agentului care nu este pe placul meu a fost că aceasta răspundea cererilor utilizatorului prin JSON în loc de limbaj natural. Așadar, scopul următorului prompt a fost să repare această problemă.

Agentul AI a implementat următoarea funcție summarizeResultWithLLM(operation, result, originalMessage) care are rolul de a prelua răspunsul JSON și de a îl converti în limbaj natural.

O parte interesantă a implementării abordate de către agentul AI a fost partea de system prompt pasată către Ollama API, pentru a ajuta modelul să ofere un răspuns mai precis dorințelor noastre.

`You are a Kubernetes command interpreter assistant. Analyze the user’s natural language input and determine the appropriate action.

Available Kubernetes operations (MCP methods):
1. list_pods - List all pods in a namespace
   Examples: “show pods”, “what pods are running”, “list all pods”

2. list_services - List all services in a namespace  
   Examples: “show services”, “what services exist”, “list services”

3. list_deployments - List all deployments in a namespace
   Examples: “show deployments”, “what apps are running”, “list deployments”

4. list_namespaces - List all namespaces
   Examples: “show namespaces”, “what namespaces exist”`

If it’s not a Kubernetes operation, use method: “chat”
Always include “namespace”: “default” unless user specifies otherwise.
Try to extract specific names from the user input for pod/deployment/service names.

User input: “${message}”`

ori

`You are a helpful Kubernetes assistant. The user asked: “${originalMessage}”

I executed the Kubernetes operation “${operation}” and got this result:
${JSON.stringify(result, null, 2)}

Please provide a clear, friendly summary of the results in natural language. Make it conversational and helpful. Focus on:
- What was found or accomplished
- Key information the user would care about
- Any notable status or issues
- Use emojis to make it friendly

If it’s a list operation, summarize the count and key details.
If it’s a creation operation, confirm what was created.
If it’s a deletion operation, confirm what was removed.
If there are errors, explain them clearly.

Keep the response concise but informative. Don’t include the raw JSON.

Acest concept de "system prompt" a fost folosit pentru fiecare apel către Ollama și LLM-ul nostru.

Odată cu finalizarea aspectelor funcționale, am mai apelat de câteva ori la agentul AI pentru a înfrumuseța aspectul clientului web, ajungând astfel la varianta finală.

Per total, experiența de vibe coding este una utilă în dezvoltarea anumitor prototipuri. Cu toate acestea, există și câteva dezavantaje atunci când începem să vorbim despre probleme mai complexe. Pe măsură ce proiectul avansează și devine tot mai mare, agentului este tot mai greu să înțeleagă inter-dependințele respective mai ales dacă vorbim despre o aplicație bazată pe micro servicii. Încă un dezavantaj pe care l-am remarcat a fost introducerea unor probleme în timpul stilizării paginii care au stricat complet fluxul, iar nesalvând un checkpoint cu un git commit a trebuit să intervin manual pentru a repara greșelile agentului. Un ultim dezavantaj pe care l-am remarcat este legat de aspectele de securitate : agentul nu doar că nu a inclus niciun procedeu privind autentificarea sau securitatea, ci a marcat CORS în backend ca wildcard, un lucru foarte nesigur. Ar fi fost foarte util ca acest aspect să fie luat în calcul de către agent.

În concluzie, vibe codingul poate fi un adevărat companion pentru proiecte la scară mică, într-un mediu de tip sandbox, facilitând o dezvoltare rapidă și o demonstrare eficientă a unor premise inițiale. Pentru un proiect care urmărește să ajungă într-un mediu de producție, unde toleranța la riscuri este zero, rolul acestor agenți ar fi mai degrabă acela de extensie a cunoștințelor dezvoltatorului, oferind suport în procesul de prototipare, analiză de cod sau optimizare a fluxului de lucru. Totuși, deciziile esențiale și implementările finale ar trebui să rămână în responsabilitatea echipei umane, pentru a asigura controlul calității și securității. Pe termen lung, integrarea acestor agenți în procesul de dezvoltare poate duce la o colaborare om-AI mai eficientă, în care inteligența artificială preia sarcinile repetitive, iar dezvoltatorii se pot concentra pe arhitectură, strategie și inovație.