Kubernetes on suurepärane tööriist Docker konteinerite käitamiseks klastris. Siiski on ülesandeid, mida Kubernetes ei suuda lahendada. Tööprotsessis, kus toimub sagedane juurutamine, vajame täielikult automatiseeritud Blue/Green juurutamist, et vältida seisakuid, kus tuleb samuti hallata väliseid HTTP-päringuid ja teostada SSL-i ütlemist. See nõuab integreerimist koormuse tasakaalustajaga, nagu ha-proxy. Teine probleem on Kubernetes klastrite osaline automaatne skaleerimine pilves, näiteks klastrite osaline vähendamine öösel.
Kuigi Kubernetes ei oma neid funktsioone otse „karbist”, pakub see API-d, mida saab kasutada sarnaste ülesannete lahendamiseks. Automaatsete Blue/Green juurutus- ja skaleerimistööriistad Kubernetes klastris on arendatud Cloud RTI projekti raames, mis loodi open-source tehnoloogia alusel.
Selles artiklis, videote selgitamisel, räägitakse, kuidas seadistada Kubernetes koos muude avatud lähtekoodiga komponente tootmiskeskkonna loomiseks, mis talub koodi git commit muudatustest ilma seisakuteta tootmises.
Niipea kui olete saanud oma rakendustele väljastpoolt juurdepääsu, saab alustada automatiseerimise täielikku seadistamist, viies selle staadiumisse, kus saab teha git commit ja veenduda, et see git commit jõuab tootmisse. Loomulikult ei soovi me, et nendest sammudest, juurutamisest, tekiks seisakuid. Seega algab kogu automatiseerimine Kubernetesis API-st.
Kubernetes ei ole tööriist, mida saaks produktiivselt kasutada «otsemüügist». Loomulikult võid sa seda nii teha, kasutada kubectl jms, kuid API on selle platvormi kõige huvitavam ja kasulikum osa. Kasutades API-d funktsioonide komplektina, saad ligipääsu peaaegu kõigile asjadele, mida soovid Kuberneteses teha. Kubectl kasutab ka ise REST API-d.
See on REST, seega võid kasutada selle API-ga töötamiseks mistahes programmeerimiskeeli ja tööriistu, kuid kasutajate raamatukogud muudavad su elu märkimisväärselt lihtsamaks. Minu meeskond on kirjutanud kaks sellist raamatukogu: ühe Java / OSGi jaoks ja teise Go jaoks. Teist kasutatakse mittetihti, kuid igal juhul on need kasulikud asjad sinu käsutuses. Need on osaliselt litsentseeritud avatud lähtekoodiga projekt. Erinevatele keeledele on olemas palju selliseid raamatukogusid, et saaksid valida endale sobivad.
Enne juurutamise automatiseerimisega alustamist on oluline veenduda, et see protsess ei põhjustaks mingeid seiskamisi. Näiteks meie meeskond viib tootmisjuurutuse läbi keskpäeval, kui inimesed kasutavad rakendusi enim, seetõttu on äärmiselt oluline vältida protsessi viivitusi. Seiskamiste vältimiseks kasutatakse kahte meetodit: blue/green juurutamine või skaleeritav värskendus (rolling update). Viimasel juhul, kui teil on töötamas 5 rakenduse koopiat, uuendatakse neid järjestikku üks pärast teist. See meetod töötab suurepäraselt, kuid see ei sobi, kui juurutamise käigus on teil samaaegselt käimas erinevad rakenduse versioonid. Sellisel juhul võite kasutajaliidese värskendada samal ajal, kui tagumise poole töötavad vanema versiooniga, ja rakenduse töö katkeb. Seega on sellistes tingimustes programmeerimine üsna keeruline.
See on üks põhjusi, miks eelistame kasutada blue/green juurutamist oma rakenduste juurutamise automatiseerimiseks. Sellise lähenemise puhul tuleb teil veenduda, et antud hetkel on aktiivne ainult üks rakenduse versioon.
Blue/green juurutamise mehhanism töötab järgmiselt. Suuname oma rakendustele liikluse läbi ha-proxy, mis suunab selle sama versiooni käivitatud replikatele.
Kui toimub uus juurutamine, kasutame Deployerit, millele antakse uued komponendid, ja see viib ellu uue versiooni juurutamise. Uue versiooni rakenduse juurutamine tähendab, et „tõuseb” uus replikate komplekt, seejärel käivitatakse need uue versiooni replikad eraldi, uues podis. Kuid ha-proxy ei tea neist midagi ja ei suuna neile veel mingit töökoormust.
Seetõttu on esmane samm uute versioonide töö kontrollimiseks health checking, et veenduda, et replikad on valmis koormust teenindama.
KÕIK rakenduste komponentide juurutamised peavad toetama mingit vormi tervise kontrolli. See võib olla üsna lihtne HTTP päring, millega saadakse 200 staatuse kood, või põhjalikum kontroll, kus kontrollitakse koopiate ühendust andmebaasi ja teiste teenustega, dünaamilise keskkonna ühenduste usaldusväärsust ning kas kõik töötab ja töötab korralikult. See protsess võib olla üsna keeruline.
Pärast seda, kui süsteem on veendunud, et kõik uuendatud koopiad töötavad, uuendab Deployer konfiguratsiooni ja edastab õige confd, mis konfigureerib uuesti ha-proxy.
Ainult pärast seda suunatakse liiklus uue versiooni koopiatega alla ja vana all kaob.
See mehhanism ei ole Kubernetes'e eripära. Blue/green juurutamise kontseptsioon on eksisteerinud juba pikka aega ja see on alati kasutanud koormuse tasandajat. Esmalt suunate kogu liikluse vanemale versioonile ja pärast uuendamist suunate selle täielikult uuele versioonile. Seda põhimõtet kasutatakse mitte ainult Kubernetes'es.
Tutvustan teile uut juurutuse komponenti - Deployer, mis viib läbi töökindluse kontrolli, konfigureerib ümber proksi jne. See on kontseptsioon, mis ei ole seotud välismaailma ja eksisteerib Kuberneteses. Näitan, kuidas luua omaenda Deployer kontseptsioon avatud lähtekoodiga tööriistade abil.
Nii et esimene asi, mida Deployer teeb - loob replikatsiooni kontrolleri RC, kasutades Kubernetes API-d. See API loob pod'id ja teenused edasiseks juurutamiseks, st loob täiesti uue klastri meie rakenduste jaoks. Kui RC veendub, et replikad on käivitatud, siis viib ta läbi nende töökindluse kontrolli. Selleks kasutatakse Deployeris käsku GET /health. See käivitab vastavad kontrollkomponendid ja kontrollib kõiki elemente, mis tagavad klastri töö.
Kui kõik podid on oma "tervise" kohta teatanud, loob Deployer uue konfiguratsiooni elemendi – jaotatud etcd-salvestuse, mida kasutatakse Kubernetes'i sees, sealhulgas koormuse tasakaalustaja konfiguratsiooni salvestamiseks. Me salvestame andmeid etcd-sse ning väike tööriist confd jälgib etcd-d, et tuvastada uusi andmeid.
Kui see tuvastab mingeid muudatusi algses konfiguratsioonis, genereerib see uue seadistust faili ja edastab selle ha-proxy'le. Sel juhul taaskäivitab ha-proxy oma ühendusi kaotamata ja suunab koormuse uutele teenustele, mis tagavad meie rakenduste uue versiooni toimimise.
Nagu näete, ei ole siin, hoolimata komponentide rohkusest, midagi keerulist. Peate lihtsalt rohkem tähelepanu pöörama API-le ja etcd-le. Soovin rääkida teile avatud lähtekoodiga deployerist, mida me ise kasutame - see on Amdatu Kubernetes Deployer.
See on tööriist Kubernetes'i juurutuste orkestreerimiseks, millel on järgmised funktsioonid:
- Blue/Green deployment juurutamine;
- välist koormuse tasakaalustaja seadistamine;
- juurutuste descriptoride haldamine;
- tõelise juurutuse haldamine;
- Terviklikkuse kontrollimine Health checks juurutamise ajal;
- Keskkonnaparameetrite sissetoomine podidesse.
See Deployer on loodud Kubernetes API üle ja pakub REST API-d descriptorite ja juurutuste haldamiseks ning Websocket API-d juurutamise ajal voogedastamiseks logides.
See paneb koormuse tasakaalustaja konfiguratsiooni andmed etcd-sse, seega ei pea te kasutama ha-proxy-d 'kastist välja', vaid saate lihtsalt kasutada oma koormuse tasakaalustaja konfiguratsiooni faili. Amdatu Deployer on kirjutatud Go-s, nagu ka Kubernetes ise, ja litsentseeritud Apache all.
Enne selle versiooni rakendamise alustamist kasutasin järgmist juurutuse deskriptorit, kus on määratud vajalikud parameetrid.
Üks selle koodi olulisi parameetreid on lipu „useHealthCheck“ lubamine. Peame näitama, et juurutamise käigus tuleb teostada töökindluse kontroll. Seda parameetrit võib välja lülitada, kui juurutamisel kasutatakse kolmandate osapoolte konteine, mida ei ole vaja kontrollida. Sellel descriptoril on samuti määratud replikaarv ja ha-proxy vajaliku eesmine URL. Lõpus on podspec'i spetsiifikalipp, mis suunab Kubernetes'i sadamate, pildi jne seadistamise teabe saamiseks. See on üsna lihtne descriptor JSON formaadis.
Veel üks tööriist, mis on osa avatud lähtekoodiga projektist Amdatu, on Deploymentctl. Sellel on kasutajaliides (UI) juurutamise seadistamiseks, see salvestab juurutamise ajaloo ning sisaldab veebi konksu tagasikutsumiste jaoks kolmandate osapoolte kasutajatelt ja arendajatelt. Te ei pruugi kasutada UI-d, kuna Amdatu Deployer ise on REST API, kuid see liides võib juurutamist oluliselt lihtsustada ilma igasuguse API kaasamiseta. Deploymentctl on kirjutatud OSGi/Vertx koos Angular 2-ga.
Nüüd demonstreerin öeldut ekraanil, kasutades eelnevalt salvestatud videot, nii et teil ei pea ootama. Me seadistame lihtsat rakendust Go-s. Ärge muretsege, kui te pole varem Go-t kasutanud; 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öövalmidust ja mitte midagi muud. Kui kontroll läheb läbi, kuvatakse allpool näidatud JSON-struktuur. See sisaldab versiooni rakendusest, mida juurutatakse, sõnumit, mida näete faili ülaosas, ja loogilist andmetüüpi boolean — kas meie rakendus on töötav või mitte.
Viimase rea juures ma pisut petasin, sest panin faili ülaossa fikseeritud boolean väärtuse, mis aitab mul hiljem isegi "haige" rakenduse juurutada. Hiljem saame sellega tegelema hakata.
Nii et alustame. Esiteks kontrollime, kas on aktiveeritud mingeid pod'e, kasutades käsku ~ kubectl get pods, ja kui esiosa URL-st vastust ei tule, veendume, et praegu ei toimu mingeid juurutamisi.
Edasi näete ekraanil Deploymentctl'i liidest, kus määratakse juurutamise parameetrid: nimekiri, rakenduse nimi, juurutamise versioon, replikaid, front-end URL, konteineri nimi, pilt, ressursi piirangud, tervisekontrolli port jne. Ressursi piirangud on väga olulised, kuna need võimaldavad maksimaalselt kasutada olemasolevat riistvara. Siin saab ka vaadata juurutamislogi.
Kui nüüd korrata käsku ~ kubectl get pods, on näha, et süsteem «peatub» 20 sekundiks, mille jooksul toimub ha-proxy rekonstruktsioon. Pärast seda käivitatakse pod ja meie replika on näha juurutamislogis.
Olen videost välja lõigatud 20-sekundilise ootamise, 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 "Tere, Kubernetes!" muutumisel "Tere, Deployer!", süsteem loob selle pildi ja paigutab selle Docker registrisse, pärast mida vajutame lihtsalt veel kord nupule "Deploy" aknas Deploymentctl. Sellega algab automaatselt juurutamise logi, just nagu see toimus esmakordse rakenduse juurutamise ajal.
Käsk ~ kubectl get pods näitab, et hetkel on käimas 2 versiooni rakendusest, kuid front-end näitab, et meil töötab ikka veel versioon 1.
Tasakaalustaja ootab, kuni tervisekontroll toimub, pärast mida suunab ta liikluse uue versiooni poole. 20 sekundi pärast vahetame curlile ja näeme, et nüüd on meil juurutatud 2. versioon rakendusest, samas kui esimene on eemaldatud.
See oli "terve" rakenduse juurutamine. Vaadakem, mis juhtub, kui muudan rakenduse uue versiooni puhul parameetri Healthy väärtuse true-st false-ks, st üritan juurutada mittefunktsionaalset rakendust, mis ei ole läbinud töökindluse kontrolli. See võib juhtuda, kui arendusetapis on rakenduses tehtud mingid konfiguratsiooni vead ja see saadeti sellisena tootmisesse.
Nagu näete, läbib juurutamine kõik ülaltoodud etapid ja ~ kubectl get pods näitab, et mõlemad podid on käimas. Kuid erinevalt eelmisest juurutamisest näitab logi timeout'i seisundit. See tähendab, et kuna health check'i kontroll ebaõnnestus, ei saa rakenduse uus versioon juurutada. Tulemusena näete, et süsteem naases vana rakenduse versiooni kasutamise juurde ja uus versioon eemaldati lihtsalt.
Hea on see, et isegi kui teie rakendusse jõuab suur hulk samaaegseid päringuid, ei märka nad isegi seisakut rakendamise protsessi ajal. Kui testite seda rakendust Gatlingi raamistikuga, mis saadab sellele maksimaalselt võimaliku hulga päringuid, ei lükka ükski neist päringutest tagasi. See tähendab, et meie kasutajad ei märkagi versioonide ajakohastamist reaalajas. Kui see ebaõnnestub, jätkatakse vana versiooniga; kui see õnnestub, liikuvad kasutajad uuele versioonile.
Ainult üks asi võib viia ebaõnnestumiseni – kui health check on läbitud ja rakendus peatub kohe, kui koormus sellele laekub, siis kokkuvarisemine toimub alles pärast juurutamise lõpetamist. Sel juhul peate käsitsi tagasi minema vanemale versioonile. Nii et oleme arutanud, kuidas kasutada Kubernetesit koos sellele mõeldud avatud lähtekoodiga tööriistadega. Juurutamisprotsess kulgeb palju sujuvamalt, kui integreerite need tööriistad oma Build/Deploy torudesse. Sellega võite kasutada juurutamise käivitamiseks nii kasutajaliidest kui ka täielikult automatiseerida protsesse, rakendades näiteks commit to master.
Meie Build Server loob Docker pildi, laadib selle Docker Hubi või mõnda muusse teie kasutatavasse registrisse. Docker Hub toetab webhook'e, seega saame käivitada kaugjuurutamise kaudu Deployer eespool näidatud viisil. Nii saab rakenduse juurutamise täiesti automatiseerida potentsiaalsesse tootmisse.
Liigume järgmise teema – Kubernetes klastrite skaleerimise – juurde. Tõin välja, et kubectl käsk on skaleerimise käsk. Selle abil on lihtne suurendada olemasolevate replikate arvu meie klastris. Praktikas tahame me siiski suurendada mitte podide, vaid nootide arvu.
Töötamise ajal võib vaja minna suurendamist, samas kui öösel, et vähendada Amazon'i teenuste kulusid, tuleb vähendada käimasolevate rakenduste koopiaid. See ei tähenda, et piisab ainult podide arvu skaleerimisest, sest isegi kui üks noot ei ole hõivatud, peate ikkagi selle eest Amazonile maksma. See tähendab, et podide skaleerimise kõrval peate skaleerima ka kasutatavate masinate arvu.
See võib tekitada raskusi, sest sõltumata sellest, kas kasutame Amazoni või mõnda muud pilveteenust, ei tea Kubernetes midagi kasutatavate masinate arvust. Tal ei ole tööriista, mis võimaldaks süsteemi skaleerida nootide tasemel.
Seega peame hoolitsema nii sõlmede kui ka podide eest. Uute sõlmede käivitamise suurendamine on lihtne AWS API ja skaleerimisgrupi (Scaling group) masinate abil, et seadistada Kubernetes'e töötlusettevõtete arv. Samuti saab kasutada cloud-init või sarnast skripti, et registreerida sõlmed Kubernetes'e klastri.
Uus masin käivitub Scaling group'is, algatab end sõlmena, registreerib end õhhis ja alustab tööd. Pärast seda saab suurendada replikate arvu, et kasutada moodustunud sõlmedes. Skaala vähendamine nõuab suuremaid pingutusi, kuna on vajalik tagada, et seesugune samm ei viiks juba töötavate rakenduste hävitamiseni pärast "mittevajalike" masinate väljalülitamist. Sellise stsenaariumi vältimiseks tuleb viia sõlmed 'unschedulable' olekusse. See tähendab, et planeerija ignoreerib neid sõlmi DaemonSet'i pod'ide plaanimisel. Planeerija ei eemalda midagi nende serverite pealt, kuid ei hakka sinna ka uusi konteineri käivitama. Järgmine samm on sõlme drenaž, s.t. töötavate pod'ide üleviimine teisele masinale või teistele sõlmedele, mis omavad sellele piisavat mahtu. Kui on veendunud, et nendel sõlmedel ei ole enam kontaine, saab need Kubernetesest eemaldada. Pärast seda lakkavad nad Kuberneteses olemast. Edasi tuleb kasutada AWS API-d, et väljalülitada mittevajalikke sõlmi või masinaid.
Te saate kasutada Amdatu Scalerd - veel üht avatud lähtekoodiga tööriista skaleerimiseks, mis sarnaneb AWS API-le. See pakub CLI-d klastrisse sõlmede lisamiseks või eemaldamiseks. Selle huvitavaks omaduseks on võimalus seadistada ajakava järgmise json-failiga.
Kood, mis on näidatud, vähendab klastrivõimsust öösiti poole võrra. See on seadistatud nii olemasolevate replikate arvu kui ka soovitud Amazon'i klastrivõimsuse jaoks. Selle ajakava kasutamine vähendab automaatselt sõlmede arvu öösel ja suurendab seda hommikul, võimaldades kokku hoida kulusid sõlmede kasutamisel sellises pilveteenuses nagu Amazon. See funktsioon ei ole Kubernetes'e sisse ehitatud, kuid Scalerd'i kasutamine võimaldab teil seda platvormi skaleerida meelepärasel viisil.
Soovin juhtida tähelepanu sellele, et paljud inimesed ütlevad mulle: "See kõik on hea, aga mis saab minu andmebaasist, mis tavaliselt on staatilises olekus?" Kuidas on võimalik midagi sellist käivitada dünaamilises keskkonnas nagu Kubernetes? Minu arvates ei peaks te seda tegema, ei peaks proovima korraldada andmehoidla toimimist Kuberneteses. Tehniliselt on see võimalik, ja internetis on selle kohta juhiseid, kuid see raskendab tõsiselt teie elu.
Jah, Kuberneteses on olemas püsivate andmehoidlate mõisted, ja võite proovida käivitada andmehoidlaid nagu Mongo või MySQL, kuid see on üsna aeganõudev ülesanne. See on seotud sellega, et andmehoidlad ei toeta täielikult suhtlemist dünaamilises keskkonnas. Enamik andmebaase nõuab olulist seadistamist, sealhulgas käsitsi klastrite seadistamist ning ei armasta automaatset skaleerimist ja muid sarnaseid asju.
Seetõttu ei tasu endale elu keeruliseks teha, püüdes andmesalvestust Kuberneteses käivitada. korraldage nende töö traditsiooniliselt tuttavate teenuste abil ja laske Kubernetesel neid kasutada.
Kokkuvõtteks tahaksin teid tutvustada Cloud RTI platvormiga, mis põhineb Kubernetesel ja mille kallal töötab minu meeskond. See pakub keskset logide haldamist, rakenduste ja klastrite monitooringut ning omab palju teisi kasulikke funktsioone, mis võivad teile kasuks tulla. Platvormil kasutatakse erinevaid avatud lähtekoodiga tööriistu, nagu Grafana monitooringu kuvamiseks.
Küsimus kerkis, miks kasutada Kubernetesega koos koormuse jaotajat ha-proxy. Hästi esitatud küsimus, kuna praegu on olemas 2 koormuse jaotustasandit. Kubernetes teenused asuvad endiselt virtuaalsetel IP-aadressidel. Te ei saa neid kasutada väliste host-masinate portidele, kuna kui Amazon üle koormab oma pilvema, muutub aadress. Sellepärast asetame ha-proxy teenuste ette — et luua stabiilsem struktuur, et liiklus saaks sujuvalt suhelda Kubernetesega.
Veel hea küsimus – kuidas hoolitseda andmebaasi skeemi muutmise eest blue/green deployment'i puhul? Tegelikult on andmebaasi skeemi muutmine keeruline ülesanne, sõltumata Kubernetes'i kasutamisest. Peate tagama vana ja uue skeemi ühilduvuse, seejärel saate andmebaasi uuendada ja seejärel rakendusi. Saate teostada „kuuma vahetuse“ andmebaasi, seejärel uuendada rakendusi. Tunnen inimesi, kes on laadinud täiesti uue andmebaasi klastri uue skeemiga, see on variant, kui teil on schemeless andmebaas nagu Mongo, kuid igal juhul ei ole see lihtne ülesanne. Kui küsimusi rohkem ei ole, tänan tähelepanu eest!
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. , ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).
Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas
Allikas: habr.com
