Kubernetes este un instrument excelent pentru rularea containerelor Docker într-un mediu de producție în cluster. Cu toate acestea, există probleme pe care Kubernetes nu le poate rezolva. Pentru implementări frecvente de producție, avem nevoie de o implementare albastră/verde complet automatizată pentru a evita timpii de nefuncționare în proces, care trebuie, de asemenea, să gestioneze solicitările HTTP externe și să efectueze descărcări SSL. Acest lucru necesită integrarea cu un echilibrator de încărcare, cum ar fi ha-proxy. O altă provocare este scalarea semi-automată a clusterului Kubernetes în sine atunci când rulează într-un mediu cloud, de exemplu reducerea parțială a clusterului pe timp de noapte.
Deși Kubernetes nu are aceste funcții din cutie, oferă un API pe care îl puteți folosi pentru a rezolva probleme similare. Instrumente pentru implementarea automată Blue/Green și scalarea unui cluster Kubernetes au fost dezvoltate ca parte a proiectului Cloud RTI, care a fost creat pe baza open-source.
Acest articol, o transcriere video, vă arată cum să configurați Kubernetes împreună cu alte componente open source pentru a crea un mediu pregătit pentru producție, care acceptă codul de la un commit git fără timp de nefuncționare în producție.
Așadar, odată ce aveți acces la aplicațiile dvs. din lumea exterioară, puteți începe să configurați complet automatizarea, adică să o aduceți la stadiul în care puteți efectua un git commit și vă asigurați că acest git commit ajunge în producție. Desigur, atunci când implementăm acești pași, atunci când implementăm implementarea, nu dorim să întâlnim timpi de nefuncționare. Deci, orice automatizare în Kubernetes începe cu API-ul.
Kubernetes nu este un instrument care poate fi folosit productiv din cutie. Desigur, puteți face asta, utilizați kubectl și așa mai departe, dar totuși API-ul este cel mai interesant și util lucru despre această platformă. Folosind API-ul ca set de funcții, puteți accesa aproape orice doriți să faceți în Kubernetes. kubectl însuși folosește și API-ul REST.
Acesta este REST, așa că puteți folosi orice limbă sau instrument pentru a lucra cu acest API, dar viața vă va fi mult mai ușoară de biblioteci personalizate. Echipa mea a scris 2 astfel de biblioteci: una pentru Java/OSGi și una pentru Go. Al doilea nu este folosit des, dar în orice caz aveți aceste lucruri utile la dispoziție. Sunt un proiect open-source parțial licențiat. Există multe astfel de biblioteci pentru diferite limbi, așa că le puteți alege pe cele care vi se potrivesc cel mai bine.
Deci, înainte de a începe automatizarea implementării, trebuie să vă asigurați că procesul nu va fi supus niciunui timp de nefuncționare. De exemplu, echipa noastră efectuează implementări de producție în mijlocul zilei, când oamenii folosesc cel mai mult aplicațiile, așa că este important să se evite întârzierile în acest proces. Pentru a evita timpul de nefuncționare, sunt utilizate 2 metode: implementare albastru/verde sau actualizare continuă. În acest din urmă caz, dacă aveți 5 replici ale aplicației în rulare, acestea sunt actualizate secvențial una după alta. Această metodă funcționează excelent, dar nu este potrivită dacă aveți diferite versiuni ale aplicației care rulează simultan în timpul procesului de implementare. În acest caz, puteți actualiza interfața cu utilizatorul în timp ce backend-ul rulează versiunea veche, iar aplicația nu va mai funcționa. Prin urmare, din punct de vedere al programării, lucrul în astfel de condiții este destul de dificil.
Acesta este unul dintre motivele pentru care preferăm să folosim implementarea albastru/verde pentru a automatiza implementarea aplicațiilor noastre. Cu această metodă, trebuie să vă asigurați că o singură versiune a aplicației este activă la un moment dat.
Mecanismul de implementare albastru/verde arată astfel. Primim trafic pentru aplicațiile noastre prin ha-proxy, care îl redirecționează către replicile care rulează ale aplicației din aceeași versiune.
Când se face o nouă implementare, folosim Deployer, care primește noile componente și implementează noua versiune. Implementarea unei noi versiuni a unei aplicații înseamnă că un nou set de replici este „ridicat”, după care aceste replici ale noii versiuni sunt lansate într-un pod separat, nou. Cu toate acestea, ha-proxy nu știe nimic despre ei și nu le direcționează încă nicio sarcină de lucru.
Prin urmare, în primul rând, este necesar să se efectueze o verificare a performanței noilor versiuni de verificare a stării de sănătate pentru a se asigura că replicile sunt gata să deservească încărcarea.
Toate componentele de implementare trebuie să accepte o formă de verificare a stării de sănătate. Aceasta poate fi o verificare a apelurilor HTTP foarte simplă, când primiți un cod cu starea 200, sau o verificare mai aprofundată, în care verificați conexiunea replicilor cu baza de date și alte servicii, stabilitatea conexiunilor mediului dinamic și dacă totul pornește și funcționează corect. Acest proces poate fi destul de complex.
După ce sistemul verifică că toate replicile actualizate funcționează, Deployer va actualiza configurația și va transmite confd-ul corect, care va reconfigura ha-proxy.
Abia după aceasta traficul va fi direcționat către podul cu replici ale noii versiuni, iar vechiul pod va dispărea.
Acest mecanism nu este o caracteristică a Kubernetes. Conceptul de implementare albastru/verde există de mult timp și a folosit întotdeauna un echilibrator de încărcare. Mai întâi, direcționați tot traficul către versiunea veche a aplicației, iar după actualizare, îl transferați complet în noua versiune. Acest principiu este folosit nu numai în Kubernetes.
Acum vă voi prezenta o nouă componentă de implementare - Deployer, care efectuează verificări de sănătate, reconfigurează proxy-urile și așa mai departe. Acesta este un concept care nu se aplică lumii exterioare și există în interiorul Kubernetes. Vă voi arăta cum vă puteți crea propriul concept Deployer folosind instrumente open-source.
Deci, primul lucru pe care îl face Deployer este să creeze un controler de replicare RC folosind API-ul Kubernetes. Acest API creează poduri și servicii pentru implementare ulterioară, adică creează un cluster complet nou pentru aplicațiile noastre. De îndată ce RC este convins că replicile au început, va efectua o verificare de sănătate a funcționalității acestora. Pentru a face acest lucru, Deployer folosește comanda GET /health. Rulează componentele de scanare adecvate și verifică toate elementele care sprijină funcționarea clusterului.
După ce toate podurile și-au raportat starea de sănătate, Deployer creează un nou element de configurare - stocarea distribuită etcd, care este utilizată intern de Kubernetes, inclusiv stocarea configurației echilibrului de încărcare. Scriem date în etcd și un mic instrument numit confd monitorizează etcd pentru date noi.
Dacă detectează orice modificări ale configurației inițiale, generează un nou fișier de setări și îl transferă la ha-proxy. În acest caz, ha-proxy repornește fără a pierde nicio conexiune și adresează încărcarea către servicii noi care permit funcționarea noii versiuni a aplicațiilor noastre.
După cum puteți vedea, în ciuda abundenței componentelor, nu este nimic complicat aici. Trebuie doar să acordați mai multă atenție API și etcd. Vreau să vă spun despre deployerul open-source pe care noi înșine îl folosim - Amdatu Kubernetes Deployer.
Este un instrument pentru orchestrarea implementărilor Kubernetes și are următoarele caracteristici:
- Implementare albastru/verde;
- configurarea unui echilibrator de sarcină extern;
- managementul descriptorilor de implementare;
- gestionarea implementării efective;
- verificarea funcționalității controalelor de sănătate în timpul implementării;
- implementarea variabilelor de mediu în pod-uri.
Acest Deployer este construit pe partea superioară a API-ului Kubernetes și oferă o API REST pentru gestionarea handle-urilor și implementărilor, precum și un API Websocket pentru jurnalele în flux în timpul procesului de implementare.
Acesta pune datele de configurare a echilibrului de încărcare în etcd, astfel încât să nu trebuie să utilizați ha-proxy cu suport din nou, ci să utilizați cu ușurință propriul fișier de configurare a echilibrului de încărcare. Amdatu Deployer este scris în Go, ca și Kubernetes însuși și este licențiat de Apache.
Înainte de a începe să folosesc această versiune a deployerului, am folosit următorul descriptor de implementare, care specifică parametrii de care am nevoie.
Unul dintre parametrii importanți ai acestui cod este activarea indicatorului „useHealthCheck”. Trebuie să precizăm că trebuie efectuată o verificare a stării de spirit în timpul procesului de implementare. Această setare poate fi dezactivată atunci când implementarea folosește containere terță parte care nu trebuie să fie verificate. Acest descriptor indică, de asemenea, numărul de replici și adresa URL frontală de care are nevoie ha-proxy. La sfârșit este indicatorul de specificare a podului „podspec”, care apelează Kubernetes pentru informații despre configurația porturilor, imaginea etc. Acesta este un descriptor JSON destul de simplu.
Un alt instrument care face parte din proiectul open-source Amdatu este Deploymentctl. Are o interfață de utilizare pentru configurarea implementărilor, stochează istoricul implementărilor și conține webhook-uri pentru apeluri inverse de la utilizatori și dezvoltatori terți. Este posibil să nu utilizați interfața de utilizare, deoarece Amdatu Deployer în sine este un API REST, dar această interfață vă poate face implementarea mult mai ușoară fără a implica niciun API. Deploymentctl este scris în OSGi/Vertx folosind Angular 2.
Acum voi demonstra cele de mai sus pe ecran folosind o înregistrare pre-înregistrată, astfel încât să nu trebuie să așteptați. Vom implementa o aplicație Go simplă. Nu vă faceți griji dacă nu ați încercat Go înainte, este o aplicație foarte simplă, așa că ar trebui să vă puteți da seama.
Aici creăm un server HTTP care răspunde doar la /health, așa că această aplicație testează doar verificarea sănătății și nimic altceva. Dacă verificarea trece, se utilizează structura JSON prezentată mai jos. Conține versiunea aplicației care va fi implementată de către implementator, mesajul pe care îl vedeți în partea de sus a fișierului și tipul de date boolean - indiferent dacă aplicația noastră funcționează sau nu.
Am trișat puțin cu ultima linie, pentru că am plasat o valoare booleană fixă în partea de sus a fișierului, care pe viitor mă va ajuta să implementez chiar și o aplicație „nesănătoasă”. Ne vom ocupa de asta mai târziu.
Asadar, haideti sa începem. În primul rând, verificăm prezența oricăror pod-uri care rulează folosind comanda ~ kubectl get pods și, pe baza absenței unui răspuns de la adresa URL de front-end, ne asigurăm că în prezent nu se fac implementări.
În continuare, pe ecran vedeți interfața Deploymentctl pe care am menționat-o, în care sunt setați parametrii de implementare: spațiu de nume, numele aplicației, versiunea de implementare, numărul de replici, adresa URL front-end, numele containerului, imaginea, limitele resurselor, numărul portului pentru verificarea stării de sănătate, etc. Limitele de resurse sunt foarte importante, deoarece vă permit să utilizați cantitatea maximă posibilă de hardware. Aici puteți vizualiza și jurnalul de implementare.
Dacă acum repetați comanda ~ kubectl get pods, puteți vedea că sistemul „îngheață” timp de 20 de secunde, timp în care ha-proxy este reconfigurat. După aceasta, podul pornește, iar replica noastră poate fi văzută în jurnalul de implementare.
Am tăiat așteptarea de 20 de secunde din videoclip, iar acum puteți vedea pe ecran că prima versiune a aplicației a fost implementată. Toate acestea au fost făcute folosind doar UI.
Acum să încercăm a doua versiune. Pentru a face acest lucru, schimb mesajul aplicației din „Bună ziua, Kubernetes!” pe „Hello, Deployer!”, sistemul creează această imagine și o plasează în registrul Docker, după care pur și simplu facem clic din nou pe butonul „Deploy” din fereastra Deploymentctl. În acest caz, jurnalul de implementare este lansat automat în același mod în care sa întâmplat la implementarea primei versiuni a aplicației.
Comanda ~ kubectl get pods arată că în prezent există 2 versiuni ale aplicației care rulează, dar frontend-ul arată că încă rulăm versiunea 1.
Echilibratorul de încărcare așteaptă finalizarea verificării de sănătate înainte de a redirecționa traficul către noua versiune. După 20 de secunde, trecem la curl și vedem că acum avem versiunea 2 a aplicației implementată, iar prima a fost ștearsă.
Aceasta a fost implementarea unei aplicații „sănătoase”. Să vedem ce se întâmplă dacă pentru o nouă versiune a aplicației schimb parametrul Healthy din true în false, adică încerc să implementez o aplicație nesănătoasă care a eșuat verificarea de sănătate. Acest lucru se poate întâmpla dacă unele erori de configurare au fost făcute în aplicație în stadiul de dezvoltare și a fost trimisă în producție sub acest formular.
După cum puteți vedea, implementarea parcurge toți pașii de mai sus și ~kubectl get pods arată că ambele pod-uri rulează. Dar, spre deosebire de implementarea anterioară, jurnalul arată starea de expirare. Adică, din cauza faptului că verificarea de sănătate a eșuat, noua versiune a aplicației nu poate fi implementată. Ca rezultat, vedeți că sistemul a revenit la utilizarea vechei versiuni a aplicației, iar noua versiune a fost pur și simplu dezinstalată.
Lucrul bun despre acest lucru este că, chiar dacă aveți un număr mare de solicitări simultane care vin în aplicație, acestea nu vor observa nici măcar timpul de nefuncționare în timpul implementării procedurii de implementare. Dacă testați această aplicație folosind framework-ul Gatling, care îi trimite cât mai multe solicitări posibil, atunci niciuna dintre aceste solicitări nu va fi abandonată. Aceasta înseamnă că utilizatorii noștri nici măcar nu vor observa actualizările versiunilor în timp real. Dacă eșuează, lucrul va continua la versiunea veche; dacă are succes, utilizatorii vor trece la noua versiune.
Există un singur lucru care poate eșua - dacă verificarea de sănătate reușește, dar aplicația eșuează de îndată ce sarcina de lucru îi este aplicată, adică colapsul va avea loc numai după finalizarea implementării. În acest caz, va trebui să reveniți manual înapoi la versiunea veche. Așadar, ne-am uitat la cum să folosim Kubernetes cu instrumentele open-source concepute pentru asta. Procesul de implementare va fi mult mai ușor dacă construiți aceste instrumente în conductele dvs. de Build/Deploy. În același timp, pentru a începe implementarea, puteți utiliza fie interfața cu utilizatorul, fie automatiza complet acest proces utilizând, de exemplu, commit to master.
Serverul nostru de compilare va crea o imagine Docker, o va împinge în Docker Hub sau în orice registru pe care îl utilizați. Docker Hub acceptă webhook, astfel încât să putem declanșa implementarea de la distanță prin Deployer în modul arătat mai sus. În acest fel, puteți automatiza pe deplin implementarea aplicației dvs. în potențiala producție.
Să trecem la următorul subiect - scalarea clusterului Kubernetes. Rețineți că comanda kubectl este o comandă de scalare. Cu mai mult ajutor, putem crește cu ușurință numărul de replici din clusterul nostru existent. Cu toate acestea, în practică, de obicei dorim să creștem numărul de noduri, mai degrabă decât pod-uri.
În același timp, în timpul orelor de lucru poate fi necesar să creșteți, iar noaptea, pentru a reduce costul serviciilor Amazon, poate fi necesar să reduceți numărul de instanțe de aplicație care rulează. Acest lucru nu înseamnă că scalarea doar a numărului de pod-uri va fi suficientă, deoarece chiar dacă unul dintre noduri este inactiv, va trebui să plătiți Amazon pentru asta. Adică, împreună cu scalarea podurilor, va trebui să scalați numărul de mașini utilizate.
Acest lucru poate fi o provocare deoarece, indiferent dacă folosim Amazon sau un alt serviciu cloud, Kubernetes nu știe nimic despre numărul de mașini utilizate. Îi lipsește un instrument care vă permite să scalați sistemul la nivel de nod.
Deci va trebui să avem grijă atât de noduri, cât și de poduri. Putem scala cu ușurință lansarea de noi noduri folosind API-ul AWS și mașinile de grup Scaling pentru a configura numărul de noduri de lucru Kubernetes. De asemenea, puteți utiliza cloud-init sau un script similar pentru a înregistra noduri în clusterul Kubernetes.
Noua mașină pornește în grupul Scaling, se inițiază ca nod, se înregistrează în registrul masterului și începe să funcționeze. După aceasta, puteți crește numărul de replici pentru utilizare pe nodurile rezultate. Reducerea necesită mai mult efort, deoarece trebuie să vă asigurați că un astfel de pas nu duce la distrugerea aplicațiilor care rulează deja după oprirea mașinilor „inutile”. Pentru a preveni un astfel de scenariu, trebuie să setați nodurile la starea „neprogramabil”. Aceasta înseamnă că planificatorul implicit va ignora aceste noduri atunci când planifică podurile DaemonSet. Planificatorul nu va șterge nimic de pe aceste servere, dar nu va lansa acolo containere noi. Următorul pas este să eliminați nodul de drenaj, adică să transferați podurile care rulează de pe acesta pe o altă mașină sau alte noduri care au capacitate suficientă pentru aceasta. După ce v-ați asigurat că nu mai există containere pe aceste noduri, le puteți elimina din Kubernetes. După aceasta, pur și simplu vor înceta să mai existe pentru Kubernetes. Apoi, trebuie să utilizați API-ul AWS pentru a dezactiva nodurile sau mașinile inutile.
Puteți utiliza Amdatu Scalerd, un alt instrument de scalare open-source similar cu API-ul AWS. Oferă un CLI pentru a adăuga sau elimina noduri dintr-un cluster. Caracteristica sa interesantă este capacitatea de a configura planificatorul folosind următorul fișier json.
Codul afișat reduce capacitatea clusterului la jumătate în timpul nopții. Acesta configurează atât numărul de replici disponibile, cât și capacitatea dorită a clusterului Amazon. Utilizarea acestui planificator va reduce automat numărul de noduri noaptea și le va crește dimineața, economisind costul utilizării nodurilor dintr-un serviciu cloud precum Amazon. Această caracteristică nu este încorporată în Kubernetes, dar utilizarea Scalerd vă va permite să scalați această platformă așa cum doriți.
Aș dori să subliniez că mulți oameni îmi spun: „Totul este bine și bine, dar cum rămâne cu baza mea de date, care este de obicei statică?” Cum poți rula așa ceva într-un mediu dinamic precum Kubernetes? În opinia mea, nu ar trebui să faci asta, nu ar trebui să încerci să rulezi un depozit de date în Kubernetes. Acest lucru este posibil din punct de vedere tehnic și există tutoriale pe Internet pe acest subiect, dar îți va complica serios viața.
Da, există un concept de magazine persistente în Kubernetes și puteți încerca să rulați magazine de date precum Mongo sau MySQL, dar aceasta este o sarcină destul de intensivă în muncă. Acest lucru se datorează faptului că depozitele de date nu acceptă pe deplin interacțiunea cu un mediu dinamic. Majoritatea bazelor de date necesită o configurare semnificativă, inclusiv configurarea manuală a clusterului, nu le place autoscaling și alte lucruri similare.
Prin urmare, nu ar trebui să vă complicați viața încercând să rulați un depozit de date în Kubernetes. Organizați-le munca în mod tradițional folosind servicii familiare și pur și simplu oferiți Kubernetes abilitatea de a le folosi.
Pentru a încheia subiectul, aș dori să vă prezint platforma Cloud RTI bazată pe Kubernetes, la care lucrează echipa mea. Oferă înregistrare centralizată, monitorizare a aplicațiilor și a clusterului și multe alte caracteristici utile care vă vor fi utile. Utilizează diverse instrumente open-source, cum ar fi Grafana, pentru a afișa monitorizarea.
A existat o întrebare despre motivul pentru care se folosește echilibrul de încărcare ha-proxy cu Kubernetes. Bună întrebare pentru că în prezent există 2 niveluri de echilibrare a sarcinii. Serviciile Kubernetes încă se află pe adrese IP virtuale. Nu le puteți folosi pentru porturi pe mașini gazdă externe, deoarece dacă Amazon își supraîncărcă gazda cloud, adresa se va schimba. Acesta este motivul pentru care plasăm ha-proxy în fața serviciilor - pentru a crea o structură mai statică pentru ca traficul să comunice perfect cu Kubernetes.
O altă întrebare bună este cum vă puteți ocupa de modificările schemei bazei de date atunci când faceți implementare albastru/verde? Faptul este că, indiferent de utilizarea Kubernetes, schimbarea schemei bazei de date este o sarcină dificilă. Trebuie să vă asigurați că vechea și noua schemă sunt compatibile, după care puteți actualiza baza de date și apoi puteți actualiza aplicațiile în sine. Puteți schimba baza de date și apoi actualizați aplicațiile. Știu oameni care au pornit un cluster de baze de date complet nou cu o nouă schemă, aceasta este o opțiune dacă aveți o bază de date fără schemă precum Mongo, dar oricum nu este o sarcină ușoară. Dacă nu mai aveți întrebări, vă mulțumim pentru atenție!
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com