Kubernetes hè un grande strumentu per eseguisce cuntenituri Docker in un ambiente di produzzione clustered. Tuttavia, ci sò prublemi chì Kubernetes ùn pò micca risolve. Per implementazioni frequenti di produzzione, avemu bisognu di una implementazione Blu / Verde cumplettamente automatizata per evità i tempi di inattività in u prucessu, chì deve ancu trattà e richieste HTTP esterne è eseguisce SSL offloads. Questu hè bisognu di integrazione cù un balancer di carica cum'è ha-proxy. Un'altra sfida hè a scala semi-automatica di u cluster Kubernetes stessu quandu eseguisce in un ambiente di nuvola, per esempiu parzialmente scaling the cluster down at night.
Mentre Kubernetes ùn hà micca queste caratteristiche fora di a scatula, furnisce una API chì pudete aduprà per risolve prublemi simili. Strumenti per l'implementazione automatica di Blue / Green è a scala di un cluster Kubernetes sò stati sviluppati cum'è parte di u prughjettu Cloud RTI, chì hè statu creatu basatu annantu à open-source.
Questu articulu, una trascrizione video, vi mostra cumu cunfigurà Kubernetes cù altri cumpunenti open source per creà un ambiente prontu per a produzzione chì accetta u codice da un git commit senza downtime in a produzzione.
Allora, una volta chì avete accessu à e vostre applicazioni da u mondu esternu, pudete cumincià à cunfigurà cumplettamente l'automatizazione, vale à dì, purtalla à u palcuscenicu induve pudete eseguisce un git commit è assicuratevi chì questu git commit finisce in produzzione. Naturalmente, quandu implementate questi passi, quandu implementate implementazione, ùn vulemu micca scuntrà tempi di inattività. Dunque, ogni automatizazione in Kubernetes principia cù l'API.
Kubernetes ùn hè micca un strumentu chì pò esse usatu produttivamente fora di a scatula. Di sicuru, pudete fà quessa, aduprate kubectl è cusì, ma ancu l'API hè a cosa più interessante è utile di sta piattaforma. Utilizendu l'API cum'è un settore di funzioni, pudete accede à quasi tuttu ciò chì vulete fà in Kubernetes. kubectl stessu usa ancu l'API REST.
Questu hè REST, cusì pudete aduprà qualsiasi lingua o strumentu per travaglià cù questa API, ma a vostra vita serà facilitata assai da biblioteche persunalizate. U mo squadra hà scrittu 2 tali librerie: una per Java / OSGi è una per Go. U sicondu ùn hè micca usatu spessu, ma in ogni casu avete queste cose utili à a vostra dispusizione. Sò un prughjettu open-source parzialmente licenziatu. Ci sò parechje biblioteche tali per diverse lingue, cusì pudete sceglie quelli chì vi cunvene megliu.
Allora, prima di cumincià à automatizà a vostra implementazione, avete bisognu di assicurà chì u prucessu ùn serà micca sottumessu à alcunu downtime. Per esempiu, a nostra squadra conduce implementazioni di pruduzzione durante a mità di u ghjornu quandu e persone utilizanu l'applicazioni à u so massimu, per quessa, hè impurtante per evità ritardi in stu prucessu. Per evità i tempi di inattività, 2 metudi sò usati: implementazione blu / verde o aghjurnamentu rolling. In l'ultimu casu, se avete 5 repliche di l'applicazione in esecuzione, sò aghjurnati sequenzialmente unu dopu l'altru. Stu metudu funziona bè, ma ùn hè micca adattatu s'è vo avete diverse versioni di l'applicazione chì funziona simultaneamente durante u prucessu di implementazione. In questu casu, pudete aghjurnà l'interfaccia d'utilizatore mentre u backend eseguisce a versione vechja, è l'applicazione cesserà di travaglià. Dunque, da un puntu di vista di prugrammazione, travaglià in tali cundizioni hè abbastanza difficiule.
Questa hè una di e ragioni per quale preferimu aduprà a implementazione blu / verde per automatizà a implementazione di e nostre applicazioni. Cù stu mètudu, vi tocca à assicurà chì una sola versione di l 'applicazzioni hè attiva à tempu.
U mecanismu di implementazione blu / verde hè cusì. Ricevemu u trafficu per e nostre appricazzioni attraversu ha-proxy, chì u trasmette à eseguite repliche di l'applicazione di a stessa versione.
Quandu una nova implementazione hè fatta, usemu Deployer, chì hè datu i novi cumpunenti è implementa a nova versione. A implementazione di una nova versione di una applicazione significa chì un novu settore di rèpliche hè "risuscitatu", dopu chì sti rèplichi di a nova versione sò lanciati in un novu pod separatu. Tuttavia, ha-proxy ùn sà nunda di elli è ùn li indirizza micca ancora alcuna carica di travagliu.
Dunque, prima di tuttu, hè necessariu di realizà una verificazione di u funziunamentu di e novi versioni di u cuntrollu di salute per assicurà chì e rèpliche sò pronti à serve a carica.
Tutti i cumpunenti di implementazione devenu sustene una certa forma di cuntrollu di salute. Questu pò esse un cuntrollu di chjama HTTP assai simplice, quandu riceve un codice cù u statutu 200, o un cuntrollu più approfonditu, in quale verificate a cunnessione di e rèpliche cù a basa di dati è altri servizii, a stabilità di e cunnessione di l'ambienti dinamichi. , è se tuttu principia è funziona bè. Stu prucessu pò esse abbastanza cumplessu.
Dopu chì u sistema verifica chì tutte e rèpliche aghjurnate funzionanu, Deployer aghjurnà a cunfigurazione è passà a confd curretta, chì reconfigurerà ha-proxy.
Solu dopu à questu, u trafficu serà direttu à u pod cù rèpliche di a nova versione, è u vechju pod sparirà.
Stu mecanismu ùn hè micca una caratteristica di Kubernetes. U cuncettu di implementazione Blu / verde hè stata per un bellu pezzu è hà sempre utilizatu un balancer di carica. Prima, dirigete tuttu u trafficu à a vechja versione di l'applicazione, è dopu l'aghjurnamentu, u trasfiriu cumplettamente à a nova versione. Stu principiu hè usatu micca solu in Kubernetes.
Avà vi presentà un novu cumpunente di implementazione - Deployer, chì esegue cuntrolli di salute, riconfigura i proxy, è cusì. Questu hè un cuncettu chì ùn hè micca applicatu à u mondu esternu è esiste in Kubernetes. Vi mustraraghju cumu pudete creà u vostru propiu cuncettu di Deployer utilizendu strumenti open-source.
Allora, a prima cosa chì Deployer faci hè di creà un controller di replicazione RC utilizendu l'API Kubernetes. Questa API crea pods è servizii per più implementazione, vale à dì, crea un cluster completamente novu per e nostre applicazioni. Appena RC hè cunvinta chì e rèpliche anu cuminciatu, farà un cuntrollu di Salute nantu à a so funziunalità. Per fà questu, Deployer usa u cumandamentu GET / health. Esegue i cumpunenti di scansione adattati è verifica tutti l'elementi chì sustenenu l'operazione di u cluster.
Dopu chì tutti i pods anu signalatu a so salute, Deployer crea un novu elementu di cunfigurazione - etcd storage distribuitu, chì hè utilizatu internamente da Kubernetes, cumpresu l'almacenamiento di a cunfigurazione di bilanciatore di carica. Scrivemu dati à etcd, è un picculu strumentu chjamatu confd monitors etcd per novi dati.
Se detecta qualsiasi cambiamenti à a cunfigurazione iniziale, genera un novu schedariu di paràmetri è u trasferisce à ha-proxy. In questu casu, ha-proxy reboots senza perde alcuna cunnessione è indirizza a carica à novi servizii chì permettenu a nova versione di e nostre applicazioni per travaglià.
Comu pudete vede, malgradu l'abbundanza di cumpunenti, ùn ci hè nunda di complicatu quì. Solu bisognu di pagà più attenzione à l'API è etcd. Vogliu parlà di u deployer open-source chì noi stessi utilizemu - Amdatu Kubernetes Deployer.
Hè un strumentu per orchestrazione di implementazioni Kubernetes è hà e seguenti caratteristiche:
- implementazione blu / verde;
- a creazione di un equilibratore di carica esterna;
- gestione di descrittore di implementazione;
- a gestione di a implementazione attuale;
- cuntrollà a funziunalità di i cuntrolli di Salute durante a implementazione;
- implementazione di variabili ambientali in pods.
Questu Deployer hè custruitu annantu à l'API Kubernetes è furnisce una API REST per a gestione di manichi è implementazioni, è ancu una API Websocket per i logs streaming durante u prucessu di implementazione.
Pone i dati di cunfigurazione di l'equilibriu di carica in etcd, cusì ùn avete micca aduprà ha-proxy cù supportu fora di a scatula, ma facilmente aduprà u vostru propiu schedariu di cunfigurazione di bilanciatore di carica. Amdatu Deployer hè scrittu in Go, cum'è Kubernetes stessu, è hè licenziatu da Apache.
Prima di cumincià à aduprà sta versione di u deployer, aghju utilizatu u seguente descrittore di implementazione, chì specifica i paràmetri chì aghju bisognu.
Unu di i parametri impurtanti di stu codice hè di attivà a bandiera "useHealthCheck". Avemu bisognu di specificà chì un cuntrollu di sanità deve esse realizatu durante u prucessu di implementazione. Questa paràmetra pò esse disattivata quandu a implementazione usa cuntenituri di terzu chì ùn deve micca esse verificatu. Stu descrittore indica ancu u numeru di repliche è l'URL di frontend chì ha-proxy hà bisognu. À a fine hè a bandiera di specificazione di pod "podspec", chì chjama Kubernetes per infurmazioni nantu à a cunfigurazione di u portu, l'imaghjini, etc. Questu hè un descrittore JSON abbastanza simplice.
Un altru strumentu chì face parte di u prughjettu open-source Amdatu hè Deploymentctl. Havi una UI per a cunfigurazione di implementazioni, almacena a storia di implementazione, è cuntene webhooks per callbacks da utilizatori è sviluppatori di terzu. Ùn pudete micca aduprà l'UI, postu chì Amdatu Deployer stessu hè una API REST, ma sta interfaccia pò fà a implementazione assai più faciule per voi senza implicà alcuna API. Deploymentctl hè scrittu in OSGi/Vertx cù Angular 2.
Avà dimustraraghju u sopra à u screnu cù una registrazione pre-registrata per ùn avè micca aspittà. Avemu da implementà una semplice applicazione Go. Ùn vi scantati s'è vo ùn avete micca pruvatu Go prima, hè una applicazione assai sèmplice cusì vi deve esse in gradu di capisce lu fora.
Quì avemu criatu un servitore HTTP chì risponde solu à / salute, cusì sta applicazione prova solu u cuntrollu di salute è nunda di più. Se u cuntrollu passa, a struttura JSON mostrata quì sottu hè aduprata. Contene a versione di l'applicazione chì serà implementata da u deployer, u missaghju chì vede à a cima di u schedariu, è u tipu di dati boolean - se a nostra applicazione funziona o micca.
Aghju ingannatu un pocu cù l'ultima linea, perchè aghju postu un valore booleanu fissu à a cima di u schedariu, chì in u futuru m'aiuterà à implementà ancu una applicazione "malsa". Avemu da trattà cun questu dopu.
Allora cuminciamu. Prima, verificamu a presenza di qualsiasi pods in esecuzione utilizendu u cumandimu ~ kubectl get pods è, basatu annantu à l'assenza di una risposta da l'URL di frontend, assicuremu chì nisuna implementazione hè attualmente fatta.
In seguitu nantu à u screnu, vede l'interfaccia Deploymentctl chì aghju citatu, in quale i paràmetri di implementazione sò stabiliti: namespace, nome di l'applicazione, versione di implementazione, numeru di repliche, URL front-end, nome di cuntainer, imagine, limiti di risorse, numeru di portu per u cuntrollu di salute, ecc. I limiti di risorse sò assai impurtanti, perchè permettenu di utilizà a quantità massima di hardware pussibule. Quì pudete ancu vede u log di Deployment.
Sè avà ripetite u cumandimu ~ kubectl get pods, pudete vede chì u sistema "congela" per 20 seconde, durante quale ha-proxy hè reconfiguratu. Dopu questu, u pod principia, è a nostra replica pò esse vistu in u logu di implementazione.
Aghju tagliatu l'aspittà di 20 secondi da u video, è avà pudete vede nantu à u screnu chì a prima versione di l'applicazione hè stata implementata. Tuttu chistu hè statu fattu cù solu l'UI.
Avà pruvemu a seconda versione. Per fà questu, aghju cambiatu u missaghju di l'applicazione da "Hello, Kubernetes!" nant'à "Hello, Deployer!", u sistema crea sta maghjina è a mette in u registru Docker, dopu chì simpricimenti cliccà nant'à u buttone "Deploy" novu in a finestra Deploymentctl. In questu casu, u logu di implementazione hè automaticamente lanciatu in a listessa manera chì hè accadutu quandu hà implementatu a prima versione di l'applicazione.
U cumandamentu ~ kubectl get pods mostra chì ci sò attualmente 2 versioni di l'applicazione in esecuzione, ma u frontend mostra chì avemu sempre a versione 1.
U bilanciu di carica aspetta chì u cuntrollu di salute finisci prima di redirige u trafficu à a nova versione. Dopu à 20 seconde, cambiamu à curl è vede chì avemu avà a versione 2 di l'applicazione implementata, è a prima hè stata sguassata.
Questa era a implementazione di una applicazione "sana". Videmu ciò chì succede se per una nova versione di l'applicazione aghju cambiatu u paràmetru Salute da veru à falsu, vale à dì, pruvate à implementà una applicazione malsana chì hà fallutu u cuntrollu di salute. Chistu pò succorsu si certi errori di cunfigurazione sò stati fatti in l'applicazione in u stadiu di sviluppu, è hè statu mandatu in produzzione in questa forma.
Comu pudete vede, a implementazione passa per tutti i passi sopra è ~ kubectl get pods mostra chì i dui pods sò in esecuzione. Ma à u cuntrariu di l'implementazione precedente, u logu mostra u statu di timeout. Questu hè, per via di u fattu chì u cuntrollu di salute hà fiascatu, a nova versione di l'applicazione ùn pò micca esse implementata. In u risultatu, vede chì u sistema hà tornatu à utilizà a versione vechja di l'applicazione, è a nova versione hè stata disinstallata.
A cosa bona di questu hè chì ancu s'è vo avete un gran numaru di richieste simultanee chì entranu in l'applicazione, ùn anu mancu nutatu u downtime mentre implementanu a prucedura di implementazione. Sè vo pruvate sta applicazione utilizendu u framework Gatling, chì l'invia quant'è più dumande pussibule, allora nimu di sti dumande serà abbandunatu. Questu significa chì i nostri utilizatori ùn anu mancu avvistu l'aghjurnamenti di versione in tempu reale. Se falla, u travagliu cuntinueghja nantu à a vechja versione; se hè successu, l'utilizatori passanu à a nova versione.
Ci hè solu una cosa chì pò fallu - se u cuntrollu di salute riesce, ma l'applicazione falla appena a carica di travagliu hè appiicata à questu, vale à dì, u colapsu si farà solu dopu chì a implementazione hè finita. In stu casu, vi tuccherà à turnà manually daretu à a vechja versione. Dunque, avemu vistu cumu utilizà Kubernetes cù l'arnesi open-source pensati per questu. U prucessu di implementazione serà assai più faciule se custruite queste arnesi in i vostri pipelines Build / Deploy. À u listessu tempu, per inizià a implementazione, pudete aduprà sia l'interfaccia d'utilizatore o automatizà cumplettamente stu prucessu usendu, per esempiu, cummit to master.
U nostru Build Server creerà una maghjina Docker, spinghjala in Docker Hub o qualsiasi registru chì utilizate. Docker Hub supporta webhook, cusì pudemu attivà a implementazione remota via Deployer in u modu mostratu sopra. In questu modu pudete automatizà cumplettamente a implementazione di a vostra applicazione à a produzzione potenziale.
Passemu à u prossimu tema - scaling the Kubernetes cluster. Nota chì u cumandamentu kubectl hè un cumandamentu di scala. Cù più aiutu, pudemu facilmente aumentà u numeru di repliche in u nostru cluster esistente. In ogni casu, in a pratica, di solitu vulemu aumentà u numeru di nodi piuttostu cà pods.
À u listessu tempu, durante l'ore di travagliu pudete avè bisognu di aumentà, è di notte, per riduce u costu di i servizii di Amazon, pudete bisognu di riduce u nùmeru di istanze d'applicazione in esecuzione. Questu ùn significa micca chì scaling solu u numeru di pods serà abbastanza, perchè ancu s'ellu unu di i nodi hè inattivu, avete sempre da pagà Amazon per questu. Questu hè, inseme cù a scala di i baccelli, avete bisognu di scala u numeru di machini utilizati.
Questu pò esse sfida, perchè s'ellu usemu Amazon o un altru serviziu di nuvola, Kubernetes ùn sapi nunda di u numeru di machini utilizati. Manca un strumentu chì permette di scala u sistema à u nivellu di node.
Allora avemu da piglià cura di i dui nodi è pods. Pudemu facilmente scala u lanciamentu di novi nodi utilizendu l'API AWS è e macchine di u gruppu Scaling per cunfigurà u numeru di nodi di u travagliu Kubernetes. Pudete ancu aduprà cloud-init o un script simili per registrà i nodi in u cluster Kubernetes.
A nova macchina principia in u gruppu Scaling, si inizia cum'è un node, si registra in u registru di u maestru è principia à travaglià. Dopu questu, pudete aumentà u nùmeru di repliche per l'usu nantu à i nodi resultanti. Scaling down richiede più sforzu, cum'è avete bisognu di assicurà chì un tali passu ùn porta micca à a distruzzione di l'applicazioni chì sò digià in esecuzione dopu avè disattivatu e macchine "inutili". Per prevene un tali scenariu, avete bisognu di stabilisce i nodi à u statu "unschedulable". Questu significa chì u pianificatore predeterminatu ignurà questi nodi durante a pianificazione di pods DaemonSet. U pianificatore ùn sguasserà nunda da questi servitori, ma ùn lanciarà ancu micca novi cuntenituri. U prossimu passu hè di caccià u node di drenu, vale à dì, per trasfirià pods in esecuzione da ellu à un'altra macchina, o altri nodi chì anu una capacità sufficiente per questu. Una volta assicuratu chì ùn ci sò più cuntenituri in questi nodi, pudete sguassà da Kubernetes. Dopu questu, cessanu solu di esiste per Kubernetes. In seguitu, avete bisognu di utilizà l'API AWS per disattivà nodi o macchine inutili.
Pudete aduprà Amdatu Scalerd, un altru strumentu di scala open-source simile à l'API AWS. Fornisce una CLI per aghjunghje o sguassà nodi in un cluster. A so funzione interessante hè a capacità di cunfigurà u scheduler usendu u seguente file json.
U codice mostratu riduce a capacità di cluster à a mità durante u periodu di notte. Configura u numeru di repliche dispunibili è a capacità desiderata di u cluster Amazon. L'usu di stu pianificatore riducerà automaticamente u numeru di nodi à a notte è l'aumentarà in a mattina, risparmiendu u costu di l'usu di nodi da un serviziu di nuvola cum'è Amazon. Questa funzione ùn hè micca integrata in Kubernetes, ma cù Scalerd vi permetterà di scala sta piattaforma cumu vulete.
Vogliu nutà chì parechje persone mi dicenu: "Va bè è bè, ma chì ne di a mo basa di dati, chì hè di solitu statica?" Cumu pudete eseguisce qualcosa cusì in un ambiente dinamicu cum'è Kubernetes? In u mo parè, ùn deve micca fà questu, ùn deve micca pruvà à gestisce un magazzinu di dati in Kubernetes. Questu hè tecnicamente pussibule, è ci sò tutoriali in Internet nantu à questu sughjettu, ma cumplicà seriamente a vostra vita.
Iè, ci hè un cuncettu di magazzini persistenti in Kubernetes, è pudete pruvà à eseguisce magazzini di dati cum'è Mongo o MySQL, ma questu hè un compitu assai intensivu di travagliu. Questu hè duvuta à u fattu chì i magazzini di dati ùn sustene micca cumplettamente l'interazzione cù un ambiente dinamicu. A maiò parte di e basa di dati necessitanu una cunfigurazione significativa, cumpresa a cunfigurazione manuale di u cluster, ùn piace micca l'autoscaling è altre cose simili.
Dunque, ùn deve micca cumplicà a vostra vita per pruvà à gestisce un magazzinu di dati in Kubernetes. Organizà u so travagliu in u modu tradiziunale utilizendu servizii familiari è solu furnisce Kubernetes cù a capacità di usà.
Per cuncludi u tema, vogliu presentà à a piattaforma Cloud RTI basata in Kubernetes, chì u mo squadra travaglia. Fornisce un logu centralizatu, un monitoraghju di l'applicazioni è di u cluster, è parechje altre funzioni utili chì saranu utili. Aduprà diversi strumenti open-source cum'è Grafana per vede u monitoraghju.
Ci era una quistione di perchè aduprà l'equilibratore di carica ha-proxy cù Kubernetes. Bona dumanda perchè ci sò attualmente 2 livelli di bilanciamentu di carica. I servizii di Kubernetes sò sempre in indirizzi IP virtuali. Ùn pudete micca aduprà per i porti nantu à e macchine di l'ospiti esterni perchè se Amazon sovraccarica u so host cloud, l'indirizzu cambierà. Hè per quessa chì pusemu ha-proxy davanti à i servizii - per creà una struttura più statica per u trafficu per cumunicà in modu perfettu cù Kubernetes.
Un'altra bona quistione hè cumu pudete piglià a cura di i cambiamenti di schema di basa di dati quandu fate una implementazione blu / verde? U fattu hè chì, indipendentemente da l'usu di Kubernetes, cambià u schema di basa di dati hè un compitu difficiule. Avete bisognu di assicurà chì u vechju è u novu schema sò cumpatibili, dopu chì pudete aghjurnà a basa di dati è dopu aghjurnà l'applicazioni stessi. Pudete scambià a basa di dati è aghjurnà l'applicazioni. Sapemu di e persone chì anu avviatu un cluster di basa di dati completamente novu cù un novu schema, questa hè una opzione se avete una basa di dati senza schema cum'è Mongo, ma ùn hè micca un compitu faciule in ogni modu. Se ùn avete più dumande, grazie per a vostra attenzione!
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com