Salutare tuturor! Numele meu este Pavel Agaletsky. Lucrez ca lider de echipă într-o echipă care dezvoltă sistemul de livrare Lamoda. În 2018, am vorbit la conferința HighLoad++, iar astăzi aș dori să vă prezint o transcriere a raportului meu.

Subiectul meu este dedicat experienței companiei noastre în implementarea sistemelor și serviciilor în diferite medii. Începând din vremurile noastre preistorice, când am implementat toate sistemele în servere virtuale obișnuite, terminând cu trecerea treptată de la Nomad la implementarea în Kubernetes. Vă voi spune de ce am făcut-o și ce probleme am avut în acest proces.

Implementarea aplicațiilor pe VM

Să începem cu faptul că în urmă cu 3 ani toate sistemele și serviciile companiei au fost implementate pe servere virtuale obișnuite. Din punct de vedere tehnic, a fost organizat în așa fel încât tot codul pentru sistemele noastre să fie stocat și asamblat folosind instrumente automate de asamblare, folosind jenkins. Folosind Ansible, a fost lansat din sistemul nostru de control al versiunilor la serverele virtuale. Mai mult, fiecare sistem care a fost în compania noastră a fost implementat pe cel puțin 2 servere: unul dintre ele - pe cap, al doilea - pe coadă. Aceste două sisteme erau absolut identice între ele în toate setările, puterea, configurația etc. Singura diferență dintre ele a fost că head a primit trafic de utilizatori, în timp ce tail nu a primit niciodată trafic de utilizatori.

Pentru ce a fost?

Când am implementat noi versiuni ale aplicației noastre, am vrut să asigurăm o lansare fără probleme, adică fără consecințe vizibile pentru utilizatori. Acest lucru a fost realizat datorită faptului că următoarea versiune compilată folosind Ansible a fost lansată până la capăt. Acolo, oamenii care au fost implicați în implementare puteau verifica și se asigura că totul era în regulă: toate metricile, secțiunile și aplicațiile funcționau; sunt lansate scripturile necesare. Abia după ce s-au convins că totul este în regulă, traficul a fost schimbat. A început să meargă la serverul care era anterior coadă. Iar cel care era anterior cap a rămas fără trafic de utilizatori, având încă versiunea anterioară a aplicației noastre pe el.

Deci a fost perfect pentru utilizatori. Pentru că comutarea este instantanee, deoarece este pur și simplu comutarea balansierului. Puteți reveni cu ușurință la versiunea anterioară prin simpla comutare înapoi a echilibratorului. De asemenea, am putut verifica dacă aplicația a fost capabilă de producție chiar înainte de a primi trafic de utilizatori, ceea ce a fost destul de convenabil.

Ce avantaje am văzut în toate acestea?

1. În primul rând, este suficient doar funcționează. Toată lumea înțelege cum funcționează o astfel de schemă de implementare, deoarece majoritatea oamenilor s-au implementat vreodată pe servere virtuale obișnuite.
2. E de ajuns fiabil, deoarece tehnologia de implementare este simplă, testată de mii de companii. Milioane de servere sunt implementate în acest fel. E greu să spargi ceva.
3. Și în sfârșit am putea obține desfăşurări atomice. Implementări care apar simultan pentru utilizatori, fără o etapă notabilă de comutare între versiunea veche și cea nouă.

Dar am văzut și câteva neajunsuri în toate acestea:

1. Pe lângă mediul de producție, mediul de dezvoltare, există și alte medii. De exemplu, qa și preproducție. La acea vreme aveam multe servere și aproximativ 60 de servicii. Din acest motiv a fost necesar pentru fiecare serviciu, mențineți cea mai recentă versiune pentru acesta mașină virtuală. Mai mult, dacă doriți să actualizați biblioteci sau să instalați noi dependențe, trebuie să faceți acest lucru în toate mediile. De asemenea, trebuia să sincronizați ora la care urmează să implementați următoarea versiune nouă a aplicației dvs. cu ora la care devops efectuează setările de mediu necesare. În acest caz, este ușor să ajungem într-o situație în care mediul nostru va fi oarecum diferit în toate mediile deodată. De exemplu, într-un mediu QA vor exista unele versiuni de biblioteci, iar într-un mediu de producție vor exista altele diferite, ceea ce va duce la probleme.
2. Dificultate la actualizarea dependențelor aplicatia ta. Nu depinde de tine, ci de cealaltă echipă. Și anume din echipa devops care întreține serverele. Trebuie să le oferiți o sarcină adecvată și o descriere a ceea ce doriți să faceți.
3. La acea vreme, am vrut să împărțim și monoliții mari mari pe care le aveam în servicii mici separate, din moment ce am înțeles că vor fi din ce în ce mai multe. La acel moment, aveam deja peste 100. Pentru fiecare serviciu nou, era necesar să se creeze o nouă mașină virtuală separată, care trebuia, de asemenea, întreținută și implementată. În plus, nu aveți nevoie de o mașină, ci de cel puțin două. La toate acestea se adaugă mediul QA. Acest lucru cauzează probleme și vă face mai dificilă construirea și rularea sistemelor noi. proces complex, costisitor și lung.

Prin urmare, am decis că ar fi mai convenabil să trecem de la implementarea mașinilor virtuale obișnuite la implementarea aplicațiilor noastre într-un container docker. Dacă aveți docker, aveți nevoie de un sistem care să poată rula aplicația într-un cluster, deoarece nu puteți pur și simplu să ridicați un container. De obicei, doriți să urmăriți câte containere sunt ridicate, astfel încât acestea să se ridice automat. Din acest motiv, a trebuit să selectăm un sistem de control.

Ne-am gândit mult timp pe care am putea lua. Cert este că la acel moment această stivă de implementare pe serverele virtuale obișnuite era oarecum depășită, deoarece nu aveau cele mai recente versiuni de sisteme de operare. La un moment dat, a existat chiar și FreeBSD, care nu era foarte convenabil de susținut. Am înțeles că trebuie să migrăm la docker cât mai repede posibil. Devopii noștri s-au uitat la experiența lor existentă cu diferite soluții și au ales un sistem precum Nomad.

Treceți la Nomad

Nomad este un produs al HashiCorp. Sunt cunoscuți și pentru celelalte soluții:

"Consul" este un instrument pentru descoperirea serviciilor.

"Terraform" - un sistem de administrare a serverelor care vă permite să le configurați prin configurare, așa-numita infrastructură-as-a-code.

"Vagabond" vă permite să implementați mașini virtuale local sau în cloud prin fișiere de configurare specifice.

Nomad la acea vreme părea o soluție destul de simplă la care putea fi trecută rapid fără a schimba întreaga infrastructură. În plus, este destul de ușor de învățat. De aceea l-am ales ca sistem de filtrare pentru containerul nostru.

De ce aveți nevoie pentru a vă implementa sistemul pe Nomad?

1. În primul rând ai nevoie imagine docker aplicatia ta. Trebuie să îl construiți și să îl plasați în depozitul de imagini docker. În cazul nostru, aceasta este o artefactorie - un sistem care vă permite să împingeți diferite artefacte de diferite tipuri în el. Poate stoca arhive, imagini docker, pachete PHP de compoziție, pachete NPM și așa mai departe.
2. De asemenea, nevoie Fișier de configurare, care îi va spune lui Nomad ce, unde și în ce cantitate doriți să implementați.

Când vorbim despre Nomad, folosește limbajul HCL ca format de fișier de informații, ceea ce înseamnă Limbajul de configurare HashiCorp. Acesta este un superset de Yaml care vă permite să vă descrieți serviciul în termeni Nomad.

Vă permite să spuneți câte containere doriți să implementați, din ce imagini să le transmiteți diferiți parametri în timpul implementării. Astfel, alimentați acest fișier către Nomad, iar acesta lansează containerele în producție conform acestuia.

În cazul nostru, ne-am dat seama că simpla scriere a fișierelor HCL absolut identice pentru fiecare serviciu nu ar fi foarte convenabilă, deoarece există o mulțime de servicii și uneori doriți să le actualizați. Se întâmplă ca un serviciu să fie implementat nu într-o singură instanță, ci într-o varietate de altele diferite. De exemplu, unul dintre sistemele pe care le avem în producție are peste 100 de instanțe în producție. Acestea rulează din aceleași imagini, dar diferă în setările de configurare și fișierele de configurare.

Prin urmare, am decis că ar fi convenabil pentru noi să stocăm toate fișierele noastre de configurare pentru implementare într-un singur depozit comun. Astfel erau vizibile: erau ușor de întreținut și puteam vedea ce sisteme avem. Dacă este necesar, este ușor să actualizați sau să schimbați ceva. Adăugarea unui sistem nou nu este, de asemenea, dificilă - trebuie doar să creați un fișier de configurare în noul director. În interiorul acestuia se află următoarele fișiere: service.hcl, care conține o descriere a serviciului nostru, și câteva fișiere env care permit configurarea tocmai acestui serviciu, fiind implementat în producție.

Cu toate acestea, unele dintre sistemele noastre sunt implementate în producție nu într-o singură copie, ci în mai multe simultan. Prin urmare, am decis că ar fi convenabil pentru noi să stocăm nu configurațiile în forma lor pură, ci forma lor șablon. Și noi am ales jinja 2. În acest format, stocăm atât configurațiile serviciului în sine, cât și fișierele env necesare pentru acesta.

În plus, am plasat în depozit un script de implementare comun tuturor proiectelor, care vă permite să lansați și să vă implementați serviciul în producție, în mediul dorit, în ținta dorită. În cazul în care am transformat configurația noastră HCL într-un șablon, apoi fișierul HCL, care înainte era o configurație obișnuită Nomad, în acest caz a început să arate puțin diferit.

Adică, am înlocuit unele variabile de locație de configurare cu variabile inserate care sunt preluate din fișierele env sau din alte surse. În plus, am avut posibilitatea de a colecta fișiere HCL în mod dinamic, adică putem folosi nu numai inserții de variabile obișnuite. Deoarece jinja acceptă bucle și condiții, puteți crea și fișiere de configurare acolo, care se schimbă în funcție de locul exact în care implementați aplicațiile.

De exemplu, doriți să implementați serviciul în pre-producție și producție. Să presupunem că în pre-producție nu doriți să rulați scripturi cron, ci doriți doar să vedeți serviciul pe un domeniu separat pentru a vă asigura că funcționează. Pentru oricine implementează serviciul, procesul pare foarte simplu și transparent. Tot ce trebuie să faceți este să executați fișierul deploy.sh, să specificați ce serviciu doriți să implementați și către ce țintă. De exemplu, doriți să implementați un anumit sistem în Rusia, Belarus sau Kazahstan. Pentru a face acest lucru, pur și simplu modificați unul dintre parametri și veți avea fișierul de configurare corect.

Când serviciul Nomad este deja implementat în clusterul dvs., arată astfel.

În primul rând, aveți nevoie de un fel de echilibrator în exterior, care va primi tot traficul utilizatorilor. Acesta va lucra împreună cu Consul și va afla de la acesta unde, pe ce nod, la ce adresă IP se află un anumit serviciu care corespunde unui anumit nume de domeniu. Serviciile în Consul vin chiar de la Nomad. Deoarece acestea sunt produse de la aceeași companie, sunt destul de legate între ele. Putem spune că Nomad out of the box poate înregistra toate serviciile lansate în el în interiorul Consul.

Odată ce echilibratorul de încărcare front-end știe la ce serviciu să trimită trafic, îl redirecționează către containerul corespunzător sau mai multe containere care se potrivesc cu aplicația dvs. Desigur, este necesar să ne gândim și la siguranță. Chiar dacă toate serviciile rulează pe aceleași mașini virtuale în containere, acest lucru necesită de obicei împiedicarea accesului gratuit de la orice serviciu la oricare altul. Am realizat acest lucru prin segmentare. Fiecare serviciu a fost lansat în propria sa rețea virtuală, pe care au fost prescrise reguli de rutare și reguli pentru a permite/interzice accesul la alte sisteme și servicii. Ele ar putea fi localizate atât în ​​interiorul acestui cluster, cât și în afara acestuia. De exemplu, dacă doriți să împiedicați un serviciu să se conecteze la o anumită bază de date, acest lucru se poate face prin segmentarea la nivel de rețea. Adică, chiar și din greșeală, nu vă puteți conecta accidental de la mediul de testare la baza de date de producție.

Cât ne-a costat tranziția din punct de vedere al resurselor umane?

Tranziția întregii companii la Nomad a durat aproximativ 5-6 luni. Ne-am mutat serviciu cu serviciu, dar într-un ritm destul de rapid. Fiecare echipă a trebuit să-și creeze propriile containere pentru servicii.

Am adoptat o astfel de abordare încât fiecare echipă este responsabilă pentru imaginile docker ale sistemelor lor în mod independent. DevOps oferă infrastructura generală necesară pentru implementare, adică suport pentru cluster-ul în sine, suport pentru sistemul CI și așa mai departe. Și la acel moment, aveam peste 60 de sisteme mutate la Nomad, ceea ce se ridica la aproximativ 2 mii de containere.

Devops este responsabil pentru infrastructura generală a tot ceea ce este legat de implementare și servere. Și fiecare echipă de dezvoltare, la rândul său, este responsabilă pentru implementarea containerelor pentru sistemul său specific, deoarece echipa este cea care știe de ce are nevoie în general într-un anumit container.

Motive pentru a abandona Nomad

Ce avantaje am obținut trecând la implementare folosind Nomad și Docker, printre altele?

1. Noi asigurate conditii egale pentru toate mediile. În dezvoltare, mediu QA, pre-producție, producție, se folosesc aceleași imagini container, cu aceleași dependențe. În consecință, practic nu aveți nicio șansă ca ceea ce va ajunge în producție să nu fie ceea ce ați testat anterior la nivel local sau în mediul dumneavoastră de testare.
2. De asemenea, am constatat că este suficient ușor de adăugat un nou serviciu. Din punct de vedere al implementării, orice sistem nou este lansat foarte simplu. Doar mergeți la depozitul care stochează configurațiile, adăugați o altă configurație pentru sistemul dvs. acolo și sunteți gata. Vă puteți implementa sistemul în producție fără niciun efort suplimentar din partea devops.
3. toate fișierele de configurare într-un singur depozit comun s-a dovedit a fi în curs de revizuire. La momentul în care ne-am implementat sistemele folosind servere virtuale, am folosit Ansible, în care configurațiile se aflau în același depozit. Cu toate acestea, pentru majoritatea dezvoltatorilor, acest lucru a fost puțin mai dificil de lucrat. Aici volumul de configurații și cod pe care trebuie să le adăugați pentru a implementa serviciul a devenit mult mai mic. În plus, este foarte ușor pentru devopți să o repare sau să o schimbe. În cazul tranzițiilor, de exemplu, la o nouă versiune de Nomad, aceștia pot prelua și actualiza în bloc toate fișierele de operare situate în același loc.

Dar am întâlnit și câteva dezavantaje:

S-a dovedit că noi nu a putut realiza implementări fără întreruperi în cazul Nomadului. La lansarea containerelor în diferite condiții, s-ar putea dovedi a fi în funcțiune, iar Nomad l-a perceput ca pe un container gata să primească trafic. Acest lucru s-a întâmplat înainte ca aplicația din interiorul acesteia să aibă chiar șansa de a se lansa. Din acest motiv, sistemul a început să producă 500 de erori pentru o perioadă scurtă de timp, deoarece traficul a început să meargă către un container care nu era încă pregătit să-l accepte.

Am întâlnit câteva de mlaștini. Cea mai semnificativă eroare este că Nomad nu gestionează foarte bine un cluster mare dacă aveți multe sisteme și containere. Când doriți să scoateți unul dintre serverele incluse în clusterul Nomad pentru întreținere, există o probabilitate destul de mare ca clusterul să nu se simtă foarte bine și să se destrame. Unele containere pot, de exemplu, să cadă și să nu se ridice - acest lucru vă va costa mult mai târziu dacă toate sistemele dvs. de producție sunt situate într-un cluster gestionat de Nomad.

Așa că am decis să ne gândim unde ar trebui să mergem mai departe. În acel moment, am devenit mult mai conștienți de ceea ce doream să realizăm. Și anume: vrem fiabilitate, puțin mai multe funcții decât oferă Nomad și un sistem mai matur, mai stabil.

În acest sens, alegerea noastră a căzut pe Kubernetes ca cea mai populară platformă pentru lansarea clusterelor. Mai ales având în vedere că dimensiunea și numărul containerelor noastre a fost suficient de mare. În astfel de scopuri, Kubernetes părea a fi cel mai potrivit sistem pe care l-am putea privi.

Trecerea la Kubernetes

Vă voi spune puțin despre conceptele de bază ale Kubernetes și despre modul în care diferă de Nomad.

În primul rând, cel mai de bază concept din Kubernetes este conceptul de pod. Păstaie este un grup de unul sau mai multe containere care funcționează întotdeauna împreună. Și funcționează întotdeauna ca și cum ar fi strict pe o singură mașină virtuală. Sunt accesibile unul altuia prin IP 127.0.0.1 pe diferite porturi.

Să presupunem că aveți o aplicație PHP care constă din nginx și php-fpm - schema clasică. Cel mai probabil, veți dori să păstrați împreună ambele containere nginx și php-fpm în orice moment. Kubernetes vă permite să realizați acest lucru, descriindu-le ca un singur pod comun. Este exact ceea ce nu am putut obține cu Nomad.

Al doilea concept este desfășurarea. Faptul este că podul în sine este un lucru efemer; începe și dispare. Doriți să vă ucideți mai întâi toate containerele anterioare și apoi să lansați versiuni noi deodată sau doriți să le lansați treptat? Acesta este procesul de care este responsabil conceptul de implementare. Acesta descrie modul în care implementați podurile, în ce cantitate și cum să le actualizați.

Al treilea concept este serviciu. Serviciul dvs. este de fapt sistemul dvs., care primește o parte de trafic și apoi îl redirecționează către unul sau mai multe poduri corespunzătoare serviciului dvs. Adică, vă permite să spuneți că tot traficul de intrare către un astfel de serviciu cu un astfel de nume trebuie trimis către aceste poduri specifice. Și, în același timp, vă oferă echilibrarea traficului. Adică, puteți lansa două poduri ale aplicației dvs. și tot traficul de intrare va fi echilibrat în mod egal între podurile aferente acestui serviciu.

Iar al patrulea concept de bază este Pătrundere. Acesta este un serviciu care rulează pe un cluster Kubernetes. Acționează ca un echilibrator de încărcare extern care preia toate solicitările. Folosind API-ul Kubernetes, Ingress poate determina unde trebuie trimise aceste solicitări. Mai mult, face acest lucru foarte flexibil. Puteți spune că toate solicitările către această gazdă și cutare URL sunt trimise acestui serviciu. Și aceste solicitări care vin către această gazdă și către o altă adresă URL sunt trimise către alt serviciu.

Cel mai tare lucru din punctul de vedere al cuiva care dezvoltă o aplicație este că ești capabil să gestionezi totul singur. Setând configurația Ingress, puteți trimite tot traficul care vine către un astfel de API la containere separate scrise, de exemplu, în Go. Dar acest trafic, care vine pe același domeniu, dar către un alt URL, ar trebui trimis către containere scrise în PHP, unde există multă logică, dar nu sunt foarte rapide.

Dacă comparăm toate aceste concepte cu Nomad, putem spune că primele trei concepte sunt toate împreună Serviciu. Și ultimul concept este absent în Nomad însuși. Am folosit un echilibrator extern ca acesta: ar putea fi haproxy, nginx, nginx+ și așa mai departe. În cazul unui cub, nu trebuie să introduceți separat acest concept suplimentar. Cu toate acestea, dacă te uiți la Ingress intern, este fie nginx, haproxy, fie traefik, dar un fel de integrat în Kubernetes.

Toate conceptele pe care le-am descris sunt, de fapt, resurse care există în cadrul unui cluster Kubernetes. Pentru a le descrie în cub, se folosește un format yaml, care este mai ușor de citit și mai familiar decât fișierele HCL în cazul Nomad. Dar structural descriu același lucru în cazul, de exemplu, a podului. Ei spun - vreau să desfășoare așa și așa poduri acolo, cu așa și așa imagini, în așa și așa cantități.

În plus, ne-am dat seama că nu dorim să creăm manual fiecare resursă individuală: implementare, servicii, Ingress etc. În schimb, am vrut să descriem fiecare dintre sistemele noastre în termeni de Kubernetes în timpul implementării, astfel încât să nu fie nevoie să recream manual toate dependențele de resurse necesare în ordinea corectă. Helm a fost ales ca sistem care ne-a permis să facem acest lucru.

Concepte de bază în Helm

Helm este manager de pachete pentru Kubernetes. Este foarte asemănător cu modul în care funcționează managerii de pachete în limbaje de programare. Acestea vă permit să stocați un serviciu constând, de exemplu, din implementare nginx, implementare php-fpm, config for Ingress, configmaps (aceasta este o entitate care vă permite să setați env și alți parametri pentru sistemul dvs.) sub formă de așa- numite diagrame. În același timp Helm rulează peste Kubernetes. Adică, acesta nu este un fel de sistem care stă deoparte, ci doar un alt serviciu lansat în interiorul cubului. Interacționați cu acesta prin intermediul API-ului său printr-o comandă de consolă. Comoditatea și frumusețea sa este că, chiar dacă cârma se rupe sau o eliminați din cluster, serviciile dvs. nu vor dispărea, deoarece cârma servește în esență doar la pornirea sistemului. Kubernetes însuși este apoi responsabil pentru performanța și starea serviciilor.

Ne-am dat seama și de asta șablonare, pe care anterior am fost forțați să o facem noi prin introducerea jinja în configurațiile noastre, este una dintre principalele caracteristici ale helm. Toate configurațiile pe care le creați pentru sistemele dvs. sunt stocate în helm sub formă de șabloane, puțin asemănătoare cu jinja, dar, de fapt, folosind șablonul limbajului Go, în care este scris helm, precum Kubernetes.

Helm mai adaugă câteva concepte pentru noi.

Diagramă - aceasta este o descriere a serviciului dvs. În alți manageri de pachete s-ar numi pachet, pachet sau ceva similar. Aici se numește diagramă.

Valori sunt variabilele pe care doriți să le utilizați pentru a vă construi configurațiile din șabloane.

Eliberați. De fiecare dată când un serviciu care este implementat folosind helm primește o versiune incrementală a versiunii. Helm își amintește care era configurația serviciului în versiunea anterioară, versiunea anterioară și așa mai departe. Prin urmare, dacă trebuie să derulați înapoi, rulați comanda helm callback, indicând-o către versiunea anterioară. Chiar dacă configurația corespunzătoare din depozitul dvs. nu este disponibilă în momentul derulării înapoi, Helm își va aminti în continuare ce a fost și va derula sistemul dvs. la starea în care se afla în versiunea anterioară.

În cazul în care folosim helm, configurațiile obișnuite pentru Kubernetes se transformă, de asemenea, în șabloane în care este posibil să se utilizeze variabile, funcții și să se aplice instrucțiuni condiționale. În acest fel, puteți colecta configurația serviciului în funcție de mediu.

În practică, am decis să facem lucrurile puțin diferit decât am făcut cu Nomad. Dacă în Nomad atât configurațiile de implementare, cât și n-variabilele necesare pentru implementarea serviciului nostru au fost stocate într-un singur depozit, aici am decis să le împărțim în două depozite separate. Depozitul „deploy” stochează numai n-variabile necesare pentru implementare, iar depozitul „helm” stochează configurații sau diagrame.

Ce ne-a dat asta?

În ciuda faptului că nu stocăm date cu adevărat sensibile în fișierele de configurare în sine. De exemplu, parolele pentru bazele de date. Ele sunt stocate ca secrete în Kubernetes, dar, cu toate acestea, există încă anumite lucruri acolo la care nu vrem să dăm acces tuturor. Prin urmare, accesul la depozitul „deploy” este mai limitat, iar depozitul „helm” conține pur și simplu o descriere a serviciului. Din acest motiv, poate fi accesat în siguranță de o gamă mai largă de persoane.

Deoarece avem nu numai producție, ci și alte medii, datorită acestei separări putem reutiliza diagramele noastre de conducere pentru a implementa servicii nu numai în producție, ci și, de exemplu, într-un mediu QA. Chiar și pentru a le implementa local folosind Minikube - acesta este un lucru pentru rularea Kubernetes local.

În interiorul fiecărui depozit, am lăsat o diviziune în directoare separate pentru fiecare serviciu. Adică, în interiorul fiecărui director există șabloane legate de diagrama corespunzătoare și care descriu resursele care trebuie implementate pentru a lansa sistemul nostru. Am lăsat doar envs în depozitul „deploy”. În acest caz, nu am folosit șablonarea folosind jinja, deoarece helm în sine oferă șablonare din cutie - aceasta este una dintre funcțiile sale principale.

Am lăsat un script de implementare - deploy.sh, care simplifică și standardizează lansarea pentru implementare folosind helm. Așadar, pentru oricine dorește să implementeze, interfața de implementare arată exact la fel ca la implementarea prin Nomad. Același deploy.sh, numele serviciului dvs. și unde doriți să-l implementați. Acest lucru face ca cârma să pornească intern. La rândul său, colectează configurații din șabloane, inserează fișierele de valori necesare în ele, apoi le implementează, lansându-le în Kubernetes.

Constatări

Serviciul Kubernetes pare a fi mai complex decât Nomad.

Aici traficul de ieșire vine la Ingress. Acesta este doar controlerul frontal, care preia toate solicitările și le trimite ulterior către serviciile corespunzătoare datelor de solicitare. Le determină pe baza configurațiilor care fac parte din descrierea aplicației dvs. din helm și pe care dezvoltatorii le stabilesc singuri. Serviciul trimite cereri către podurile sale, adică containerele specifice, echilibrând traficul de intrare între toate containerele care aparțin acestui serviciu. Și, desigur, nu ar trebui să uităm că nu ar trebui să trecem nicăieri de la securitate la nivel de rețea. Prin urmare, segmentarea funcționează într-un cluster Kubernetes, care se bazează pe etichetare. Toate serviciile au anumite etichete la care sunt asociate drepturile de acces ale serviciilor la anumite resurse externe/interne din interiorul sau din afara clusterului.

Pe măsură ce am făcut tranziția, am văzut că Kubernetes avea toate capabilitățile Nomad, pe care le folosisem anterior și, de asemenea, a adăugat o mulțime de lucruri noi. Poate fi extins prin pluginuri și, de fapt, prin tipuri de resurse personalizate. Adică, aveți ocazia nu doar să folosiți ceva ce vine cu Kubernetes din cutie, ci și să vă creați propria resursă și serviciu care vă va citi resursa. Acest lucru vă oferă opțiuni suplimentare pentru a vă extinde sistemul fără a fi nevoie să reinstalați Kubernetes și fără a necesita modificări.

Un exemplu de astfel de utilizare este Prometheus, care rulează în clusterul nostru Kubernetes. Pentru ca acesta să înceapă să colecteze valori de la un anumit serviciu, trebuie să adăugăm un tip suplimentar de resursă, așa-numitul monitor al serviciului, la descrierea serviciului. Prometheus, datorită faptului că poate citi un tip de resursă personalizat atunci când este lansat în Kubernetes, începe automat să colecteze valori din noul sistem. Este destul de convenabil.

Prima implementare pe care am făcut-o în Kubernetes a fost în martie 2018. Și în acest timp nu am avut niciodată probleme cu el. Funcționează destul de stabil, fără erori semnificative. În plus, îl putem extinde și mai mult. Astăzi avem destule capacități pe care le are și ne place foarte mult ritmul de dezvoltare al Kubernetes. În prezent, peste 3000 de containere sunt în Kubernetes. Clusterul ocupă mai multe Noduri. În același timp, este util, stabil și foarte controlabil.

Sursa: www.habr.com