Kubernetes este un instrument excelent pentru lansarea containerelor Docker într-un mediu de producție clusterizat. Totuși, există sarcini pe care Kubernetes nu le poate rezolva. Atunci când desfășurăm frecvent în mediu de lucru, avem nevoie de un proces complet automatizat de Blue/Green deployment pentru a evita timpii de inactivitate, care necesită, de asemenea, gestionarea cererilor HTTP externe și realizarea extragerii SSL. Acest lucru necesită integrarea cu un balancer de încărcare, precum ha-proxy. O altă sarcină este scalarea semi-automată a clusterului Kubernetes în medii cloud, cum ar fi reducerea parțială a dimensiunii clusterului noaptea.
Deși Kubernetes nu dispune de aceste funcții direct „din cutie”, el oferă un API pe care îl putem folosi pentru a rezolva astfel de sarcini. Instrumentele pentru desfășurarea automatizată Blue/Green și scalarea clusterului Kubernetes au fost dezvoltate în cadrul proiectului Cloud RTI, care a fost creat pe baza unor soluții open-source.
În acest articol, o transcriere a unui videoclip, se discută despre cum să configurăm Kubernetes împreună cu alte componente open-source pentru a obține un mediu de producție îl care să accepte codul din commit-urile git fără timpi de inactivitate.
Așadar, după ce ați obținut accesul la aplicațiile dvs. din lumea externă, puteți începe configurarea completă a automatizării, adică să o aduceți la stadiul în care puteți realiza un git commit și să vă asigurați că acest git commit se finalizează în producție. Este evident că, în implementarea acestor pași, ne dorim să evităm timpii de inactivitate. Așadar, orice automatizare în Kubernetes începe cu API-ul.
Kubernetes nu este un instrument care poate fi folosit productiv „direct din cutie”. Desigur, puteți face asta, folosi kubectl și așa mai departe, dar API-ul rămâne cea mai interesantă și utilă parte a acestei platforme. Folosind API-ul ca un set de funcții, aveți acces practic la tot ce doriți să faceți în Kubernetes. Kubectl în sine utilizează, de asemenea, REST API.
Acesta este un API REST, deci poți folosi orice limbaj sau instrument pentru a lucra cu el, dar bibliotecile utilizatorului îți vor face viața mult mai ușoară. Echipa mea a scris 2 astfel de biblioteci: una pentru Java / OSGi și una pentru Go. Cea de-a doua nu este folosită prea des, dar oricum ai la dispoziție aceste lucruri utile. Ele fac parte dintr-un proiect open-source parțial licențiat. Există multe astfel de biblioteci pentru diferite limbi, așa că poți alege cele mai potrivite.
Așadar, înainte de a începe automatizarea desfășurării, trebuie să te asiguri că acest proces nu va suferi de timpi de nefuncționare. De exemplu, echipa noastră desfășoară desfășurări de producție în mijlocul zilei, când oamenii folosesc la maxim aplicațiile, deci este foarte important să evităm întârzierile în acest proces. Pentru a preveni timpii de nefuncționare, se folosesc 2 metode: desfășurarea blue/green sau actualizarea graduală rolling update. În cel din urmă caz, dacă ai 5 replici ale aplicației active, acestea sunt actualizate una câte una. Această metodă funcționează excelent, dar nu este potrivită dacă, în timpul desfășurării, ai versiuni diferite ale aplicației care rulează simultan. În acest caz, poți actualiza interfața utilizatorului în timp ce backend-ul funcționează cu versiunea anterioară, iar funcționarea aplicației va fi întreruptă. De aceea, din punct de vedere programatic, lucrul în aceste condiții este destul de complicat.
Aceasta este una dintre motivele pentru care preferăm să folosim desfășurarea blue/green pentru automatizarea desfășurării aplicațiilor noastre. În acest mod, trebuie să te asiguri că, într-un anumit moment, este activă doar o singură versiune a aplicației.
Mecanismul desfășurării blue/green funcționează astfel. Primim traficul pentru aplicațiile noastre prin ha-proxy, care îl direcționează către replicile active ale aplicației de aceeași versiune.
Când se efectuează un nou deployment, folosim Deployer, căruia i se furnizează noi componente, și acesta realizează deplasarea noii versiuni. Deplasarea noii versiuni a aplicației înseamnă că un nou set de replici este „ridicat”, după care aceste replici ale noii versiuni sunt lansate într-un nou pod separat. Totuși, ha-proxy nu are cunoștință despre acestea și momentan nu le direcționează nicio încărcătură de lucru.
Prin urmare, mai întâi trebuie să efectuăm verificări de sănătate a noilor versiuni pentru a ne asigura că replicile sunt pregătite să gestioneze încărcătura.
Toate componentele de deployment trebuie să suporte o formă de verificare a stării. Aceasta poate fi o verificare HTTP simplă, când obții un cod cu statutul 200, sau o verificare mai profundă, în care verifici conexiunea replicilor cu baza de date și alte servicii, stabilitatea conexiunilor mediului dinamic, dacă totul se lansează și funcționează corect. Acest proces poate fi destul de complex.
După ce sistemul se asigură că toate replicile actualizate sunt funcționale, Deployer va actualiza configurația și va transmite confd-ul corect, care va reconfigura ha-proxy.
Numai după aceea, traficul va fi direcționat către podul cu replicile noii versiuni, iar podul vechi va dispărea.
Acest mecanism nu este o caracteristică specifică Kubernetes. Conceptul de Blue/green deployment există de mult timp și mereu a folosit un echilibrator de încărcare. Inițial, direcționezi tot traficul către versiunea veche a aplicației, iar după actualizare, îl transferi complet pe noua versiune. Acest principiu este folosit nu doar în Kubernetes.
Acum vă voi prezenta un nou component de deployment – Deployer, care efectuează verificări de sănătate, reconfigurază proxy-ul și așa mai departe. Acesta este un concept care nu se referă la lumea externă și există în interiorul Kubernetes. Voi arăta cum poți crea propriul tău concept Deployer folosind instrumente open-source.
Așadar, primul lucru pe care îl face Deployer este să creeze un controler de replicare RC, folosind API-ul Kubernetes. Acest API creează pod-uri și servicii pentru desfășurarea ulterioară, adică creează un nou cluster complet pentru aplicațiile noastre. Odată ce RC se asigură că replicile au pornit, va efectua o verificare a sănătății lor. Pentru aceasta, în Deployer se folosește comanda GET /health. Aceasta activează componentele corespunzătoare ale verificării și verifică toate elementele care asigură funcționarea cluster-ului.
După ce toate pod-urile au raportat starea lor de "sănătate", Deployer creează un nou element de configurare – un depozit distribuit etcd, care este folosit în interiorul Kubernetes, inclusiv pentru a stoca configurația load balancer-ului. Noi înregistrăm datele în etcd, iar un mic instrument confd monitorizează etcd pentru apariția de noi date.
Dacă detectează vreo modificare a configurației inițiale, acesta generează un nou fișier de configurare și îl trimite către ha-proxy. În acest caz, ha-proxy se reîncarcă fără a pierde vreo conexiune și își direcționează traficul către noile servicii, care asigură funcționarea noii versiuni a aplicațiilor noastre.
După cum vedeți, în ciuda numeroaselor componente, aici nu este nimic complicat. Trebuie doar să acordați o atenție mai mare API-ului și etcd. Vreau să vă povestesc despre un Deployer open-source, pe care îl folosim noi înșine – Amdatu Kubernetes Deployer.
Este un instrument pentru orchestration of Kubernetes deployments, având următoarele funcții:
- desfășurare Blue/Green;
- configurarea unui load balancer extern;
- managementul descriptorilor de desfășurare;
- managementul desfășurării efective;
- verificări de sănătate în timpul desfășurării;
- inserarea de variabile de mediu în pod-uri.
Acest Deployer este construit pe baza API-ului Kubernetes și oferă un REST API pentru gestionarea descriptorilor și desfășurărilor, precum și un Websocket API pentru streaming de log-uri în timpul desfășurării.
Acesta plasează datele de configurare ale load balancer-ului în etcd, astfel încât să nu fie necesar să folosiți ha-proxy cu suport "din cutie", ci să folosiți cu ușurință propriul fișier de configurare al load balancer-ului. Amdatu Deployer este scris în Go, la fel ca Kubernetes, și este licențiat Apache.
Înainte de a utiliza această versiune a deploiatorului, am folosit următorul descriptor de implementare, care include parametrii necesari pentru mine.
Unul dintre parametrii importanți ai acestui cod este activarea flag-ului „useHealthCheck”. Trebuie să specificăm că în timpul desfășurării trebuie efectuată o verificare a funcționalității. Acest parametru poate fi dezactivat atunci când în desfășurare sunt utilizate containere de la terți, care nu necesită verificare. Acest descriptor specifică, de asemenea, numărul de replici și URL-ul front-end-ului necesar pentru ha-proxy. La final, este indicat flag-ul specificației pod-ului „podspec”, care se adresează Kubernetes pentru informații despre configurarea porturilor, imaginea, etc. Este un descriptor destul de simplu în format JSON.
Un alt instrument care face parte din proiectul open-source Amdatu este Deploymentctl. Acesta are o interfață utilizator UI pentru configurarea desfășurării, păstrează istoricul desfășurărilor și conține webhooks pentru apeluri inverse de la utilizatori și dezvoltatori terți. Nu este necesar să utilizați UI-ul, deoarece Amdatu Deployer este un REST API, dar această interfață vă poate facilita foarte mult desfășurarea fără a apela la un API. Deploymentctl este scris în OSGi/Vertx folosind Angular 2.
Acum voi demonstra cele spuse mai sus pe ecran, folosind o înregistrare preînregistrată, astfel încât să nu fie nevoie să așteptați. Vom desfășura o aplicație simplă în Go. Nu vă faceți griji dacă nu ați avut de-a face cu Go anterior, aceasta este o aplicație foarte simplă, așa că ar trebui să fie totul clar.
Aici creăm un server HTTP care răspunde doar la /health, așa că această aplicație verifică doar sănătatea, nimic mai mult. Dacă verificarea trece, este folosită structura JSON arătată mai jos. Aceasta conține versiunea aplicației care va fi desfășurată de deploiator, mesajul pe care îl vedeți în partea de sus a fișierului și un tip de date boolean — dacă aplicația noastră este sau nu funcțională.
Cu ultima linie am fost puțin șiret, deoarece am plasat în partea de sus a fișierului o valoare booleană fixă, care ulterior mă va ajuta să desfășor chiar și o aplicație „nesănătoasă”. Mai târziu vom discuta despre asta.
Așadar, să începem. Mai întâi verificăm dacă există vreo instanță de poduri rulând cu comanda ~ kubectl get pods și prin absența răspunsului URL-ului frontend ne asigurăm că nu se desfășoară nicio implementare în acest moment.
Mai departe, pe ecran vedeți interfața menționată de mine, Deploymentctl, în care se stabilesc parametrii implementării: spațiul de nume, numele aplicației, versiunea implementării, numărul de replici, URL-ul frontend, numele containerului, imaginea, limitele resurselor, numărul de port pentru health check etc. Limitele resurselor sunt foarte importante, deoarece permit utilizarea maximă a resurselor hardware disponibile. De asemenea, aici puteți vizualiza jurnalul implementării, Deployment log.
Dacă repetăm acum comanda ~ kubectl get pods, se poate observa că sistemul "îngheață" timp de 20 de secunde, timp în care are loc reconfigurarea ha-proxy. După aceasta, podul se lansează, iar replica noastră poate fi văzută în jurnalul implementării.
Am tăiat din videoclip așteptarea de 20 de secunde și acum vedeți pe ecran că prima versiune a aplicației a fost implementată. Totul a fost realizat doar prin intermediul UI-ului.
Acum să încercăm a doua versiune. Pentru aceasta, schimb mesajul aplicației din "Hello, Kubernetes!" în "Hello, Deployer!", sistemul creează această imagine și o plasează în registrul Docker, după care apăsăm din nou butonul "Deploy" în fereastra Deploymentctl. La acest lucru, se lansează automat jurnalul implementării exact așa cum s-a întâmplat la implementarea primei versiuni a aplicației.
Comanda ~ kubectl get pods arată că în prezent sunt rulante 2 versiuni ale aplicației, totuși frontend-ul arată că avem încă versiunea 1 activă.
Balancerul de sarcină așteaptă să fie efectuat un health check, după care va redirecționa traficul către noua versiune. După 20 de secunde, trecem la curl și vedem că acum avem implementată versiunea 2 a aplicației, iar prima a fost eliminată.
Aceasta a fost implementarea unei aplicații "sănătoase" — healthy. Să vedem ce se întâmplă dacă pentru noua versiune a aplicației schimb valoarea parametrului Healthy din true în false, adică încerc să implementez o aplicație unhealthy, care nu a trecut testul de sănătate. Acest lucru se poate întâmpla dacă în timpul dezvoltării s-au făcut anumite erori de configurare în aplicație și aceasta a fost trimisă în producție în această formă.
După cum vedeți, desfășurarea trece prin toate etapele menționate mai sus, iar ~ kubectl get pods arată că ambele poduri sunt active. Însă, spre deosebire de desfășurarea anterioară, logul arată un timeout. Asta înseamnă că, din cauza unei verificări health check eșuate, noua versiune a aplicației nu poate fi desfășurată. Drept urmare, observați că sistemul a revenit la utilizarea versiunii vechi a aplicației, iar noua versiune a fost pur și simplu ștearsă.
Binele este că, chiar dacă aveți un număr mare de cereri simultane care ajung în aplicație, utilizatorii nu vor observa întreruperi în timpul desfășurării. Dacă testați această aplicație cu framework-ul Gatling, care trimite maximul de cereri posibil, nu va fi respinsă niciuna dintre acestea. Acest lucru înseamnă că utilizatorii noștri nu vor observa nici o actualizare a versiunilor în timp real. Dacă aceasta eșuează, activitatea va continua pe vechea versiune; dacă este reușită, utilizatorii vor trece la noua versiune.
Există un singur lucru care poate duce la eșec – dacă verificarea health check a fost efectuată cu succes, dar aplicația a dat eroare imediat ce a fost supusă unei sarcini de lucru, adică colapsul va avea loc doar după finalizarea desfășurării. În acest caz, va trebui să reveniți manual la versiunea anterioară. Așadar, am discutat despre cum să folosiți Kubernetes cu instrumentele open-source destinate acestuia. Procedura de desfășurare va decurge mult mai simplu dacă integrați aceste instrumente în pipeline-urile de creare/desfășurare Build/Deploy. În acest fel, pentru a porni desfășurarea, puteți utiliza atât interfața grafică, cât și automatiza complet acest proces prin aplicarea, de exemplu, a commit to master.
Serverul nostru de construire Build Server va crea o imagine Docker, o va încărca pe Docker Hub sau pe orice alt registru pe care îl utilizați. Docker Hub suportă webhook, astfel încât putem iniția o desfășurare la distanță prin Deployer așa cum am arătat mai sus. Astfel, desfășurarea aplicației în producție poate fi complet automatizată.
Să trecem la următoarea temă – scalarea clusterului Kubernetes. Observ că comanda kubectl este o comandă de scalare. Cu ajutorul acesteia, putem să creștem cu ușurință numărul de replici în clusterul existent. Cu toate acestea, în practică, de obicei dorim să creștem numărul nu al podurilor, ci al nodurilor.
În acest sens, în timpul programului de lucru, este posibil să aveți nevoie de o creștere, iar pe timp de noapte, pentru a reduce costurile serviciilor Amazon – o reducere a numărului de instanțe de aplicație rulate. Asta nu înseamnă că va fi suficient să scalăm doar numărul podurilor, pentru că, chiar și dacă unul dintre noduri nu este ocupat, va trebui totuși să plătiți pentru el către Amazon. Adică, pe lângă scalarea podurilor, trebuie să scalăm și numărul mașinilor utilizate.
Acest lucru poate cauza dificultăți, deoarece, indiferent dacă folosim Amazon sau un alt serviciu cloud, Kubernetes nu știe nimic despre numărul de mașini utilizate. Nu există un instrument în acesta care să permită scalarea sistemului la nivelul nodurilor.
Așadar, va trebui să ne ocupăm atât de noduri, cât și de poduri. Putem să scalăm cu ușurință lansarea de noi noduri folosind API-ul AWS și grupul de masini de scalare pentru a configura numărul de noduri de lucru Kubernetes. De asemenea, putem folosi cloud-init sau un script similar pentru a înregistra nodurile în clusterul Kubernetes.
Noua mașină pornește în grupul de scalare, se inițiază ca nod, se înscrie în registrul master și începe să funcționeze. După aceasta, se poate crește numărul de replici pentru utilizarea pe nodurile formate. Reducerea scalării necesită un efort mai mare, deoarece trebuie să ne asigurăm că un astfel de pas nu va duce la distrugerea aplicațiilor deja funcționale după deconectarea mașinilor „necesare”. Pentru a preveni un astfel de scenariu, nodurile trebuie readuse la statusul „unschedulable”. Aceasta înseamnă că planificatorul implicit va ignora aceste noduri atunci când planifică podurile DaemonSet. Planificatorul nu va elimina nimic de pe aceste servere, dar nici nu va lansa recipiente noi acolo. Următorul pas este de a face nodul drain, adică de a muta podurile active de pe acesta pe o altă mașină sau pe alte noduri, care dispun de capacitatea necesară. După ce ne-am asigurat că pe aceste noduri nu mai există recipiente, acestea pot fi eliminate din Kubernetes. După aceasta, pentru Kubernetes, acestea pur și simplu nu vor mai exista. În continuare, trebuie să folosiți AWS API pentru a dezactiva nodurile sau mașinile inutile.
Puteți folosi Amdatu Scalerd – un alt instrument open-source pentru scalare, similar cu AWS API. Acesta oferă CLI pentru adăugarea sau eliminarea nodurilor din cluster. O caracteristică interesantă este capacitatea de a configura planificatorul prin următorul fișier JSON.
Codul prezentat reduce la jumătate capacitatea cluster-ului în perioada de noapte. Acesta configurează atât numărul de replici existente, cât și capacitatea dorită a cluster-ului Amazon. Utilizarea acestui planificator va reduce automat numărul de noduri noaptea și le va crește dimineața, permițând economisirea costurilor utilizării nodurilor unui astfel de serviciu cloud, cum ar fi Amazon. Această funcție nu este integrată în Kubernetes, dar utilizarea Scalerd vă va permite să scalați această platformă în orice mod doriți.
Vreau să vă atrag atenția asupra faptului că mulți oameni îmi spun: „Toate acestea sunt bune, dar ce se întâmplă cu baza mea de date, care de obicei este într-o stare statică?” Cum putem rula ceva similar într-un mediu dinamic precum Kubernetes? Din punctul meu de vedere, nu ar trebui să faceți asta, nu ar trebui să încercați să organizați funcționarea stocării datelor în Kubernetes. Tehnic, acest lucru este posibil, și există ghiduri pe internet despre acest subiect, însă vă va complica serios viața.
Da, în Kubernetes există conceptul de stocare persistentă, iar tu poți încerca să rulezi baze de date precum Mongo sau MySQL, dar este o sarcină destul de laborioasă. Acest lucru se datorează faptului că bazele de date nu suportă complet interacțiunea cu un mediu dinamic. Cele mai multe baze de date necesită o configurare semnificativă, inclusiv configurarea manuală a clusterului, nu le plac auto-scalarea și alte lucruri de genul acesta.
Prin urmare, nu ar trebui să-ți complici viața încercând să rulezi o bază de date în Kubernetes. Organizează-le funcționarea într-un mod tradițional, folosind servicii familiare și oferă pur și simplu Kubernetes-ului posibilitatea de a le folosi.
În încheiere, vreau să vă prezint platforma Cloud RTI bazată pe Kubernetes, la care lucrează echipa mea. Aceasta asigură un management centralizat al log-urilor, monitorizarea aplicațiilor și a clusterelor și dispune de multe alte funcții utile pe care le veți găsi utile. Folosește diverse instrumente open-source, precum Grafana pentru afișarea monitorizării.
A fost ridicată întrebarea de ce să folosim un echilibror de încărcare ha-proxy cu Kubernetes. O întrebare bună, deoarece în prezent există 2 niveluri de echilibrare a încărcării. Serviciile Kubernetes se află în continuare pe adrese IP virtuale. Nu le poți utiliza pentru porturile mașinilor gazdă externe, deoarece dacă Amazon își suprasolicită gazda cloud, adresa se va schimba. De aceea plasăm ha-proxy înaintea serviciilor — pentru a crea o structură mai statică pentru interacțiunea continuă a traficului cu Kubernetes.
Încă o întrebare bună – cum putem gestiona modificarea schemei bazei de date în timpul unui deployment blue/green? Problema este că, indiferent de utilizarea Kubernetes, modificarea schemei bazei de date este o sarcină complexă. Trebuie să asigurați compatibilitatea între vechea și noua schemă, după care puteți actualiza baza de date și apoi aplicațiile. Puteți efectua o 'înlocuire la cald' a bazei de date și apoi să actualizați aplicațiile. Cunosc oameni care au încărcat un cluster de baze de date complet nou cu o schemă nouă; aceasta este o opțiune dacă aveți o bază de date fără schemă, cum ar fi Mongo, dar oricum, nu este o sarcină simplă. Dacă nu mai sunt întrebări, vă mulțumesc pentru atenție!
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
