DEVOXX UK. Kubernetes tootmises: Blue/Green juurutamine, automaatne skaleerimine ja juurutamise automatiseerimine. Osa 2

Kubernetes on suurepärane tööriist Docker-konteinerite käitamiseks klastris töötamise keskkonnas. Siiski on olemas ülesandeid, mida Kubernetes ei suuda lahendada. Tiheda juurutamise korral töötavas keskkonnas vajame täielikult automatiseeritud Blue/Green juurutamist, et vältida seisakuid, millega tuleb samuti tegeleda väliste HTTP-päringutega ja hallata SSL-i eksporti. See nõuab integreerimist koormustaseme jagajaga, nagu ha-proxy. Teine ülesanne on klastrite pooleautomaatne skaleerimine Kubernetes, kui töötame pilves, näiteks klastrite osaline vähendamine öösel.

Kuigi Kubernetes ei paku neid funktsioone otse "karbist", on see varustanud API-ga, mille abil saab sarnaseid ülesandeid lahendada. Automatiseeritud Blue/Green juurutamise ja Kubernetes klastrite skaleerimise tööriidud on välja töötatud Cloud RTI projekti raames, mis loodi open-source'i põhjal.

Selles artiklis, video tõlgenduses, räägitakse, kuidas seadistada Kubernetes koos teiste avatud lähtekoodiga komponentidega tootmisvalmis keskkonna loomiseks, mis ilma seisakuteta käsitleb koodi git commit muutustest.

DEVOXX UK. Kubernetes tootmises: Blue/Green juurutamine, automaatne skaleerimine ja juurutamise automatiseerimine. Osa 1

Niipea kui olete oma rakendustele väljastpoolt juurdepääsu saanud, saate alustada automatiseerimise täielikku seadistamist, viies selle etappi, kus saab teha git commit ja veenduda, et see git commit jõuab tootmisse. Loomulikult ei soovi me nende sammude rakendamisel, juurutamisel, silmitsi seista seisakutega. Seega algab igasugune automatiseerimine Kuberneteses API-st.

Kubernetes ei ole tööriist, mida saaks produktiivselt kasutada "otsekoheselt karbist". Loomulikult võite seda nii teha, kasutada kubectl-i ja nii edasi, kuid API on siiski selle platvormi kõige huvitavam ja kasulik element. Kasutades API-d funktsioonide kogumina, pääsete ligi praktiliselt kõigile asjadele, mida soovite Kuberneteses teha. Ka kubectl kasutab endal REST API-d.

See on REST, nii et saate selle API-ga töötamiseks kasutada mistahes keeli ja tööriistu, kuid kasutajate raamatukogud muudavad teie elu oluliselt lihtsamaks. Minu meeskond on kirjutanud kaks sellist raamatukogu: ühe Java / OSGi jaoks ja ühe Go jaoks. Teist kasutatakse harva, kuid igal juhul on need kasulikud tööriistad teie käsutuses. Need on osaliselt litsentseeritud avatud lähtekoodiga projekt. Erinevatele keeltele on olemas palju selliseid raamatukogusid, nii et võite valida kõige sobivama.

Nii et enne automaatse juurutamise alustamist on oluline veenduda, et see protsess ei oleks märgitud mingite seisakutega. Näiteks meie meeskond viib tootmisjuurutuse läbi keset päeva, kui inimesed kasutavad rakendusi oma maksimaalses mahus, seega on väga oluline vältida viivitusi. Seisakute vältimiseks kasutatakse kahte meetodit: blue/green juurutamine või libisev värskendus rolling update. Viimasel juhul, kui teie rakendusel on 5 koopiat, uuendatakse neid järjestikku. See meetod töötab väga hästi, kuid ei sobi, kui juurutamise ajal on teil samaaegselt erinevad versioonid rakendusest. Sellisel juhul saate kasutajaliidese värskendada, samal ajal kui tagaplaat töötab vanema versiooniga, ja rakenduse töö katkeb. Seetõttu on programmeerimise seisukohalt sellistes tingimustes töö tegemine üsna keeruline.

See on üks põhjuseid, miks me eelistame kasutada blue/green juurutamist oma rakenduste automaatseks juurutamiseks. Selle meetodi puhul peate veenduma, et teatud hetkel on aktiivne ainult üks rakenduse versioon.

Blue/green juurutamise mehhanism on järgmine. Saame oma rakenduste liikluse läbi ha-proxy, mis suunab selle samade versioonide jooksvale koopiale.

Uue juurutuse teostamisel kasutame Deployer'i, millele antakse uued komponendid, ning see viib läbi uue versiooni juurutamise. Uue versiooni rakenduse juurutamine tähendab, et "tõstetakse" uus replika kogum, seejärel käivitatakse need uue versiooniga eraldi, uues konteineris. Siiski ei ole ha-proxy sellest teadlik ning ei suuna neile veel mingit koormust.

Seetõttu on esmajärjekorras vajalik teostada uue versiooni terviklikkuse kontroll, et veenduda replikate valmisolekus koormust teenindama.

Kõik juurutamise komponendid peavad toetama mingit vormi terviklikkuse kontrolli. See võib olla täiesti lihtne HTTP päring, kus saate 200 staatusekoode, või sügavam kontroll, kus kontrollite replikate ühendust andmebaasi ja teiste teenustega, dünaamilise keskkonna sidemete stabiilsust, ja kas kõik käivitub ja töötab õigesti. See protsess võib olla üsna keeruline.

Pärast seda, kui süsteem on veendunud, et kõik värskendatud replikad töötavad, uuendab Deployer konfiguratsiooni ja edastab õige confd, mis konfigureerib ha-proxy ümber.

Ainult pärast seda suunatakse liiklus konteinerrisse uue versiooni replikatega ning vana konteiner kaob.

See mehhanism ei ole Kubernetes'e spetsiifiline. Blue/green juurutamise kontseptsioon on olemas olnud juba pikka aega ja on alati kasutanud koormuse tasakaalustajat. Esmalt suuname kogu liikluse vana rakenduse versiooni, seejärel pärast värskendust suuname selle täielikult uue versiooni suunas. Seda põhimõtet kasutatakse mitte ainult Kubernetes'e puhul.

Praegu tutvustan ma teile uut juurutuskomponenti - Deployer, mis viib läbi terviklikkuse kontrolli, rekonfigureerib proxy jne. See on kontseptsioon, mis ei puuduta välist maailma ja eksisteerib Kubernetes'e sees. Näitan, kuidas luua omaenda Deployer'i kontseptsioon avatud lähtekoodiga tööriistade abil.

Nii et, esimene asi, mida Deployer teeb, on replikatsiooni kontrollija RC loomine, kasutades Kubernetes API-d. See API loob podid ja teenused edasiseks juurutamiseks, ehk loob täiesti uue klastrite meie rakendustele. Kui RC on kindel, et koopiad on käivitatud, viib ta läbi tervisekontrolli. Selleks kasutatakse Deployeris käsku GET /health. See käivitab vastavad kontrollkomponendid ja kontrollib kõiki elemente, mis tagavad klastrite töö.

Kui kõik podid on teatanud oma 'terves' seisundist, loob Deployer uue konfiguratsioonielemendi – jaotatud andmehoidla etcd, mida kasutatakse Kuberneteses, sealhulgas koormuse tasandaja konfiguratsiooni salvestamiseks. Me salvestame andmed etcd-sse ja väike tööriist confd jälgib etcd-d uute andmete ilmumise osas.

Kui ta tuvastab algse konfiguratsiooni muudatused, genereerib ta uue seadistust faili ja edastab selle ha-proxyle. Sel juhul taaskäivitub ha-proxy, kaotamata mingeid ühendusi, ja suunab koormuse uutele teenustele, mis tagavad meie uute rakenduste versioonide toimimise.

Nagu näete, ei ole siin, vaatamata komponentide arvule, midagi keerulist. Te peate lihtsalt rohkem tähelepanu pöörama API-le ja etcd-le. Ma tahan rääkida teile avatud koodiga juutisest, mida me ise kasutame – Amdatu Kubernetes Deployer.

See on tööriist Kubernetes'i juurutuste orkestreerimiseks, millel on järgmised funktsioonid:

• Blue/Green juurutamine;
• välist koormuse tasandaja seadistamine;
• juurutuste descriptorite haldamine;
• tegeliku juurutuse haldamine;
• tervenemisvõime tervisekontrollid juurutamise ajal;
• keskkonnamuutujate sisestamine podidesse.

See Deployer on loodud Kubernetes API tipul ja esindab REST API-d descriptorite ja juurutuste haldamiseks ning Websocket API-d juurutamise ajal logide voogedastamiseks.

Ta paneb koormuse tasandaja konfiguratsiooni andmed etcd-sse, seega ei pea te kasutama ha-proxy't 'karbist välja', vaid saate hõlpsasti kasutada oma koormuse tasandaja konfiguratsiooni faili. Amdatu Deployer on kirjutatud Go keeles, nagu ka Kubernetes ise, ja on litsentseeritud Apache.

Enne selle versiooni kasutusele võtmist kasutasin järgmist juurutuse deskriptorit, mis sisaldab mulle vajalikke parameetreid.

Üks selle koodi olulisi parameetreid on lipu „useHealthCheck“ aktiveerimine. Me peame näitama, et juurutamise käigus tuleb teostada töökontrolli kontroll. See parameeter võib olla välja lülitatud, kui juurutuses kasutatakse kolmandate osapoolte konteinerid, mida ei pea kontrollima. Selles deskriptoris on ka määratud replikate arv ja ha-proxy jaoks vajalik esiplaanide URL. Lõpus on määratud podi spefikatsiooni lipp „podspec“, mis pöördub Kubernetes'i poole portsade, pildi jne seadistamise teabe saamiseks. See on suhteliselt lihtne deskriptor JSON formaadis.

Veel üks tööriist, mis on osa avatud lähtekoodiga projektist Amdatu, on Deploymentctl. Sellel on kasutajaliides juurutamise seadistamiseks, see säilitab juurutamise ajalugu ja sisaldab veebikutseid kolmandate kasutajate ja arendajate jaoks. Te ei pea kasutama kasutajaliidest, kuna Amdatu Deployer on REST API, kuid see liides võib oluliselt lihtsustada juurutamist ilma ühegi API kaasamiseta. Deploymentctl on kirjutatud OSGi/Vertx koos Angular 2 kasutamisega.

Nüüd demonstreerin eelnevat ekraanil, kasutades ettevalmistatud salvestust, nii et te ei pea ootama. Juurutame lihtsa rakenduse Go-s. Ärge muretsege, kui te pole Go-s varem kokku puutunud, see on väga lihtne rakendus, nii et kõik peaks olema arusaadav.

Siin loome HTTP-serveri, mis vastab ainult /health, nii et see rakendus kontrollib ainult töökontrolli, mitte midagi enamat. Kui kontroll läbib, aktiveeritakse allpool esitatud JSON-struktuur. See sisaldab rakenduse versiooni, mis juurutatakse deploieriga, sõnumit, mida näete faili ülaosas, ja boolean-tüüpi, mis näitab, kas meie rakendus on töökorras või mitte.

Viimase rea osas olin ma natuke petlik, sest panin faili ülaossa fikseeritud boolean väärtuse, mis aitab mul hiljem juurutada isegi "haige" rakenduse. Hiljem käsitleme seda.

Nii, alustame. Esiteks kontrollime, kas mõni pod on juba käimas käsu abil ~ kubectl get pods ja kui frontendi URL-i vastust ei tule, siis veendume, et praegu ei toimu mingit juurutamist.

Edasi näete ekraanil Deploymentctl’i liidest, kus määratakse juurutamise parameetrid: nimekiri, rakenduse nimi, juurutamise versioon, replikate arv, frontendi URL, konteineri nimi, pilt, ressursipiirangud, kontrollimise pordi number jne. Ressursipiirangud on äärmiselt olulised, kuna need võimaldavad kasutada maksimaalset võimalikku riistvara. Siin saate ka vaadata juurutamise ajalugu Deployment log.

Kui praegu järgida käsku ~ kubectl get pods, siis on näha, et süsteem "seisab paigal" 20 sekundit, mille jooksul toimub ha-proxy rekodeerimine. Pärast seda käivitatakse pod ja meie replikat on võimalik näha juurutamise logis.

Olen videost välja lõiganud 20-sekundilise ooteaja ja nüüd näete ekraanil, et rakenduse esimene versioon on juurutatud. Kõik see tehti ainult UI abil.

Nüüd proovime teist versiooni. Selleks muudan rakenduse sõnumi "Hello, Kubernetes!" asemel "Hello, Deployer!", süsteem loob selle pildi ja üles laeb selle Docker registerisse, seejärel vajutame lihtsalt veel kord Deploymentctl’i aknas nupule "Deploy". Sellega käivitatakse automaatselt juurutamise log, just nagu see toimus esimese rakenduse versiooni juurutamisel.

Käsku ~ kubectl get pods näitab, et praegu on käimas 2 versiooni rakendusest, kuid frontendi poolt näidatakse, et meil on endiselt töötamas versioon 1.

Koormuse tasakaalustaja ootab, kuni toimub tervisekontroll, pärast mida suunatakse liiklus uuele versioonile. 20 sekundi pärast lülitume curlile ja näeme, et nüüd on juurutatud 2. versioon rakendusest, samas esimene on eemaldatud.

See oli "tervise" - healthy - rakenduse juurutamine. Vaadakem, mis juhtub, kui muudan uue versiooni rakenduse terviseparameetri väärtuse true'lt false'le, st üritan juurutada mitteterved rakendust, mis ei läbinud töökindluse kontrolli. See võib juhtuda, kui arenduse etapis on rakenduses tehtud mingisuguseid konfiguratsioonivigu ja see saadeti sellisel kujul tootmisse.

Nagu näete, läbib juurutamine kõik ülalkirjeldatud etapid ja ~ kubectl get pods näitab, et mõlemad podid on käivitatud. Kuid erinevalt eelmisest juurutamisest näitab logi olek timeout. See tähendab, et kuna health check‘i kontroll ebaõnnestus, ei saa uut rakenduse versiooni juurutada. Tulemuseks on see, et süsteem naaseb vana rakenduse versiooni kasutamisele ning uus versioon eemaldatakse lihtsalt.

Hea on see, et isegi kui teil on suur hulk samaaegseid päringuid, mis rakendusse jõuavad, ei märka nad juurutamisprotseduuri ajal katkestusi. Kui testida seda rakendust Gatlingi raamistiku abil, mis edastab sellele maksimaalselt võimalikke päringuid, siis ei jäeta ühtegi neist päringutest kõrvale. See tähendab, et meie kasutajad ei märka isegi versioonide uuendust reaalajas. Kui see ebaõnnestub, jätkab töö vana versiooni kasutamist, kui see õnnestub – kasutajad liiguvad uuele versioonile.

On ainult üks asi, mis võib ebaõnnestuda – kui health check läbis eduka kontrolli, aga rakendus ebaõnnestus kohe, kui sellele koormus tuli, st kokkuvarisemine toimub alles pärast juurutamise lõppemist. Sellisel juhul peate käsitsi naasma vana versiooni juurde. Nii et oleme vaadanud, kuidas kasutada Kubernetes't sellele mõeldud avatud lähtekoodiga tööriistadega. Juurutamisprotseduur läheb palju sujuvamalt, kui integreerite need tööriistad Build/Deploy torustikesse. Samuti saate juurutamise käivitamiseks kasutada nii kasutajaliidest kui ka täielikult automatiseerida selle protsessi, rakendades näiteks commit to master.

Meie Build Server loob Docker-pildi, laadib selle Docker Hubi või mis tahes muu kasutatava registri sisse. Docker Hub toetab webhooke, seega saame käivitada kaugjuurutamise vaikimisi eespool näidatud viisil. Nii saab rakenduse juurutamise täielikult automatiseerida potentsiaalsesse tootmisse.

Liigume järgmise teema – Kubernetes klastrite skaleerimise – juurde. Tahan märkida, et kubectl käsk on skaleerimise käsk. Selle abil on lihtne suurendada meie klastris olevate replikate arvu. Siiski soovime praktikas tavaliselt suurendada mitte podide, vaid node'ide arvu.

Töötamise ajal võib teil vaja minna skaleerimist ja öösiti, et vähendada Amazon'i teenuste kulusid, tuleks rakenduse käivitatud näidiste arvu vähendada. See ei tähenda, et piisab ainult podide skaleerimisest, sest isegi kui üks node on tühi, peate ikkagi selle eest Amazon'ile maksma. Seega tuleb lisaks podide skaleerimisele ka masinate arvu suurendada.

See võib tekitada raskusi, kuna hoolimata sellest, kas kasutame Amazon'i või mõnda teist pilveteenust, ei tea Kubernetes midagi kasutatavate masinate arvust. Sellest puudub tööriist süsteemi skaleerimiseks node'ite tasemel.

Seega peame hoolitsema nii node'ite kui ka podide eest. Me saame hõlpsasti käivitada uusi node'e AWS API ja skaleerimisgrupi masinate abil, et seadistada Kubernetes'e töötavate sõlmede arvu. Samuti on võimalik kasutada cloud-init või sarnast skripti node'ite registreerimiseks Kubernetes klastris.

Uus masin käivitub Scaling group'is, registreerib end sõlmena, kirjutatakse meistri registrisse ja alustab tööd. Pärast seda saab suurendada koopiaid, et kasutada loodud sõlmedes. Skaalamise vähendamine nõuab suuremaid jõupingutusi, kuna tuleb veenduda, et selline samm ei tooks kaasa juba aktiivsete rakenduste hävitamist pärast "mittevajalike" masinate väljalülitamist. Sellise stsenaariumi vältimiseks tuleb viia sõlmed „unschedulable” staatuse. See tähendab, et vaikeplaneerija ignoreerib neid sõlmi, kui ta planeerib DaemonSet-i pude. Planeerija ei eemalda sealt midagi, kuid ei alusta seal uusi mahuteid. Järgmine samm on sõlme tühjendamine, see tähendab tööpudede ülekandmine teisele masinale või teistele sõlmedele, millel on selleks piisavalt mahutavust. Kui veenduda, et nendel sõlmedel pole enam mahuteid, saab need Kubernetesest eemaldada. Pärast seda lõpetavad nad Kuberneteses lihtsalt olemise. Edasi tuleb kasutada AWS API-d tarbetute sõlmede, või masinate, väljalülitamiseks.
Saate kasutada Amdatu Scalerd'i — veel ühte open-source tööriista, mis sarnaneb AWS API-le. See pakub CLI-d sõlmede lisamiseks või eemaldamiseks klastrist. Selle huvitav omadus on võimalus seadistada planeerijat järgmise json-faili abil.

Kood, mida on kujutatud, vähendab klastrite mahutavust öösel poole võrra. See on seadistatud nii olemasolevate koopiaide arvu kui ka soovitud Amazon'i klastrite mahutavuse jaoks. Selle planeerija kasutamine vähendab automaatselt sõlmede arvu öösel ja suurendab neid hommikul, võimaldades säästa kulusid selliste pilveteenuste, nagu Amazon, sõlmede kasutamisel. See funktsioon ei ole Kubernetesesse sisse ehitatud, kuid Scalerd'i kasutamine võimaldab teil seda platvormi igal viisil skaleerida.

Tahan juhtida teie tähelepanu sellele, et paljud inimesed ütlevad mulle: „See kõik on tore, aga mis toimub minu andmebaasiga, mis tavaliselt on staatilises olekus?” Kuidas saaks midagi sellist käivitada nii dünaamilises keskkonnas nagu Kubernetes? Minu arvates ei tohiks te seda teha, te ei peaks proovima korraldada andmehoidla tööd Kuberneteses. Tehniliselt on see võimalik ja internetis on selle kohta juhiseid, kuid see keerab teie elu tõsiselt keeruliseks.

Jah, Kuberneteses eksisteerib püsihoiustamise mõisted ja võite proovida käitada selliseid andmehoidlaid nagu Mongo või MySQL, kuid see on üsna töömahukas ülesanne. See on seotud sellega, et andmehoidlad ei toeta täielikult koostööd dünaamilise keskkonnaga. Enamik andmebaase vajab olulist seadistamist, sealhulgas klastrite käsitsi seadistamist, nad ei meeldi automaatse skaleerimisele ja muudele sarnastele asjadele.
Seetõttu pole mõtet endale elu keeruliseks teha, proovides käitada andmehoidlat Kuberneteses. Korraldage nende töö traditsioonilise meetodi abil, kasutades tuttavaid teenuseid, ja laske Kubernetesel neid kasutada.

Kokkuvõtteks soovin tutvustada teile Cloud RTI platvormi Kubernetesel, mille kallal töötab minu meeskond. See pakub tsentraliseeritud logimist, rakenduste ja klastrite jälgimist ning omab palju muid kasulikke funktsioone, mis teile kasuks tulevad. Platvorm kasutab erinevaid avatud lähtekoodiga tööriistu, nagu Grafana, jälgimise kuvamiseks.

Küsimus, miks kasutada Kubernetesega koos koormuse tasandajat ha-proxy. Hea küsimus, sest praegu on olemas kaks taset koormuse tasandamisel. Kubernetes teenused on endiselt virtuaalsetel IP-aadressidel. Te ei saa neid kasutada väliste hostmasinate portide jaoks, kuna kui Amazon oma pilveteenuseid üle koormab, muutub aadress. Seetõttu paigutame ha-proxy teenuste ette — et luua stabiilsem struktuur sujuvaks liiklustihedust Kubernetesega.

Veel hea küsimus – kuidas saab andmebaasi skeemi muutmisega tegeleda blue/green deployment'i ajal? Asi on selles, et olenemata Kubernetesest on andmebaasi skeemi muutmine keeruline ülesanne. Peate tagama vana ja uue skeemi ühilduvuse, seejärel saate andmebaasi uuendada ja seejärel rakendused uuendada. Saate teha andmebaasi "kuuma vahetuse" (hot swapping) ja seejärel rakendused uuendada. Mul on tuttavaid, kes on laadinud täiesti uue andmebaasi klastrisse koos uue skeemiga; see on valik, kui teil on schemeless andmebaas nagu Mongo, kuid igal juhul pole see lihtne ülesanne. Kui rohkem küsimusi pole, tänan tähelepanu eest!

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com