Ce este Kubernetes și zece moduri creative de a-l folosi.

Kubernetes are reputația lucrului pe care îl adaugi când un proiect a devenit serios și o a doua reputație, a lucrului care a complicat un proiect simplu. Amândouă sunt meritate. Articolul ăsta pornește de la întrebarea pe care oamenii o scriu de fapt: ce este Kubernetes? Kubernetes rulează containere pe un grup de mașini și le ține pornite exact cum le-ai descris, fără să le supravegheze cineva. Utilizarea evidentă — o aplicație mare, pe multe servere — e acoperită de orice tutorial. Articolul ăsta e despre celelalte: cele care transformă un cluster într-o fermă de build-uri, un exercițiu de incendiu, un rezervor de plăci video sau o ușă de ieșire de la furnizorul de cloud. Mai întâi, pe scurt, ce este Kubernetes și prin ce diferă de Docker. Apoi zece moduri creative de a-l folosi, numărate invers de la zece, pe care îl poți construi pe birou în seara asta, la unu, utilizarea pe care am păstra-o dacă am putea păstra doar una.

Ce este de fapt Kubernetes

Docker rulează un container pe o mașină. Kubernetes rulează multe containere pe multe mașini și le ține în funcțiune. Descrii ce vrei — trei copii ale aplicației web, atâta memorie fiecare, accesibile la adresa asta — iar Kubernetes lucrează continuu ca clusterul să arate exact așa: pornește containerele, le mută de pe o mașină care a căzut, le repornește pe cele blocate și le înlocuiește pe rând când lansezi o versiune nouă. Bucla asta, care compară ce ai cerut cu ce rulează de fapt și închide diferența, este toată ideea.

Patru cuvinte fac cea mai mare parte din treabă. Un cluster e grupul de mașini, numite noduri, plus un plan de control care ia deciziile. Un pod e cea mai mică unitate pe care o rulează Kubernetes: unul sau mai multe containere care împart aceeași adresă. Un deployment spune câte poduri identice trebuie să existe și cum se lansează o versiune nouă. Un service e o adresă stabilă în fața unor poduri care vin și pleacă. Totul se scrie în fișiere text scurte, numite manifeste, deci întreaga configurație poate sta într-un depozit Git — ideea din spatele numărului unu.

Kubernetes vine de la Google, care își rula de un deceniu serviciile pe un sistem intern numit Borg. Google a publicat Kubernetes ca open source în iunie 2014, a lansat versiunea 1.0 în iulie 2015 și l-a cedat proaspăt înființatei Cloud Native Computing Foundation, unde a fost primul proiect care a absolvit. Numele înseamnă cârmaci în greacă, iar K8s e pur și simplu K, cele opt litere din mijloc și s.

Astăzi e modul implicit în care organizațiile mai mari rulează containere: în studiul Cloud Native Computing Foundation din 2025, 82% dintre utilizatorii de containere rulau Kubernetes în producție. Programatorii luați individual sunt altă poveste. În studiul Stack Overflow din 2025, 71,1% dintre respondenți foloseau Docker și 28,5% Kubernetes — majoritatea celor care lucrează cu containere nu ating niciodată un cluster. Iar Kubernetes nu stă pe loc. O versiune nouă apare de circa trei ori pe an, 1.37 în august 2026, și fiecare primește suport cam paisprezece luni, ceea ce face parte din cost, cum explică secțiunea despre costuri.

Kubernetes vs Docker: nu sunt rivali

Docker construiește și rulează containere; Kubernetes decide unde și câte dintre ele rulează pe un grup de mașini. Nu sunt alternative. Aceeași imagine, construită cu Docker, rulează pe un laptop sub Docker și pe un cluster sub Kubernetes, neschimbată. Comparația cinstită e între Kubernetes și Docker Compose, care rulează mai multe containere împreună pe o singură mașină.

Titlul „Kubernetes renunță la Docker”, din 2022, a încurcat mulți oameni. Ce s-a eliminat în Kubernetes 1.24 a fost dockershim, un adaptor prin care Kubernetes vorbea cu motorul Docker de pe fiecare nod. Clusterele vorbesc acum direct cu containerd sau CRI-O. Imaginile construite cu Docker respectă standardul deschis OCI, deci rulează exact ca înainte. Pentru un programator nu s-a schimbat nimic.

Regula de bază e scurtă. Unul sau două servere și câteva servicii: Docker Compose și ideile din zece moduri creative de a folosi Docker. Multe servicii, mai multe mașini, trafic care crește și scade sau mai multe echipe care publică independent: aceasta e problema pentru care a fost construit Kubernetes și punctul din care greutatea lui începe să se plătească singură.

Cum le-am clasat

„Creativ” e un cuvânt ieftin, așa că i-am dat un test. Fiecare intrare trebuia să fie altceva decât rularea aplicației principale și trebuia să ia ceva real de pe săptămâna cuiva: o factură, un pas manual fragil, un server pe care îl înțelege un singur om, un risc pe care nu l-a măsurat nimeni.

Kubernetes e mai greu decât Docker, așa că am ridicat ștacheta. Majoritatea intrărilor presupun că un cluster există deja — unul administrat de un furnizor de cloud sau unul mic, construit cu k3s — și întreabă ce altceva poate face, odată ce plătești pentru el. O utilizare care să justifice singură construirea unui cluster de la zero e rară și spunem asta acolo unde e cazul.

Ordinea merge de la zece la unu după cât valorează pentru o firmă mică sau o echipă mică de dezvoltare, nu după cât de isteț e trucul. Fiecare intrare are aceiași trei pași: ce înlocuiește, cum se face, în mare, și limita onestă.

10. Un cluster de Raspberry Pi pe birou

Ce înlocuiește: cititul despre Kubernetes în loc să-l vezi lucrând. k3s e o distribuție Kubernetes certificată, împachetată într-un singur fișier executabil mic, făcută pentru mașini mici și ARM. Trei sau patru plăci Raspberry Pi, sau câteva laptopuri vechi, fac un cluster adevărat într-o seară.

Își merită locul pentru că Kubernetes capătă sens abia când îl vezi revenindu-și. Rulează o aplicație în trei copii, scoate cablul de alimentare al unei plăci și urmărește cum clusterul observă și pornește copia lipsă în altă parte. Lansează o versiune nouă și privește cum înlocuiește podurile unul câte unul, fără ca pagina să cadă. Nicio diagramă nu te învață asta la fel de bine.

Limita onestă: e o sală de clasă, nu o cameră de servere. Cardurile SD se uzează, internetul de acasă nu e un centru de date, iar un cluster de pe birou nu are backup dacă nu i-l faci tu. Folosește-l ca să înveți, apoi rulează munca reală pe un cluster administrat sau pe mașini serioase.

9. Un exercițiu de incendiu: strici lucrurile intenționat

Ce înlocuiește: aflarea, în timpul unei căderi reale, că logica de reîncercare n-a funcționat niciodată. Uneltele de chaos engineering care rulează în cluster — Chaos Mesh și LitmusChaos sunt cele open source — opresc poduri, adaugă întârzieri de rețea între servicii, umplu un disc sau izolează un nod, după un program ales de tine.

Scopul e repetiția. Oprește podurile serviciului de plăți pe staging și vezi dacă finalizarea comenzii afișează un mesaj clar sau o pagină albă. Încetinește baza de date cu jumătate de secundă și vezi care pagină expiră prima. Fiecare descoperire e o reparație făcută într-o marți liniștită, nu în timpul unei campanii de reduceri.

Limita onestă: e o disciplină, nu un produs. Fără monitorizare care să-ți spună ce s-a întâmplat, un experiment de chaos e doar o cădere provocată de tine. Începe pe staging, ține fiecare experiment mic și reversibil și apropie-te de producție abia când echipa are încredere și în unealtă, și în propriile grafice. O echipă mică, fără angajamente de disponibilitate, câștigă poate mai mult întâi din verificări mai simple.

8. Sarcini programate care supraviețuiesc serverului pe care rulau

Ce înlocuiește: crontab-ul de pe un server care s-a oprit în liniște când serverul a fost reinstalat și backup-ul de noapte care eșuează din martie fără să știe nimeni. Un CronJob Kubernetes rulează un container după un program, oriunde în cluster, așa că sarcina nu mai depinde de o singură mașină care trebuie să rămână în viață.

Rezolvă și detaliile pe care un crontab obișnuit le lasă la noroc. O politică de concurență împiedică un backup lent să pornească a doua copie peste el însuși. Rulările eșuate sunt reîncercate de un număr stabilit de ori. Ultimele rulări reușite și eșuate rămân păstrate pentru verificare, iar programului i se poate da un fus orar explicit, ca o sarcină de la 02:00 să nu se mute la schimbarea orei.

Limita onestă: Kubernetes rulează sarcina, nu-l interesează dacă a făcut ceva util. Un backup care se termină cu succes după ce a scris un fișier gol e tot o rulare reușită. Pune alerte pe eșecuri, verifică rezultatul și testează restaurarea. Pentru două sarcini pe lună pe un singur server, un crontab cu un semnal trimis către un monitor de disponibilitate e perfect suficient.

7. Mașini de build care există doar cât rulează o sarcină

Ce înlocuiește: plata la minut pentru runnere CI găzduite sau un server de build care merge toată noaptea și încă are pe el fișierele de săptămâna trecută. Actions Runner Controller de la GitHub rulează runnere self-hosted ca poduri: când pornește un workflow, apare un runner nou, face treaba și e șters. Când nu se construiește nimic, numărul de runnere poate coborî la zero.

Fiecare build pornește dintr-o imagine curată, deci nimic nu trece de la o sarcină la alta — niciun token rămas, niciun cache vechi care face un build stricat să treacă. Suitele mari de teste se pot împărți pe câte runnere încap în cluster, iar runnerele stau în aceeași rețea cu serviciile de staging, ceea ce face testele de integrare simple.

Limita onestă e securitatea. Un runner din clusterul tău rulează orice cod conține workflow-ul, deci nu trebuie să preia niciodată sarcini din pull request-uri trimise de străini — chiar GitHub recomandă să nu folosești runnere self-hosted pe depozite publice. Construirea imaginilor de containere într-un pod cere și ea grijă: calea ușoară e un container privilegiat, care dă build-ului drepturi de root pe nod. Folosește un builder rootless și ține runnerele în propriul namespace, fără acces la producție.

6. Procese care dorm la zero și se trezesc pentru coadă

Ce înlocuiește: un server de procesare care stă degeaba douăzeci și două de ore pe zi ca să fie pregătit pentru două. KEDA, un proiect al Cloud Native Computing Foundation, urmărește o coadă, un tabel dintr-o bază de date, un program sau zeci de alte surse de evenimente și scalează un deployment de la zero poduri la câte îi trebuie muncii, apoi înapoi la zero când a terminat.

Se potrivește oricărei munci care vine în valuri: facturi transformate în PDF la final de lună, imagini de produs redimensionate după un import, o mie de emailuri după ce pleacă un newsletter, un video convertit după o încărcare. Coada se umple, procesele apar, coada se golește, procesele dispar.

Limita onestă e prima sarcină din val. Când nu rulează nimic, primul mesaj așteaptă să pornească un pod — câteva secunde de obicei, mai mult dacă clusterul trebuie să adauge și o mașină. Iar scalarea podurilor la zero economisește bani doar dacă și mașinile de dedesubt se micșorează, ceea ce cere și un autoscaler de noduri. Pe un cluster de dimensiune fixă, podurile inactive nu costă nimic în plus, iar câștigul e mai ales ordinea.

5. Un model AI privat care împarte o placă video scumpă

Ce înlocuiește: o placă video cumpărată pentru o singură unealtă AI internă și nefolosită cea mai mare parte a zilei. GPU Operator de la NVIDIA pentru Kubernetes poate împărți o placă între mai multe poduri, fie pe felii de timp, fie, pe plăcile de centru de date care permit asta, prin împărțirea ei în bucăți izolate. Mai multe modele mici — unul care rezumă documente, unul care citește facturi, unul care sortează cererile primite — pot atunci împărți o placă în loc să aibă nevoie fiecare de una.

Datele nu părăsesc niciodată infrastructura ta, care e tot motivul pentru care rulezi modele singur, iar clusterul le programează ca pe orice altă sarcină: repornite dacă se blochează, mutate dacă un nod cade. Conectat la propriile documente, devine varianta privată a RAG pentru afaceri.

Limita onestă: împărțirea pe felii de timp împarte timpul plăcii, nu memoria ei, deci un model care crește le poate împinge afară pe celelalte, iar o eroare într-unul le poate afecta pe toate. Izolarea adevărată cere împărțirea hardware pe care o oferă doar plăcile scumpe de centru de date. Mașinile cu GPU sunt și cele mai scumpe noduri pe care le poate avea un cluster. Pentru un model folosit de zece oameni, un singur server cu GPU care îl rulează în Docker — numărul cinci din zece moduri creative de a folosi Docker — e mai simplu și mai ieftin.

4. Muncă grea pe capacitate ieftină, rămasă liberă

Ce înlocuiește: plata la preț întreg pentru putere de calcul care trebuie să existe doar la un moment dat. Furnizorii de cloud își vând capacitatea nefolosită ca mașini spot, cu reduceri de până la 90%, cu o singură condiție: pot lua mașina înapoi cu un preaviz scurt — două minute la AWS, treizeci de secunde la Azure, iar la Google Cloud niciun preaviz dacă nu ceri unul. Kubernetes se descurcă foarte bine cu condiția asta. Când dispare un nod spot, podurile lui sunt mutate pe alte mașini, iar sarcinile eșuate sunt reîncercate.

Candidații buni sunt sarcinile mari, răbdătoare și care pot fi reluate: rapoarte de noapte peste un an de comenzi, regenerarea unui catalog de produse, procesarea unei arhive de documente scanate, antrenarea sau ajustarea unui model care își salvează progresul. Pune-le pe un grup de noduri spot și ține restul pe mașini obișnuite.

Limita onestă: acolo are loc doar munca ce poate fi întreruptă. Niciodată baza de date, niciodată finalizarea comenzii, niciodată ceva după care așteaptă un client. Sarcina trebuie să-și salveze progresul, altfel o mașină luată înapoi te costă toată rularea. Iar capacitatea spot se poate epuiza pentru un anumit tip de mașină, așa că permite mai multe tipuri și așteaptă-te la câte o întârziere.

3. Câte un namespace pentru fiecare client

Ce înlocuiește: câte un server separat pentru fiecare client sau pentru fiecare cumpărător al unui produs software, fiecare configurat de mână și fiecare îndepărtându-se de celelalte. Un namespace Kubernetes e o secțiune cu nume a unui cluster. Dă fiecărui client propriul namespace, cu o cotă de resurse ca nimeni să nu folosească mai mult decât partea lui, cu politici de rețea ca serviciile lui să nu poată vorbi cu ale altora și cu propriile secrete.

Adăugarea unui client devine aplicarea unui șablon; plecarea lui devine ștergerea namespace-ului, care elimină tot ce e în el. Se potrivește unei agenții care găzduiește multe aplicații de clienți și unui produs software care oferă clienților mai mari o instanță dedicată. Fiecare client rulează pe aceeași configurație testată, iar o îmbunătățire făcută o dată ajunge la toți.

Limita onestă: un namespace e un zid moale. Toți chiriașii împart planul de control al clusterului și nucleul nodurilor — ceea ce documentația Kubernetes numește multi-tenancy soft, gândit pentru chiriași care au încredere unii în alții. E potrivit pentru clienți de încredere care rulează cod scris de tine; nu e suficient pentru chiriași care s-ar putea ataca între ei sau pentru date strict reglementate, care cer noduri sau clustere separate. Reține și că Kubernetes stochează implicit secretele necriptate, dacă nu activezi criptarea datelor stocate — un namespace nu schimbă asta.

2. O ușă de ieșire de la furnizorul de cloud

Ce înlocuiește: propoziția „nu putem pleca” despre un furnizor de cloud ale cărui prețuri au crescut. Orice platformă Kubernetes certificată — serviciile administrate de Amazon, Google și Microsoft, DigitalOcean, furnizori europeni, un cluster pe hardware propriu — rulează aceleași manifeste în același fel. Asta certifică programul de conformitate al Cloud Native Computing Foundation, pentru peste 90 de oferte Kubernetes. O aplicație descrisă pentru un cluster poate fi mutată pe altul într-un proiect de câteva săptămâni, nu printr-o rescriere.

Valoarea unei ieșiri e că rareori trebuie s-o folosești. Una credibilă schimbă discuția despre preț și răspunde la întrebarea unde stau datele: dacă un client sau o reglementare cere un furnizor din UE, mutarea e o mărime cunoscută, nu o ghicitoare.

Limita onestă: portabilitatea acoperă containerele, nu serviciile din jurul lor. O bază de date administrată, o coadă, stocarea de fișiere sau sistemul de autentificare cumpărate de la furnizorul de cloud sunt o dependență pe care Kubernetes n-o elimină, iar load balancerele, stocarea și permisiunile se configurează diferit pe fiecare platformă. Ține și stratul de date portabil, altfel ușa se deschide doar pe jumătate. Rularea pe două clouduri în același timp e o idee diferită și mult mai scumpă — vezi lista utilizărilor pe care le-am lăsat afară.

1. Toată platforma ca un depozit Git

Ce înlocuiește: modificări făcute de mână pe un server live, ținute minte de un singur om și scrise nicăieri. În GitOps, o unealtă care rulează în cluster — Argo CD sau Flux, ambele proiecte absolvite ale Cloud Native Computing Foundation — urmărește un depozit Git și ține clusterul identic cu el. O modificare în producție e un pull request. Cineva o verifică, e acceptată, iar clusterul se actualizează singur.

E pe locul unu pentru că transformă operarea din ceva ce oamenii țin minte în ceva scris. Fiecare modificare are un autor, un motiv și o verificare — exact evidența modificărilor pe care o cere un auditor. Revenirea la versiunea anterioară înseamnă anularea unui commit. O reparație rapidă tastată direct în cluster e observată și anulată, deci depozitul rămâne adevărul. Iar dacă pierzi un cluster, unul nou îndreptat spre același depozit reconstruiește singur aplicațiile.

Tot aici se întâlnesc mai multe dintre intrările de mai sus. Namespace-urile de la numărul trei, sarcinile programate de la numărul opt și procesele de coadă de la numărul șase sunt toate doar fișiere în depozit, verificate și versionate ca orice cod.

Limitele oneste: secretele nu pot intra în Git ca text simplu, deci au nevoie de la prima zi de un format criptat sau de un depozit extern de secrete. Depozitul devine cel mai sensibil lucru pe care îl ai, pentru că cine poate accepta modificări în el controlează producția. Iar Git descrie aplicațiile, nu datele: bazele de date și fișierele încărcate au în continuare nevoie de backup real și de o restaurare testată.

Cinci pe care le-am lăsat afară și de ce

Kubernetes pentru un site de prezentare. Un site de cinci pagini, sau un site WordPress cu un formular de contact, are nevoie de găzduire bună, nu de un cluster. Kubernetes adaugă piese mobile pe care un astfel de site nu le va folosi niciodată, iar cineva plătește pentru fiecare dintre ele.

Kubernetes pentru trei containere pe un server. Docker Compose rulează câteva servicii pe o singură mașină cu o fracțiune din complexitate. Treci mai sus când ai cu adevărat nevoie de mai multe mașini, de scalare automată sau de echipe independente — nu când o prezentare de la o conferință spune că vei avea.

Un plan de control construit de mână, pentru producție. Asamblarea unui cluster de la zero e un mod excelent de a învăța și un mod prost de a conduce o afacere. Folosește un serviciu administrat, sau k3s pentru instalări mici, și petrece timpul pe aplicații.

Baza de date de producție în cluster, fără nimeni care să știe s-o ruleze acolo. Bazele de date pot merge bine pe Kubernetes, cu un operator care se ocupă de replici, backup și actualizări. Fără cineva care să înțeleagă acel operator, o bază de date administrată iese de obicei mai ieftin, dacă numeri orele.

Multi-cloud de dragul multi-cloud. Rularea aceleiași aplicații pe două clouduri în același timp dublează munca de operare pentru un nivel de reziliență de care majoritatea firmelor nu au nevoie niciodată. Numărul doi e despre păstrarea opțiunii de a pleca, nu despre a locui permanent în două locuri.

Cât costă, de fapt, toate astea

Kubernetes în sine e open source și gratuit. Costurile sunt mașinile, planul de control și, mai presus de toate, oamenii.

Planul de control e locul unde serviciile administrate diferă. Amazon EKS cere 0,10 dolari pe oră pentru fiecare cluster, cam 73 de dolari pe lună. Google GKE cere aceeași taxă, dar oferă fiecărui cont de facturare un credit lunar care acoperă un cluster zonal sau Autopilot. Azure AKS are un nivel gratuit fără garanție de disponibilitate și un nivel Standard la 0,10 dolari pe oră, iar DigitalOcean nu taxează deloc planul de control. Peste acestea vin nodurile — de obicei cel puțin trei, ca pierderea unuia să nu fie o cădere — și load balancerele și stocarea pe care le folosesc.

Cel mai mare cost e atenția. Un cluster trebuie actualizat cam de trei ori pe an ca să rămână pe o versiune cu suport, iar un cluster pe care nu-l actualizează nimeni iese din suport în ceva mai mult de un an; pe EKS, rămânerea pe o versiune veche costă atunci 0,60 dolari pe oră în loc de 0,10. Cineva trebuie să răspundă de actualizări, monitorizare, patch-uri de securitate și backup. Linia asta, nu factura de găzduire, e locul unde se ia de fapt decizia de a folosi Kubernetes — așa că ia-o cu bună știință.

Dacă încerci doar unul

Încearcă numărul zece, chiar dacă nu vei pune niciodată Kubernetes în producție. O seară cu k3s pe două mașini vechi te învață ideea din spatele tuturor celorlalte intrări: descrii ce trebuie să ruleze, iar clusterul păstrează lucrurile așa când ceva se strică.

După aceea, depinde unde ești. Dacă afacerea ta rulează pe unul sau două servere, probabil nu ai nevoie încă de Kubernetes — ideile de găzduire proprie din zece moduri creative de a folosi Docker te vor ajuta mai mult. Dacă rulezi deja un cluster, fă numărul unu. E intrarea al cărei câștig crește cu fiecare lună în care rămâne pe loc.

Iar dacă preferi să-l configureze altcineva, munca noastră cu Docker acoperă Compose pe un singur server și Kubernetes atunci când o aplicație l-a depășit, iar Hosting Node.js + monitorizare îl ține în funcțiune după aceea. Spune-ne ce rulează unde astăzi și îți spunem sincer dacă te-ar ajuta Kubernetes — inclusiv când răspunsul e că nu ai nevoie de el.

Surse

Fiecare afirmație despre produse, prețuri și suport de mai sus vine din paginile publice ale proiectului sau ale furnizorului, verificate în octombrie 2026. Prețurile și condițiile de suport se schimbă, așa că verifică înainte să te angajezi.

• Documentația Kubernetes — Overview ↗

  Definește Kubernetes ca o platformă portabilă, extensibilă și open source pentru administrarea sarcinilor și serviciilor din containere. Numele înseamnă cârmaci sau pilot în greacă, K8s numără cele opt litere dintre K și s, iar Google a publicat proiectul ca open source în 2014.

• Blogul Kubernetes — 10 years of Kubernetes ↗

  Primul commit a fost pe 6 iunie 2014, iar versiunea 1.0 pe 21 iulie 2015, când Google a anunțat că va dona Kubernetes proaspăt înființatei Cloud Native Computing Foundation. A devenit primul proiect absolvit al fundației în martie 2018.

• Kubernetes — Patch releases ↗

  Versiunile minore apar de circa trei ori pe an și primesc aproximativ paisprezece luni de suport: douăsprezece luni de suport standard, urmate de două luni în regim de întreținere. Versiunea 1.37 a apărut pe 26 august 2026.

• Blogul Kubernetes — Dockershim removal FAQ ↗

  Kubernetes 1.24 a eliminat dockershim; imaginile produse cu docker build funcționează cu toate implementările CRI, precum containerd și CRI-O.

• CNCF — Annual Cloud Native Survey 2025 ↗

  Publicat în ianuarie 2026: 82% dintre utilizatorii de containere rulează Kubernetes în producție, față de 66% în 2023.

• Stack Overflow — 2025 Developer Survey, Technology ↗

  Dintre toți respondenții, 71,1% foloseau Docker și 28,5% Kubernetes în 2025.

• Documentația Kubernetes — Multi-tenancy ↗

  Descrie namespace-urile, cotele de resurse și politicile de rețea ca piesele de bază pentru împărțirea unui cluster și deosebește multi-tenancy soft, între chiriași de încredere, de multi-tenancy hard, între chiriași care nu au încredere unii în alții.

• Documentația Kubernetes — Secrets ↗

  Secretele sunt stocate implicit necriptat în baza de date a serverului API (etcd); criptarea datelor stocate trebuie activată separat.

• Documentația Kubernetes — CronJob ↗

  Acoperă politica de concurență (Allow, Forbid, Replace), limitele istoricului de rulări și câmpul pentru fusul orar.

• K3s — Requirements ↗

  O distribuție Kubernetes certificată și proiect sandbox al Cloud Native Computing Foundation, care rulează pe x86 și ARM, inclusiv Raspberry Pi. Minimul: 2 nuclee și 2 GB de memorie pentru un nod server, 1 nucleu și 512 MB pentru un agent; pe Raspberry Pi se recomandă un SSD.

• Chaos Mesh ↗

  O platformă de chaos engineering pentru Kubernetes care provoacă defecte de pod, rețea, disc și nod; proiect în incubare al Cloud Native Computing Foundation, ca și LitmusChaos.

• Documentația GitHub — Actions Runner Controller ↗

  Un operator Kubernetes care orchestrează și scalează runnere self-hosted pentru GitHub Actions; seturile de runnere pot coborî la zero.

• Documentația GitHub — Securitatea runnerelor self-hosted ↗

  Recomandă folosirea runnerelor self-hosted doar cu depozite private, pentru că fork-urile unui depozit public pot rula cod pe ele prin pull request-uri.

• KEDA ↗

  Scalare automată pe bază de evenimente pentru Kubernetes: scalează sarcinile de la și până la zero după cozi, baze de date, programe și peste 70 de alte surse de evenimente incluse; proiect al Cloud Native Computing Foundation din 2020, absolvit în august 2023.

• NVIDIA — GPU Operator, time-slicing ↗

  Împărțirea pe felii de timp permite mai multor poduri să folosească aceeași placă, dar fără izolare de memorie sau de erori între ele; Multi-Instance GPU (MIG) împarte plăcile de centru de date compatibile în instanțe izolate.

• AWS — EC2 Spot Instances ↗

  Capacitate EC2 liberă cu până la 90% sub prețul On-Demand, care poate fi luată înapoi cu un preaviz de două minute.

• Google Cloud — Spot VMs ↗

  Mașinile Spot costă cu până la 91% mai puțin decât cele standard. Preavizul de oprire e opțional — niciunul implicit sau 120 de secunde dacă e configurat — iar oprirea care urmează durează până la 30 de secunde.

• Microsoft Learn — Azure Spot Virtual Machines ↗

  Mașinile Spot folosesc capacitatea liberă Azure cu o reducere de până la 90% și pot fi retrase cu un preaviz de 30 de secunde.

• Argo CD ↗

  O unealtă declarativă de livrare continuă GitOps pentru Kubernetes, care ține starea clusterului sincronizată cu un depozit Git; parte din proiectul Argo, absolvit în Cloud Native Computing Foundation în decembrie 2022.

• Flux ↗

  Un set de unelte GitOps care aliniază clusterele cu depozite Git și alte surse; absolvit în Cloud Native Computing Foundation în noiembrie 2022.

• CNCF — Certified Kubernetes Software Conformance ↗

  Listează peste 90 de oferte Kubernetes certificate; conformitatea înseamnă că aceleași API-uri se comportă la fel, deci sarcinile se mută de la o instalare certificată la alta.

• Amazon EKS — Pricing ↗

  0,10 dolari pe cluster pe oră cât timp versiunea Kubernetes are suport standard și 0,60 dolari pe cluster pe oră după ce trece în suport extins.

• Google Kubernetes Engine — Pricing ↗

  O taxă de administrare de 0,10 dolari pe cluster pe oră, cu un credit gratuit de 74,40 dolari pe lună pentru fiecare cont de facturare, utilizabil pe clustere zonale și Autopilot.

• Azure Kubernetes Service — Pricing ↗

  Nivelul Free nu taxează planul de control și nu are SLA de disponibilitate; nivelul Standard costă 0,10 dolari pe cluster pe oră (lista de prețuri Azure, East US).

• DigitalOcean Kubernetes — Pricing ↗

  Planul de control nu se taxează; varianta cu disponibilitate ridicată costă 40 de dolari pe lună.