Mașini virtuale, containere sau Kubernetes: câtă infrastructură ne trebuie?

Seria II: De la infrastructură la proiecte agentice în producție. Episodul 02 din 20.

În episodul anterior am decis unde ar putea rula piesele unui portal B2B fictiv pentru solicitări și documente. Următoarea întrebare este cum le împachetăm și administrăm. O mașină virtuală, un container și Kubernetes nu sunt trei mărimi ale aceluiași produs. Ele rezolvă probleme diferite și pot funcționa împreună. Pentru un IMM, decizia principală este ce nivel de separare și automatizare poate susține echipa, la disponibilitatea cerută de afacere.

Ce izolează fiecare opțiune

O mașină virtuală sau VM este un calculator definit prin software, cu propriul sistem de operare. Un hypervisor împarte resursele unui server fizic între mai multe VM-uri. Firma poate separa, de exemplu, aplicația de baza de date și poate administra ori restaura fiecare mediu conform unui plan. Dacă toate VM-urile depind de același server fizic, oprirea acelui server le poate afecta pe toate. Virtualizarea nu creează singură disponibilitate ridicată.

Un container este un proces izolat împreună cu fișierele și bibliotecile de care are nevoie aplicația. Mai multe containere de pe același sistem partajează nucleul sistemului de operare, spre deosebire de VM-uri, care rulează sisteme de operare proprii. O imagine de container este pachetul din care pornește procesul. Ea ajută la reproducerea mediului între dezvoltare și producție, dar nu include automat datele persistente, copiile de siguranță sau actualizările de securitate. Izolarea unui container depinde și de privilegii, volume, rețea și configurarea gazdei; nu o tratați ca echivalentă în orice situație cu separarea unei VM.

Nu trebuie ales între VM și container. O VM poate găzdui mai multe containere, păstrând o limită clară între aplicație și alte sisteme ale firmei. Docker Compose poate descrie serviciile, rețelele și volumele unei aplicații cu mai multe containere și are instrucțiuni oficiale pentru folosirea în producție. Este însă necesar un plan separat pentru actualizări, monitorizare, backup și defectarea gazdei.

Ce adaugă Kubernetes

Orchestrarea înseamnă că o platformă urmărește starea dorită a componentelor și încearcă să le ruleze acolo unde există resurse. Kubernetes distribuie sarcini containerizate pe noduri, adică mașinile dintr-un cluster. Un Pod este unitatea de rulare care grupează unul sau mai multe containere. Un Deployment poate menține numărul dorit de Poduri pentru o componentă fără stare și poate coordona actualizări treptate.

Aceste funcții devin utile când aplicația are replici, adică instanțe ale aceleiași componente, pe mai multe noduri, schimbări dese și cerințe reale de extindere sau recuperare. Totuși, Kubernetes nu construiește aplicația, nu aduce implicit o bază de date și nu rezolvă singur stocarea, observabilitatea ori securitatea. Un cluster de producție cere decizii despre noduri, rețea, certificate, controlul accesului, stocare, actualizări și disponibilitatea planului de control, adică serviciile care conduc clusterul. Un serviciu gestionat poate transfera unele sarcini furnizorului, dar echipa rămâne responsabilă de configurația aplicației și de date.

Cercetarea Google despre Borg, Omega și Kubernetes descrie experiența gestionării containerelor la scară mare. Este context pentru problema orchestrării, nu dovada că fiecare firmă mică are nevoie de aceeași complexitate. Nu dimensionați proiectul după arhitectura unei platforme globale.

Portalul B2B: un scenariu de pornire

Să presupunem, explicit ca scenariu ipotetic, că interfața și API-ul portalului, adică punctul prin care sistemele schimbă cereri, rulează într-un mediu cloud, iar documentele și baza de date rămân inițial pe infrastructura firmei. Condițiile de latență și conectivitate din episodul 01 trebuie măsurate înainte de acceptarea acestei împărțiri. O variantă de test folosește o VM pentru partea de aplicație, cu containere separate pentru interfață, API și un proces de fundal care prelucrează cereri. Baza de date și documentele au un mediu separat, administrat conform politicilor firmei. Accesul dintre medii este controlat; baza de date nu este expusă direct publicului.

Procesul de fundal poate include ulterior un agent AI integrat în portal care clasifică o solicitare sau propune un rezumat pentru un operator. Agenții AI pe care echipa îi folosește pentru a dezvolta și testa codul sunt altceva: accesul și mediile lor de lucru se stabilesc separat. Un container pentru agentul din aplicație nu îi conferă automat dreptul de a citi toate documentele sau de a aproba o cerere.

În această variantă, Compose poate descrie serviciile aplicației. Pentru baza de date, alegem o soluție cu persistență și copii testate, fie pe VM, fie într-un serviciu gestionat dacă amplasarea datelor permite. Nu păstrăm singura copie a documentelor în stratul temporar al unui container. Un singur server de aplicație rămâne un punct unic de defectare: în fișa proiectului notăm timpul de recuperare acceptat, cine intervine și ce se întâmplă când VM-ul ori legătura dintre medii cade. Aceasta este o propunere de validat, nu o arhitectură certificată pentru orice portal.

Pentru fiecare lansare, păstrăm versiunea imaginii de container, configurarea aplicată și pașii de revenire. O repornire automată poate readuce un proces, dar nu repară o modificare greșită a datelor. Nici revenirea la imaginea anterioară nu inversează automat o schimbare a structurii bazei de date. De aceea, testăm actualizarea și restaurarea pe un mediu separat, cu date adecvate pentru test, înainte de a le folosi pentru solicitări reale. Măsurăm timpul de întrerupere și comunicăm operatorilor ce funcții sunt indisponibile.

Când merită un pas în plus

Înainte de Kubernetes, verificați dacă problema este într-adevăr orchestrarea pe mai multe noduri. Poate fi suficient să reparați un proces de livrare manual, să separați baza de date, să adăugați monitorizare sau să testați restaurarea. Dacă cererile cresc, măsurați încărcarea, durata operațiilor și frecvența incidentelor. O cerință clară de replicare a aplicației pe noduri distincte, actualizări fără întreruperi și echipa capabilă să opereze platforma poate justifica evaluarea Kubernetes ori a unei platforme gestionate. Chiar și atunci, disponibilitatea depinde de configurația reală și de testele de avarie.

Piesa rezultată este harta de rulare a portalului: pentru fiecare componentă, notați gazda, forma de împachetare, datele persistente, proprietarul operațional, scenariul de avarie și dovada din test. Adăugați o condiție precisă pentru schimbarea soluției, nu o promisiune vagă de „scalare”. În episodul următor vom separa rețelele și vom stabili ce trafic este permis între aceste componente.

Surse

• Red Hat, What is KVM? (16 aprilie 2026), pentru hypervisor și mașini virtuale.
• Docker Docs, What is a container?, pentru diferența dintre VM și container.
• Docker Docs, Use Compose in production, pentru utilizarea Compose în producție.
• Kubernetes, Overview și Production environment, pentru funcții și responsabilități de operare.
• Burns și colaboratorii, Borg, Omega, and Kubernetes, ACM Queue (2016), context academic privind orchestrarea la scară mare.

Următorul pas

Vrei să alegi o platformă pe care echipa ta o poate administra realist? Discută cu i8 despre harta de rulare și testele necesare proiectului tău.