Kubernetes & Helm Fundamentals

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 1 din 10. Ani de zile, Google și-a rulat infrastructura globală de search și e-mail folosind un sistem extrem de secret, numit după cei mai terifianți răufăcători din Star Trek. A trebuit să-l inventeze deoarece managementul existent al serverelor pur și simplu ceda la scara lor. Astăzi, ne uităm la originile sale, de la Borg la Kubernetes, și de ce companiile moderne se bazează pe el. Pentru a înțelege de ce există Kubernetes, trebuie să te uiți la cum a evoluat partea de deployment al aplicațiilor. În era tradițională de deployment, rulai aplicațiile pe servere fizice. Nu exista nicio modalitate de a defini limitele de resurse. Dacă o aplicație ocupa cea mai mare parte din memorie, alte aplicații de pe acel server fizic aveau de suferit. Puteai să cumperi o mașină fizică separată pentru fiecare aplicație, dar asta ducea la hardware scump și subutilizat. Apoi a urmat era de deployment virtualizat. Rulai mai multe Virtual Machines pe CPU-ul unui singur server fizic. VM-urile izolau aplicațiile și ofereau un anumit nivel de securitate, dar fiecare VM necesita în continuare un sistem de operare complet și greoi. În cele din urmă, am ajuns la era de deployment cu containere. Containerele sunt similare cu VM-urile, dar împart sistemul de operare de bază între aplicații. Pentru că sunt decuplate de hardware-ul de bază, sunt lightweight, pornesc rapid și sunt portabile pe diferite cloud-uri și distribuții de sisteme de operare. Dar containerele au introdus o nouă problemă. Dacă rulezi o aplicație enterprise globală, nu ai doar un singur container. Ai mii. Dacă un container pică, altul trebuie să pornească imediat. Dacă apar spike-uri de trafic, trebuie să faci spin up la mai multe containere și să distribui uniform load-ul în rețea. Nu poți gestiona asta manual pe sute de mașini. Google s-a confruntat exact cu această problemă cu mult înaintea restului industriei. Au construit un cluster manager intern pentru containere numit Borg, pentru a automatiza orchestrarea a sute de mii de job-uri. Când a devenit clar că restul lumii software avea nevoie de aceeași capabilitate, inginerii Google au început un proiect open-source bazat pe lecțiile învățate din Borg. I-au dat o referință din Star Trek, numindu-l inițial Project Seven of Nine, o aluzie la o dronă Borg care a scăpat din colectiv. Acel proiect s-a lansat în cele din urmă sub numele de Kubernetes. Logoul în formă de cârmă pe care îl vezi astăzi are șapte spițe, ca un omagiu discret adus numelui original al proiectului. Asta e partea care contează. Kubernetes îți oferă un framework pentru a rula sisteme distribuite în mod rezilient. Se ocupă de scaling și failover pentru aplicația ta. Dacă un container dă crash, Kubernetes îl înlocuiește. Dacă un node pică, face reschedule la containere pe node-uri sănătoase. Se ocupă de service discovery, ceea ce înseamnă că un container poate fi găsit folosind un nume DNS sau propria adresă IP, și face load balancing, astfel încât niciun container să nu fie suprasolicitat. De asemenea, gestionează partea de storage orchestration, permițându-ți să faci mount automat la storage local sau la cloud providers, și automatizează procesele de rollout și rollback. Tu descrii starea dorită a containerelor tale deployate, iar Kubernetes schimbă starea actuală în starea dorită la o rată controlată. Nu scrii scripturi pentru a gestiona starea serverului; declari ceea ce vrei, iar sistemul face lucrurile să se întâmple. Ideea principală aici este că Kubernetes nu este doar un mediu de hosting, ci este un control loop care măsoară constant realitatea în raport cu așteptările tale și corectează diferența. Înainte să încheiem, dacă vrei să ne ajuți să continuăm să facem aceste episoade, caută DevStoriesEU pe Patreon — apreciem sprijinul. Asta e tot pentru acest episod. Mersi că ne-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes & Helm, episodul 2 din 10. Ai zeci de servere care rulează sute de containere. Când o mașină cedează brusc, ceva trebuie să decidă unde merg mai departe acele workloads orfane. O orchestră fără dirijor e doar zgomot, iar o flotă de containere fără un creier centralizat e un haos imposibil de gestionat. Acel creier centralizat, împreună cu mașinile care fac munca propriu-zisă, formează arhitectura de cluster Kubernetes. Un cluster Kubernetes este împărțit în două jumătăți distincte. Ai Control Plane-ul, care acționează ca un creier, și ai Worker Nodes, care reprezintă forța brută. Control Plane-ul ia toate deciziile globale, cum ar fi scheduling-ul pentru workloads, și detectează și răspunde la evenimentele din cluster. Worker Nodes îți găzduiesc aplicațiile și execută instrucțiunile trimise de Control Plane. Orice cluster trebuie să aibă cel puțin un worker node pentru a rula aplicații. Uită-te mai întâi la Control Plane. Componenta sa principală este kube-apiserver. Uneori, ascultătorii aud API server și își imaginează un web server standard care gestionează request-uri HTTP pentru o aplicație. Nu despre asta e vorba aici. kube-apiserver este sistemul nervos central al întregului cluster. Este front end-ul pentru Control Plane. Absolut orice comunicare, fie că vine de la un operator uman, de la un worker node sau de la o componentă internă, este rutată prin acest API server. Pentru că API server-ul este complet stateless, clusterul are nevoie de o memorie. Aceasta este etcd. Acesta este un key-value store consistent și highly-available, care conține toate datele clusterului. Ori de câte ori se creează o configurație sau se schimbă starea sistemului, înregistrarea reală a acelei modificări se află în etcd. Urmează kube-scheduler. Când ceri clusterului să ruleze un nou workload de containere, acel workload nu are inițial nicio mașină asignată. Scheduler-ul observă acest workload neasignat. Evaluează cerințele de resurse, constrângerile hardware și regulile de policy, apoi asignează workload-ul celui mai potrivit worker node. În cele din urmă, ai kube-controller-manager. Această componentă rulează background loops continue, numite controllere. Aceste controllere urmăresc constant starea curentă a clusterului prin API server și lucrează activ pentru a aduce acea stare curentă cât mai aproape de starea ta dorită. Dacă un worker node dă crash, controller manager-ul observă mașina lipsă și declanșează răspunsul pentru a înlocui acele workloads pierdute. Asta acoperă partea de creier. Acum uită-te la worker nodes care execută task-urile. Componentele de nod rulează pe absolut fiecare mașină worker pentru a menține acel runtime environment. Cea mai critică componentă aici este kubelet. Acesta este un agent care rulează pe fiecare nod și comunică direct cu Control Plane-ul. Kubelet preia instrucțiuni de la API server și se asigură că acele containere necesare chiar rulează și sunt healthy pe mașina sa specifică. Kubelet nu pornește el însuși containerele. Deleagă acest task către Container Runtime. Runtime-ul este software-ul propriu-zis, cum ar fi containerd, responsabil pentru a face pull la imaginile de containere dintr-un registry și pentru a porni procesele pe sistemul de operare. În cele din urmă, există kube-proxy. Acesta este un network proxy care rulează pe fiecare nod. Menține regulile de rețea locală care permit comunicării de rețea să ajungă la containerele tale din interiorul sau din afara clusterului. Iată ideea cheie. Control Plane-ul dictează ce ar trebui să se întâmple, dar nu execută niciodată codul aplicației. Worker Nodes rulează codul aplicației, dar se bazează în întregime pe Control Plane pentru a le spune ce să ruleze. Această separare strictă a luării deciziilor de execuție este ceea ce permite Kubernetes să scaleze pe orizontală și să se recupereze automat după defecțiuni hardware. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes & Helm, episodul 3 din 10. Construiești un container, îl testezi local și îl dai lui Kubernetes să-l ruleze. Dar Kubernetes refuză categoric să lucreze direct cu containerul tău. În schimb, îți cere să-l încapsulezi mai întâi într-o abstracție complet diferită. Demistificăm Pod-urile, unitatea de lucru propriu-zisă din acest ecosistem. Dacă containerele sunt balenele independente ale lumii tradiționale a containerizării, Pod-urile sunt grupurile unite în care acestea înoată împreună. Un Pod este cel mai mic și mai de bază obiect căruia îi poți face deploy, pe care îl poți crea și gestiona în Kubernetes. Reprezintă o singură instanță a unui proces care rulează în clusterul tău. S-ar putea să te întrebi de ce Kubernetes introduce acest strat suplimentar în loc să gestioneze direct containerele. Răspunsul constă în abstractizare și context partajat. Kubernetes are nevoie de o modalitate uniformă de a gestiona partea de networking, storage și scheduling, indiferent de runtime-ul de container pe care îl folosești. Prin încapsularea containerelor într-un Pod, Kubernetes tratează Pod-ul ca pe un host logic. Aici e ideea de bază. Un Pod nu doar încapsulează un singur container; el stabilește un mediu de execuție partajat. Deși un Pod conține adesea un singur container, acesta poate conține mai multe containere care trebuie să colaboreze strâns. Atunci când mai multe containere sunt plasate în interiorul aceluiași Pod, ai garanția că vor primi scheduling pe exact aceeași mașină fizică sau virtuală. Mai important, aceste containere împart același network namespace. Fiecare container dintr-un singur Pod împarte o singură adresă IP și un singur port space. Pentru că există în același network context, pot comunica între ele pur și simplu folosind localhost. Nu e nevoie de DNS lookups interne sau de service routing complex doar ca să faci două procese locale să comunice. Dacă containerul A face bind pe portul opt mii, containerul B din același Pod îl poate accesa la localhost portul opt mii. Acest context comun se extinde și la storage. Poți defini storage volumes partajate la nivel de Pod. Odată definite, orice container din acel Pod poate face mount la acele volume partajate în propriul său file system. Asta permite containerelor tightly coupled să citească și să scrie exact aceleași fișiere fără probleme. Ia în considerare un container principal de web server. Treaba lui este să servească trafic HTTP, dar scrie și access logs brute într-un director local. Vrei să trimiți acele loguri către un sistem central de monitorizare, dar nu vrei să încarci imaginea de web server cu logging agents și fișiere de configurare. În schimb, creezi un al doilea container, un utilitar de logging lightweight. Faci deploy atât web serverului, cât și containerului de logging în exact același Pod. Web serverul își scrie logurile într-un storage volume partajat. Containerul de logging, acționând ca un sidecar, face mount la același volum, citește fișierele de log primite și le face stream către sistemul tău de monitorizare. Ele operează ca o singură unitate integrată, împărțind resursele fără a-și amesteca responsabilitățile individuale. Când decizi dacă două containere aparțin aceluiași Pod, întreabă-te dacă au nevoie în mod inerent să ajungă pe exact aceeași mașină și să împartă un lifecycle identic. Dacă nu e absolut necesar să primească deploy, să pornească și să moară împreună, atunci aparțin în Pod-uri separate. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 4 din 10. Dormi. La trei dimineața, un memory leak îți pică serverul principal de aplicații. Într-un setup tradițional, se declanșează o alertă și te trezești ca să repornești procesul manual. În Kubernetes, sistemul face tura de noapte în locul tău. Asta e puterea gestionării state-ului cu Deployments. Un Deployment oferă update-uri declarative pentru aplicațiile tale. În loc să scrii scripturi care îi spun sistemului pas cu pas cum să-ți ruleze software-ul, descrii exact cum ar trebui să arate imaginea finală. Transmiți acest desired state către Deployment controller, iar el modifică state-ul real ca să se potrivească, într-un ritm controlat. Ca să înțelegi cum face asta, trebuie să cunoști ierarhia. Rareori creezi direct Pod-uri individuale. În schimb, creezi un Deployment. Deployment-ul creează apoi un obiect secundar numit ReplicaSet. ReplicaSet-ul este mecanismul strict responsabil să se asigure că numărul exact de replici de Pod-uri specificat rulează în orice moment. Dacă un node de server pică, sau un Pod dă crash din cauza acelui memory leak, ReplicaSet-ul observă că numărul a scăzut sub desired state-ul tău. Imediat pornește un Pod nou ca să-l înlocuiască pe cel pierdut. Ăsta e mecanismul tău de self-healing. Nu intervii niciodată. Aceeași logică se aplică și la scaling. Dacă traficul are un spike, îți faci update la fișierul de Deployment ca să ceri cinci replici în loc de trei. Controller-ul vede discrepanța dintre request-ul tău și realitate, și dă instrucțiuni ReplicaSet-ului să mai lanseze două Pod-uri. Abordarea asta declarativă e critică mai ales în timpul update-urilor de aplicație. Să zicem că ai trei Pod-uri care rulează o imagine de Nginx la versiunea 1.14. Trebuie să faci upgrade la versiunea 1.16 fără să pierzi din traficul utilizatorilor. Pur și simplu actualizezi versiunea imaginii în configurația de Deployment. Deployment-ul nu îți oprește toate Pod-urile vechi deodată. În schimb, creează un ReplicaSet complet nou, special pentru versiunea 1.16. Apoi, începe un rolling update. Pornește un Pod nou în noul ReplicaSet. Odată ce noul Pod este healthy, dă scale down la vechiul ReplicaSet oprind un Pod de versiune 1.14. Repetă procesul ăsta atent și eșalonat până când toate cele trei Pod-uri vechi dispar și rulează trei Pod-uri noi. Tranziția este complet seamless. Acum, ce se întâmplă dacă update-ul e stricat? Aici e ideea cheie. Pentru că Deployment controller-ul orchestrează aceste ReplicaSets, îți oferă o plasă de siguranță built-in. Dacă tastezi din greșeală numele imaginii ca Nginx 1.16-typo, noile Pod-uri vor da crash la startup. Deployment-ul detectează eroarea și oprește imediat rollout-ul. Îți lasă vechile Pod-uri să ruleze în continuare, astfel încât aplicația ta rămâne online. Odată ce identifici eroarea, poți să dai o comandă de rollback. Deployment-ul pur și simplu dă scale up la loc vechiului ReplicaSet, pe care îl știe că e bun, și dă scale down la zero celui stricat. Adevărata putere a unui Deployment nu constă doar în lansarea de containere, ci în loop-ul său continuu și neobosit de a compara ce ai cerut cu ce există de fapt, și de a forța realitatea să se potrivească. Aș vrea să-ți mulțumesc pentru că ne asculți — ne ajută foarte mult. Să ai o zi faină!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 5 din 10. Pod-urile sunt muritoare. Dau crash, li se face scale down, primesc evict, iar când sunt înlocuite, primesc un IP complet nou. Dacă ai o aplicație care încearcă să comunice cu ele, tragi constant într-o țintă în mișcare. Resursele de tip Service din Kubernetes rezolvă exact această problemă. Gândește-te la o aplicație web tipică. Ai un deployment de frontend și o bază de date pe backend. Dacă Pod-ul bazei de date își dă restart, control plane-ul clusterului pornește un Pod nou ca să-l înlocuiască. Acestui Pod nou i se atribuie o adresă IP complet diferită în rețeaua clusterului. Dacă frontend-ul tău a fost configurat să comunice direct cu vechiul IP, conexiunea se pierde și aplicația ta pică. Nu te poți baza pe IP-urile individuale ale Pod-urilor pentru nimic permanent. Un Service din Kubernetes este o abstracție care oferă o identitate de rețea stabilă și de lungă durată pentru un grup dinamic de Pod-uri. Când creezi un Service, i se atribuie o adresă IP care nu se va schimba niciodată cât timp acel Service există. Aplicația ta de frontend nu trebuie să țină evidența exactă a Pod-urilor de bază de date care sunt active într-o anumită secundă. Pur și simplu trimite trafic către IP-ul acelui Service. Mai mult, clusterul atribuie un nume de DNS stabil pentru Service. Codul tău de frontend se poate conecta la un simplu hostname, iar clusterul îi face resolve automat la adresa IP corectă. În culise, acest Service acționează ca un load balancer intern. Se bazează pe o componentă numită kube-proxy, care rulează pe fiecare node, pentru a implementa regulile efective de routing. Când traficul ajunge la Service, este redirecționat către unul dintre Pod-urile healthy din spate. Pentru a lega un Service de Pod-urile corecte, folosești labels și selectors. Poți configura acel Service cu un selector care caută un label ce indică o aplicație de bază de date. Acest Service urmărește constant clusterul. Dacă un Pod de bază de date moare, IP-ul lui este eliminat din pool-ul activ. Când Pod-ul de înlocuire pornește, noul său IP este adăugat. Aplicația de frontend rămâne complet inconștientă de faptul că topologia de rețea din spate tocmai s-a schimbat. Există câteva modalități de a expune un Service, în funcție de unde vine traficul. Tipul default este ClusterIP. Un Service de tip ClusterIP primește un IP intern, accesibil doar din interiorul clusterului. Asta este alegerea corectă pentru baza ta de date de pe backend, păstrând-o izolată în siguranță de lumea exterioară. Dar frontend-ul tău trebuie să primească trafic de la utilizatori externi. Pentru asta, schimbi tipul de Service în LoadBalancer. Când creezi un Service de tip LoadBalancer, Kubernetes comunică cu cloud provider-ul tău pentru a face provision la un load balancer extern standard. Traficul extern de pe internet ajunge la acea resursă de cloud, care face forward la conexiune în clusterul tău, trecând-o prin Service și, în final, către Pod-urile tale de frontend. Aici e ideea de bază. Resursele de tip Service decuplează identitatea adresabilă a aplicației tale de workload-urile fizice care execută efectiv logica. Te oprești din a face routing către instanțe specifice, fragile, și începi să faci routing către un concept rezilient și persistent. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 6 din 10. Vrei să faci deploy la o singură aplicație, dar ajungi să gestionezi sute de linii de YAML static prin deployments, services și ingresses. Când trebuie să faci push la aceeași aplicație într-un mediu de staging, copiezi acele fișiere într-un director nou și cauți și înlocuiești manual image tags și hostnames. Este un proces fragil, extrem de repetitiv și imposibil de întreținut pe măsură ce infrastructura ta crește. Asta este exact problema pe care Helm a fost creat să o rezolve. Helm este package manager-ul pentru Kubernetes. Te poți gândi la el ca la apt, yum sau Homebrew, dar conceput special pentru resursele Kubernetes. În loc să îți trateze aplicația ca pe o colecție de manifests YAML independente, Helm le grupează într-o singură unitate coezivă. Acest format de packaging se numește Chart. Un Chart este în esență un director care conține fișiere ce descriu un set corelat de resurse Kubernetes. Conține toate definițiile de care aplicația ta are nevoie pentru a rula. Principalul mecanism care face ca un Chart să fie util este templating-ul. Manifests-urile Kubernetes raw sunt complet statice. Un Chart Helm, prin contrast, înlocuiește detaliile de infrastructură hardcoded cu template variables. În loc să scrii un replica count specific, un container image tag fix sau un environment variable distinct direct într-un fișier de deployment, definești placeholders. Când vine momentul să faci deploy, Helm îmbină aceste templates cu un fișier separat care conține valorile tale specifice. Această arhitectură înseamnă că menții mereu un singur Chart pentru aplicația ta. Pur și simplu îi transmiți parametri de configurare diferiți, în funcție de cum faci deploy: local, în staging sau în producție. Când iei un Chart, îl combini cu valorile tale specifice de configurare și îi faci deploy într-un cluster Kubernetes, creezi ceea ce Helm numește un Release. Aici devine interesant. Un Chart este doar blueprint-ul generic. Un Release este instanța efectivă, deployată, care rulează în clusterul tău. Datorită acestei separări stricte dintre blueprint și instanță, poți instala exact același Chart de mai multe ori în exact același cluster. Dacă ai nevoie de trei instanțe separate ale unui caching server, nu duplici YAML-ul. Instalezi caching chart-ul de trei ori. Helm urmărește fiecare instalare ca un Release distinct, cu propriul nume unic, propriile valori de configurare și propriul lifecycle izolat. De asemenea, Helm urmărește starea și istoricul acestor Releases în cadrul clusterului. Când actualizezi o aplicație furnizând un nou image tag sau modificând o setare, Helm evaluează diferențele și creează un nou revision al acelui Release specific. Aplică doar modificările necesare resurselor Kubernetes subiacente. Dacă un update eșuează sau o aplicație începe să se comporte ciudat, îi dai comanda lui Helm să facă roll back la un revision anterior. Helm știe exact ce resurse Kubernetes aparțin cărei versiuni a aplicației tale, gestionând crearea, modificarea și ștergerea acelor resurse ca o singură operațiune. Schimbarea principală cu Helm este abstractizarea. Încetezi să mai gestionezi fișiere text independente care reprezintă pods, services și volumes deconectate, și începi să faci deploy, să configurezi și să actualizezi aplicații complete. Mulțumesc pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 7 din 10. Trebuie să actualizezi o parolă de bază de date, dar credențialele sunt hardcoded în cincisprezece fișiere YAML diferite. Un singur fișier omis, și întregul deployment eșuează. Să faci hardcoding la configurație direct în structura ta de deployment este o abordare fragilă. Soluția este să înțelegi anatomia unui Helm chart. Un Helm chart este un pachet standardizat care conține toate definițiile de resurse necesare pentru a rula o aplicație, un tool sau un serviciu în interiorul unui cluster Kubernetes. Întregul sistem este construit în jurul unei filozofii de bază: o separare strictă între definiția structurală și configurația specifică mediului. Definești forma deployment-ului tău o singură dată și injectezi detaliile specifice atunci când este timpul să faci deploy. Când te uiți în interiorul unui Helm chart, găsești un layout specific de directoare. Folderul top-level poartă întotdeauna numele chart-ului în sine. În interiorul acestui folder, trei componente de bază susțin sistemul de packaging. Primul este un fișier numit Chart dot yaml. Acesta este hub-ul de metadate. Îi spune lui Helm exact ce este pachetul. Conține versiunea de API pentru standardul chart-ului, numele chart-ului, o descriere și numerele de versiune. În mod crucial, urmărește atât versiunea chart-ului în sine, cât și app version, adică versiunea software-ului propriu-zis căruia i se face deploy. S-ar putea să găsești și un director charts lângă el, care conține orice subcharts de care depinde aplicația ta, dar fișierul de metadate este identificatorul principal. A doua componentă principală este directorul templates. Aici se află definiția structurală. Înăuntru, pui fișierele tale standard de manifest Kubernetes, cum ar fi deployments și services. Totuși, în loc să scrii YAML static, aceste fișiere conțin logică de Go template. În loc să faci hardcoding la un replica count de trei, sau să dai paste la o parolă specifică de bază de date, scrii o directivă de template. Acea directivă instruiește Helm să caute dinamic valoarea necesară în timpul deployment-ului. A treia componentă răspunde la aceste lookup-uri dinamice. Este un fișier numit values dot yaml, care stă la rădăcina directorului chart-ului, alături de fișierul de metadate. Acest fișier conține setările de configurare default. Când un template cere un image repository, un număr de port sau o parolă, fișierul values oferă răspunsul de bază. Iată ideea cheie. Template-urile dictează arhitectura aplicației tale, în timp ce valorile dictează modul în care acea arhitectură se comportă într-un mediu specific. Când rulezi o comandă de install, Helm ia template-urile brute, le face merge cu fișierul values și randează fișiere manifest Kubernetes finale și valide. Apoi trimite acele manifeste randate către API-ul Kubernetes. Această separare este ceea ce face chart-urile extrem de reutilizabile. Gândește-te la un scenariu în care trebuie să faci deploy la exact aceeași aplicație atât într-un mediu de staging, cât și într-un mediu de producție. Nu copiezi și nu modifici chart-ul. Folosești exact aceeași structură de directoare și exact aceleași template-uri. Pentru deployment-ul de staging, îi pasezi lui Helm un fișier values custom în timpul comenzii de install. Acest fișier face override la valorile default, specificând o replică de pod, un URL de bază de date de test locală și logging la nivel de debug. Când faci deploy în producție, pasezi un fișier values complet diferit. Acest fișier de producție specifică zece replici, un URL de bază de date managed și constrângeri stricte de resurse. Helm face merge între setul unic de template-uri și fișierele values custom respective, producând două profiluri de deployment complet diferite. Puterea unui Helm chart nu constă în YAML-ul pe care îl conține, ci în granițele pe care le creează. Acesta blochează arhitectura infrastructurii în template-uri, păstrând în același timp detaliile operaționale complet fluide în values. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat, și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 8 din 10. Doar pentru că poți face template la fiecare linie dintr-un manifest Kubernetes, nu înseamnă că ar trebui să o faci. Când încerci să faci fiecare field configurabil, ajungi să ai un chart pe care nimeni nu-l poate citi, darămite să-l mențină. Acest episod acoperă best practices pentru Helm charts, regulile care împiedică configurațiile tale să se prăbușească sub propria greutate. Cea mai mare capcană în crearea unui chart este over-templating-ul. Mulți developeri tratează Helm templates ca pe un simplu script de text replacement. Asta e o confuzie frecventă. Helm execută un Go template engine pentru a produce un YAML structurat și valid. Dacă arunci o variabilă într-un fișier fără să gestionezi cu atenție indentarea și data types, YAML-ul generat va crăpa complet. Din cauza asta, ar trebui să faci template doar pentru acele values care se schimbă cu adevărat între environments. Gândește-te la image tags, replicas, resource limits sau ingress rules. Lasă field-urile structurale de bază hardcoded. Dacă un user nu are niciodată nevoie să modifice un anumit security context sau volume mount, nu le expune ca variabile. Fișierul values dot yaml acționează ca un API public pentru chart-ul tău. Când organizezi acest fișier, trebuie să echilibrezi structura cu usability-ul. Recomandarea oficială este să menții ierarhia cât mai shallow posibil. Deși ar trebui să grupezi parametrii care au legătură între ei, evită deep nesting-ul. Ia în calcul că userul va trimite overrides din command line. Să-l forțezi să scrie un path separat prin puncte, adânc de cinci niveluri, doar ca să schimbe un port number, provoacă o fricțiune inutilă. Dacă ai o configurație de web server, pune proprietățile sub un singur server key, dar păstrează proprietățile interne flat. Când denumești aceste variabile, folosește mereu camel case. Începe cu o literă mică și scrie cu majusculă prima literă a fiecărui cuvânt care urmează. Nu folosi dashes sau underscores în fișierul tău de values. Ai putea crea o variabilă numită externalPort, în loc de external dash port. Un camel case consistent previne erorile de parsing în timpul de template rendering și se potrivește cu standardele mai largi ale ecosistemului Kubernetes. De asemenea, menține o consistență strictă a type-urilor. Dacă un parametru este un integer în Kubernetes, cum ar fi un port number, lasă-l ca integer în fișierul tău de values. Nu-l pune între ghilimele ca să-l transformi într-un string. Această consecvență se aplică direct modului în care pui tag-uri pe resursele generate de chart-ul tău. Fiecare obiect are nevoie de labels standard. Helm best practices dictează folosirea de app labels oficiale Kubernetes. Mai exact, folosește prefixul app dot kubernetes dot io. Label-ul name ar trebui să fie mapat la numele chart-ului, în timp ce label-ul instance ar trebui să fie mapat la release name. De asemenea, incluzi label-ul de version și notezi că resursa este managed by Helm. Aplicarea acestor labels exacte pe fiecare deployment, pod, service și config map asigură faptul că tool-urile externe de monitorizare și service meshes pot descoperi și grupa automat componentele aplicației tale, fără configurare manuală. Iată ideea cheie. Cel mai bun Helm chart nu este cel cu cele mai multe opțiuni de configurare. Este cel care necesită cele mai puține overrides pentru a rula cu succes out of the box. Dacă vrei să ajuți la continuarea emisiunii, caută DevStoriesEU pe Patreon — apreciem foarte mult sprijinul. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 9 din 10. Construirea unui cluster de la zero este un exercițiu excelent de învățare, dar când scalezi la sute de microservicii, nu vrei să gestionezi tu singur acel control plane. Vrei ca providerul de cloud să ducă greul, astfel încât inginerii tăi să se poată concentra pe livrarea codului. Exact așa arată o implementare enterprise de Kubernetes și Helm pe Azure. Într-o arhitectură Kubernetes standard, ai un control plane care ia decizii globale și worker nodes care le execută. Să menții acel control plane highly available este extrem de dificil. Un client enterprise care face deploy pe Azure folosește de obicei Azure Kubernetes Service, sau AKS. AKS abstractizează acel control plane. Azure gestionează API server-ul, scheduler-ul și acel key-value data store. Echipa ta de operațiuni este responsabilă doar pentru acele worker nodes care îți rulează efectiv aplicațiile. Așadar, cum ajunge o aplicație de pe mașina unui developer pe acele worker nodes? Aici intervine Helm în workflow. O aplicație enterprise constă rareori dintr-un singur container. De obicei, este o colecție de microservicii, fiecare având nevoie de propriile deployments, services și configurări. În loc să gestioneze zeci de fișiere YAML statice, developerii împachetează aceste resurse într-un Helm chart. Un chart acționează ca un singur blueprint versionat pentru un microserviciu. Pentru că Helm folosește templates, developerii pot scrie logica structurală o singură dată și pot injecta valori de configurare diferite, în funcție de faptul că fac deploy pe un cluster de development, staging sau production. Înainte să ruleze ceva, codul aplicației este compilat în container images. Aceste imagini primesc push într-o locație de stocare securizată, cum ar fi un container registry. Aceste Helm charts pot fi și ele împachetate și trimise cu push într-un registry, ceea ce permite echipelor enterprise să își trateze definițiile de infrastructură exact la fel ca pe codul compilat al aplicației. Iată ideea principală. Când un release pipeline declanșează un deployment, Helm își evaluează acele templates cu valorile specifice mediului și trimite acele manifests finale către API server-ul AKS. Acel control plane AKS citește acest desired state și începe să facă scheduling pentru Pod-uri pe acele worker nodes ale tale. Nodurile contactează acel container registry, se autentifică în siguranță, fac pull la versiunile specifice de imagine și pornesc containerele. Kubernetes monitorizează constant această stare. Dacă un worker node pică, acel control plane face imediat reschedule la Pod-urile sale pe noduri sănătoase, pentru a menține acel replica count definit în Helm chart. Odată ce Pod-urile rulează, acestea trebuie să primească trafic. Un Helm chart va include de obicei un service definition pentru a expune aplicația. Când i se face deploy pe AKS, Kubernetes comunică direct cu infrastructura Azure din spate. Dacă serviciul solicită un public entry point, AKS face automat provision la un Azure Load Balancer. Acest load balancer preia traficul extern de intrare și îl rutează în siguranță în cluster, distribuindu-l către Pod-urile sănătoase. Developerii tăi nu au trebuit niciodată să atingă portalul Azure sau să scrie reguli specifice de rutare în cloud. Pur și simplu au definit un Kubernetes service standard în acel Helm chart al lor, iar platforma managed s-a ocupat de acel provisioning pentru rețeaua fizică. Adevărata putere a acestei arhitecturi enterprise este acea clean separation of concerns. Helm standardizează modul în care aplicația este definită în diferite environments, acel registry securizează artefactele versionate, iar platforma de cloud managed se asigură că infrastructura din spate rămâne efectiv activă pentru a o rula. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Kubernetes și Helm, episodul 10 din 10. Ai teoria și tool-urile. Dar când te uiți la un terminal gol, prăpastia dintre o infrastructură masivă de cloud și laptopul tău pare incredibil de mare. Să reduci această distanță este exact ideea de bază când începi cu Minikube. Un cluster Kubernetes de producție implică mai multe mașini care acționează ca control planes și worker nodes. Să faci provisioning la așa ceva în cloud costă bani, ia timp și necesită o configurare complexă de rețea. Ca developer solo sau ca o echipă mică ce proiectează o arhitectură day-one, ai nevoie de un mediu local care se comportă exact ca în producție, fără overhead. Minikube este o implementare lightweight de Kubernetes care creează o mașină virtuală sau un container direct pe laptopul tău. În acel mediu izolat, face deploy la un cluster simplu, single-node. De obicei, Kubernetes separă control plane-ul, care gestionează state-ul clusterului, de worker nodes, care rulează containerele aplicației tale. Minikube le combină. Mașina ta locală rulează un singur nod care se ocupă atât de logica de management, cât și de workload-urile efective ale aplicației. Nu este gândit să servească trafic de producție. Există exclusiv ca să poți testa în siguranță orchestrarea de containere. Aici este ideea cheie. Interfața pe care o folosești ca să interacționezi cu Minikube este identică cu cea pe care o folosești pentru un cluster masiv în cloud. Folosești tool-ul de command-line numit kubectl. Când execuți o comandă kubectl, aceasta comunică direct cu control plane-ul Minikube prin API-ul său. Nu ai de învățat nicio sintaxă specială pentru local development. Workflow-ul se potrivește perfect cu tutorialul oficial de bază Kubernetes. Inițiezi clusterul cu o simplă comandă de start. Minikube face provisioning la mediu și configurează automat kubectl să pointeze către noua ta instanță locală. De acolo, folosești kubectl pentru a crea un deployment. Îi spui control plane-ului să facă pull la o imagine specifică de container și să o ruleze. Odată ce i-ai făcut deploy, aplicația ta rulează în interiorul unui pod pe acel singur nod. Totuși, este izolată de rețeaua host-ului tău. Ca să o accesezi din browserul de pe laptop, trebuie să o expui creând un service. Un service rutează traficul de pe un port specific de pe mașina ta locală către portul corect de pe pod-ul care rulează în Minikube. Din acest punct, poți exersa fiecare funcție de bază din Kubernetes. Poți scala aplicația spunându-i lui kubectl să crească numărul de replicas. Minikube va ridica pod-uri adiționale pe lângă primul. Poți exersa rolling updates schimbând versiunea imaginii de container în deployment-ul tău. Minikube va închide gracefully vechile pod-uri și va porni altele noi, simulând un deployment cu zero-downtime. Pentru că Minikube expune un API standard de Kubernetes, tooling-ul tău extern se integrează perfect. Helm funcționează imediat. Poți instala baze de date complexe, ingress controllers sau message queues folosind Helm charts, exact așa cum ai face-o într-un mediu live. Minikube include chiar și addons built-in, cum ar fi un web dashboard local, permițându-ți să inspectezi vizual state-ul clusterului, să citești log-urile și să monitorizezi utilizarea resurselor. Adevărata putere a unui cluster local este paritatea. Când scrii o configurație de deployment sau un Helm chart care rulează cu succes pe Minikube, ai scris deja configurația exactă care va rula în cloud. Ia-ți timp să explorezi documentația oficială Kubernetes și să încerci aceste comenzi hands-on. Dacă ai sugestii de subiecte pe care ar trebui să le abordăm în următoarea noastră serie, vizitează devstories dot eu și dă-ne de veste. Asta e tot pentru astăzi. Mersi că ai ascultat, du-te și construiește ceva cool.