Kubernetes je odlično orodje za izvajanje vsebnikov Docker v produkcijskem okolju z gručami. Vendar pa obstajajo težave, ki jih Kubernetes ne more rešiti. Za pogoste produkcijske uvedbe potrebujemo popolnoma avtomatizirano modro/zeleno uvajanje, da se izognemo izpadom v procesu, ki mora obravnavati tudi zunanje zahteve HTTP in izvajati prenose SSL. To zahteva integracijo z izravnalnikom obremenitve, kot je ha-proxy. Drug izziv je polavtomatsko skaliranje same gruče Kubernetes, ko deluje v okolju oblaka, na primer delno skaliranje gruče ponoči.
Čeprav Kubernetes teh funkcij nima takoj po namestitvi, ponuja API, ki ga lahko uporabite za reševanje podobnih težav. Orodja za avtomatizirano Blue/Green postavitev in skaliranje gruče Kubernetes so bila razvita v okviru projekta Cloud RTI, ki je nastal na podlagi odprtokodnosti.
Ta članek, video prepis, vam pokaže, kako nastavite Kubernetes skupaj z drugimi odprtokodnimi komponentami, da ustvarite okolje, pripravljeno za proizvodnjo, ki sprejema kodo iz objave git brez izpadov v proizvodnji.
Torej, ko imate dostop do svojih aplikacij iz zunanjega sveta, lahko začnete v celoti nastavljati avtomatizacijo, to je, da jo pripeljete do stopnje, kjer lahko izvedete potrditev git in poskrbite, da bo ta potrditev git končala v proizvodnji. Seveda pri izvajanju teh korakov, pri izvajanju uvajanja, ne želimo naleteti na izpade. Vsaka avtomatizacija v Kubernetesu se torej začne z API-jem.
Kubernetes ni orodje, ki bi ga bilo mogoče produktivno uporabljati takoj. Seveda lahko to storite, uporabite kubectl in tako naprej, vendar je API še vedno najbolj zanimiva in uporabna stvar na tej platformi. Z uporabo API-ja kot nabora funkcij lahko dostopate do skoraj vsega, kar želite početi v Kubernetesu. sam kubectl uporablja tudi REST API.
To je REST, tako da lahko za delo s tem API-jem uporabljate kateri koli jezik ali orodje, vendar vam bodo knjižnice po meri olajšale življenje. Moja ekipa je napisala 2 takšni knjižnici: eno za Java/OSGi in eno za Go. Drugi se ne uporablja pogosto, a v vsakem primeru imate te uporabne stvari na voljo. So delno licenčni odprtokodni projekt. Takih knjižnic je veliko za različne jezike, tako da lahko izberete tiste, ki vam najbolj ustrezajo.
Torej, preden začnete avtomatizirati uvajanje, se morate prepričati, da proces ne bo podvržen izpadom. Na primer, naša ekipa izvaja produkcijske uvedbe sredi dneva, ko ljudje največ uporabljajo aplikacije, zato je pomembno, da se izognete zamudam v tem procesu. Da bi se izognili izpadom, se uporabljata 2 načina: modra/zelena uvedba ali tekoča posodobitev. V slednjem primeru, če imate v teku 5 replik aplikacije, se te posodabljajo zaporedno ena za drugo. Ta metoda deluje odlično, vendar ni primerna, če se med postopkom uvajanja hkrati izvajajo različne različice aplikacije. V tem primeru lahko posodobite uporabniški vmesnik, medtem ko zaledje izvaja staro različico, in aplikacija bo prenehala delovati. Zato je s programskega vidika delo v takih razmerah precej težko.
To je eden od razlogov, zakaj raje uporabljamo modro/zeleno uvajanje za avtomatizacijo uvajanja naših aplikacij. Pri tej metodi morate zagotoviti, da je naenkrat aktivna samo ena različica aplikacije.
Modro/zeleni mehanizem uvajanja izgleda takole. Promet za naše aplikacije prejemamo prek ha-proxyja, ki ga posreduje delujočim replikam aplikacije iste različice.
Ko se izvede nova uvedba, uporabimo Deployer, ki dobi nove komponente in uvede novo različico. Uvedba nove različice aplikacije pomeni, da se "dvigne" nov nabor replik, nakar se te replike nove različice zaženejo v ločenem, novem sklopu. Vendar ha-proxy ne ve ničesar o njih in jim še ne usmerja nobene delovne obremenitve.
Zato je najprej treba opraviti preverjanje delovanja novih različic preverjanja zdravja, da se zagotovi, da so replike pripravljene za servisiranje obremenitve.
Vse komponente uvajanja morajo podpirati določeno obliko preverjanja stanja. To je lahko zelo preprosto preverjanje klicev HTTP, ko prejmete kodo s statusom 200, ali pa bolj poglobljeno preverjanje, pri katerem preverite povezavo replik z bazo in drugimi storitvami, stabilnost povezav dinamičnega okolja. in ali se vse zažene in deluje pravilno. Ta proces je lahko precej zapleten.
Ko sistem preveri, ali vse posodobljene replike delujejo, bo Deployer posodobil konfiguracijo in posredoval pravilen confd, ki bo znova konfiguriral ha-proxy.
Šele po tem bo promet usmerjen na pod z replikami nove različice, stari pod pa bo izginil.
Ta mehanizem ni lastnost Kubernetesa. Koncept modro/zelene uvedbe obstaja že precej časa in vedno je uporabljal izravnalnik obremenitve. Najprej ves promet usmerite na staro različico aplikacije, po posodobitvi pa ga v celoti prenesete na novo različico. To načelo se ne uporablja samo v Kubernetesu.
Zdaj vam bom predstavil novo komponento za uvajanje - Deployer, ki izvaja preglede zdravja, ponovno konfigurira posrednike in tako naprej. To je koncept, ki ne velja za zunanji svet in obstaja znotraj Kubernetesa. Pokazal vam bom, kako lahko z odprtokodnimi orodji ustvarite svoj koncept Deployerja.
Torej, prva stvar, ki jo naredi Deployer, je ustvariti krmilnik replikacije RC z API-jem Kubernetes. Ta API ustvarja pode in storitve za nadaljnjo uvedbo, to pomeni, da ustvari popolnoma novo gručo za naše aplikacije. Takoj, ko se RC prepriča, da so se replike začele, bo opravil zdravstveni pregled njihove funkcionalnosti. Za to Deployer uporabi ukaz GET /health. Zažene ustrezne komponente skeniranja in preveri vse elemente, ki podpirajo delovanje gruče.
Ko vsi sklopi poročajo o svojem zdravju, Deployer ustvari nov konfiguracijski element - porazdeljeno shranjevanje etcd, ki ga interno uporablja Kubernetes, vključno s shranjevanjem konfiguracije izravnalnika obremenitve. Podatke pišemo v etcd in majhno orodje, imenovano confd, spremlja etcd za nove podatke.
Če zazna kakršne koli spremembe začetne konfiguracije, ustvari novo datoteko z nastavitvami in jo prenese v ha-proxy. V tem primeru se ha-proxy znova zažene brez izgube povezav in naslovi obremenitev na nove storitve, ki omogočajo delovanje nove različice naših aplikacij.
Kot lahko vidite, kljub obilici komponent tukaj ni nič zapletenega. Samo več pozornosti morate nameniti API-ju in itd. Želim vam povedati o odprtokodnem programu za uvajanje, ki ga uporabljamo sami – Amdatu Kubernetes Deployer.
Je orodje za orkestriranje uvajanj Kubernetes in ima naslednje funkcije:
- Modra/zelena uvedba;
- nastavitev zunanjega izravnalnika obremenitve;
- upravljanje deskriptorjev razmestitve;
- upravljanje dejanske namestitve;
- preverjanje delovanja pregledov zdravja med uvajanjem;
- implementacija spremenljivk okolja v pods.
Ta program za uvajanje je zgrajen na API-ju Kubernetes in ponuja API REST za upravljanje ročajev in uvajanj ter API Websocket za pretakanje dnevnikov med postopkom uvajanja.
Podatke o konfiguraciji izravnalnika obremenitve postavi v etcd, tako da vam ni treba uporabljati ha-proxy s podporo, ki je že pripravljena, ampak preprosto uporabite svojo konfiguracijsko datoteko izravnalnika obremenitve. Amdatu Deployer je napisan v Go, kot sam Kubernetes, in ima licenco Apache.
Preden sem začel uporabljati to različico razmestitvenega programa, sem uporabil naslednji deskriptor razmestitve, ki določa parametre, ki jih potrebujem.
Eden od pomembnih parametrov te kode je omogočiti zastavico »useHealthCheck«. Določiti moramo, da je treba med postopkom uvajanja opraviti preverjanje razumnosti. To nastavitev je mogoče onemogočiti, če uvedba uporablja vsebnike tretjih oseb, ki jih ni treba preverjati. Ta deskriptor označuje tudi število replik in naslovni URL, ki ga potrebuje ha-proxy. Na koncu je specifikacijska zastavica sklopa "podspec", ki kliče Kubernetes za informacije o konfiguraciji vrat, sliki itd. To je dokaj preprost deskriptor JSON.
Drugo orodje, ki je del odprtokodnega projekta Amdatu, je Deploymentctl. Ima uporabniški vmesnik za konfiguriranje uvajanj, shranjuje zgodovino uvajanja in vsebuje spletne kljuke za povratne klice uporabnikov in razvijalcev tretjih oseb. Uporabniškega vmesnika ne smete uporabljati, ker je Amdatu Deployer sam API REST, vendar vam lahko ta vmesnik olajša uvajanje brez vključevanja API-ja. Deploymentctl je napisan v OSGi/Vertx z uporabo Angular 2.
Zdaj bom z vnaprej posnetim posnetkom prikazal zgoraj navedeno na zaslonu, tako da vam ne bo treba čakati. Uvedli bomo preprosto aplikacijo Go. Ne skrbite, če Go še niste preizkusili, to je zelo preprosta aplikacija, tako da bi jo morali razumeti.
Tukaj ustvarjamo strežnik HTTP, ki se odziva samo na /health, tako da ta aplikacija testira samo pregled stanja in nič drugega. Če je preverjanje uspešno, se uporabi spodaj prikazana struktura JSON. Vsebuje različico aplikacije, ki jo bo namestil uvajalec, sporočilo, ki ga vidite na vrhu datoteke, in logični tip podatkov – ali naša aplikacija deluje ali ne.
Z zadnjo vrstico sem malo goljufal, ker sem na vrh datoteke postavil fiksno logično vrednost, ki mi bo v prihodnje pomagala pri uvajanju tudi “nezdrave” aplikacije. S tem se bomo ukvarjali kasneje.
Pa začnimo. Najprej z ukazom ~ kubectl get pods preverimo prisotnost morebitnih delujočih podov in se na podlagi odsotnosti odgovora s naslovnega URL-ja prepričamo, da se trenutno ne izvaja nobena uvedba.
Nato na zaslonu vidite vmesnik Deploymentctl, ki sem ga omenil, v katerem so nastavljeni parametri uvajanja: imenski prostor, ime aplikacije, različica uvajanja, število replik, sprednji URL, ime vsebnika, slika, omejitve virov, številka vrat za preverjanje stanja, itd. Omejitve virov so zelo pomembne, saj vam omogočajo uporabo največje možne količine strojne opreme. Tukaj si lahko ogledate tudi dnevnik uvajanja.
Če zdaj ponovite ukaz ~ kubectl get pods, lahko vidite, da sistem »zamrzne« za 20 sekund, med katerimi se ha-proxy ponovno konfigurira. Po tem se pod zažene in našo repliko je mogoče videti v dnevniku uvajanja.
Iz videoposnetka sem izrezal 20 sekund čakanja in zdaj lahko na zaslonu vidite, da je prva različica aplikacije nameščena. Vse to je bilo narejeno samo z uporabniškim vmesnikom.
Zdaj pa poskusimo drugo različico. Da bi to naredil, spremenim sporočilo aplikacije iz "Pozdravljeni, Kubernetes!" na “Hello, Deployer!”, sistem ustvari to sliko in jo postavi v register Docker, nakar preprosto ponovno kliknemo na gumb “Deploy” v oknu Deploymentctl. V tem primeru se dnevnik uvajanja samodejno zažene na enak način, kot se je to zgodilo pri uvajanju prve različice aplikacije.
Ukaz ~ kubectl get pods kaže, da se trenutno izvajata 2 različici aplikacije, vendar sprednji del kaže, da še vedno izvajamo različico 1.
Uravnoteževalec obremenitve počaka, da se preverjanje stanja konča, preden preusmeri promet na novo različico. Po 20 sekundah preklopimo na curl in vidimo, da imamo zdaj nameščeno različico 2 aplikacije, prva pa je bila izbrisana.
To je bila uvedba "zdrave" aplikacije. Poglejmo, kaj se zgodi, če za novo različico aplikacije spremenim zdrav parameter iz true v false, kar pomeni, da poskušam razmestiti nezdravo aplikacijo, ki ni opravila pregleda zdravja. To se lahko zgodi, če so bile v fazi razvoja v aplikaciji narejene nekatere konfiguracijske napake in je bila poslana v produkcijo v tej obliki.
Kot lahko vidite, gre pri uvajanju skozi vse zgornje korake in ~kubectl get pods pokaže, da oba sklopa delujeta. Toda za razliko od prejšnje uvedbe dnevnik prikazuje stanje časovne omejitve. To pomeni, da zaradi dejstva, da pregled zdravja ni uspel, nove različice aplikacije ni mogoče namestiti. Posledično vidite, da se je sistem vrnil k uporabi stare različice aplikacije, nova različica pa je bila preprosto odstranjena.
Dobra stvar pri tem je, da tudi če imate ogromno število hkratnih zahtev, ki prihajajo v aplikacijo, ne bodo niti opazile izpadov med izvajanjem postopka uvajanja. Če to aplikacijo preizkusite z uporabo ogrodja Gatling, ki ji pošlje čim več zahtev, potem nobena od teh zahtev ne bo opuščena. To pomeni, da naši uporabniki ne bodo niti opazili posodobitev različice v realnem času. Če ne uspe, se bo delo nadaljevalo na stari različici, če bo uspešno, bodo uporabniki prešli na novo različico.
Obstaja samo ena stvar, ki lahko odpove - če je pregled zdravja uspešen, vendar aplikacija odpove takoj, ko je nanjo uporabljena delovna obremenitev, to pomeni, da bo do kolapsa prišlo šele po zaključku uvajanja. V tem primeru se boste morali ročno vrniti na staro različico. Tako smo pogledali, kako uporabljati Kubernetes z odprtokodnimi orodji, ki so zasnovana zanj. Postopek uvajanja bo veliko lažji, če ta orodja vgradite v svoje cevovode Build/Deploy. Hkrati lahko za začetek uvajanja uporabite bodisi uporabniški vmesnik ali popolnoma avtomatizirate ta postopek z uporabo na primer commit to master.
Naš gradbeni strežnik bo ustvaril sliko Docker in jo potisnil v Docker Hub ali kateri koli register, ki ga uporabljate. Docker Hub podpira webhook, tako da lahko sprožimo oddaljeno uvajanje prek Deployerja na način, prikazan zgoraj. Na ta način lahko popolnoma avtomatizirate uvajanje vaše aplikacije v potencialno proizvodnjo.
Preidimo na naslednjo temo – skaliranje gruče Kubernetes. Upoštevajte, da je ukaz kubectl ukaz za skaliranje. Z dodatno pomočjo lahko preprosto povečamo število replik v naši obstoječi gruči. Vendar v praksi običajno želimo povečati število vozlišč in ne podov.
Hkrati boste morda morali med delovnim časom povečati in ponoči, da zmanjšate stroške storitev Amazon, morda zmanjšati število delujočih primerkov aplikacij. To ne pomeni, da bo dovolj skaliranje samo števila podov, kajti tudi če je eno od vozlišč nedejavno, boste morali zanj še vedno plačati Amazonu. To pomeni, da boste morali skupaj s spreminjanjem velikosti sklopov spreminjati število uporabljenih strojev.
To je lahko izziv, saj ne glede na to, ali uporabljamo Amazon ali drugo storitev v oblaku, Kubernetes ne ve ničesar o številu strojev, ki se uporabljajo. Manjka mu orodje, ki bi vam omogočalo skaliranje sistema na ravni vozlišča.
Tako bomo morali poskrbeti tako za vozlišča kot za stroke. Zagon novih vozlišč lahko preprosto povečamo z uporabo API-ja AWS in skupinskih strojev za skaliranje, da konfiguriramo število delovnih vozlišč Kubernetes. Za registracijo vozlišč v gruči Kubernetes lahko uporabite tudi cloud-init ali podoben skript.
Nov stroj se zažene v skupini za skaliranje, se iniciira kot vozlišče, se registrira v glavnem registru in začne delovati. Po tem lahko povečate število replik za uporabo na nastalih vozliščih. Zmanjšanje obsega zahteva več truda, saj morate zagotoviti, da takšen korak ne povzroči uničenja že delujočih aplikacij po izklopu "nepotrebnih" strojev. Če želite preprečiti takšen scenarij, morate vozlišča nastaviti v status »nerazporejeno«. To pomeni, da bo privzeti razporejevalnik prezrl ta vozlišča pri razporejanju podov DaemonSet. Razporejevalnik ne bo izbrisal ničesar s teh strežnikov, vendar tam tudi ne bo zagnal novih vsebnikov. Naslednji korak je izrivanje odtočnega vozlišča, to je prenos tekočih podov iz njega na drug stroj ali druga vozlišča, ki imajo za to dovolj zmogljivosti. Ko zagotovite, da na teh vozliščih ni več vsebnikov, jih lahko odstranite iz Kubernetesa. Po tem bodo za Kubernetes preprosto prenehali obstajati. Nato morate uporabiti API AWS, da onemogočite nepotrebna vozlišča ali stroje.
Uporabite lahko Amdatu Scalerd, drugo odprtokodno orodje za skaliranje, podobno API-ju AWS. Zagotavlja CLI za dodajanje ali odstranjevanje vozlišč v gruči. Njegova zanimiva funkcija je zmožnost konfiguriranja razporejevalnika z naslednjo datoteko json.
Prikazana koda zmanjša kapaciteto gruče za polovico v nočnem obdobju. Konfigurira število razpoložljivih replik in želeno zmogljivost gruče Amazon. Uporaba tega razporejevalnika bo samodejno zmanjšala število vozlišč ponoči in jih povečala zjutraj, s čimer boste prihranili stroške uporabe vozlišč iz storitve v oblaku, kot je Amazon. Ta funkcija ni vgrajena v Kubernetes, vendar vam bo uporaba Scalerd omogočila, da to platformo prilagodite, kot želite.
Rad bi poudaril, da mi veliko ljudi reče: "To je vse lepo in prav, kaj pa moja baza podatkov, ki je običajno statična?" Kako lahko poženeš kaj takega v dinamičnem okolju, kot je Kubernetes? Po mojem mnenju tega ne bi smeli početi, ne bi smeli poskušati zagnati podatkovnega skladišča v Kubernetesu. To je tehnično izvedljivo in na internetu obstajajo vaje na to temo, vendar vam bo resno zakompliciralo življenje.
Da, v Kubernetesu obstaja koncept trajnih shramb in lahko poskusite zagnati shrambo podatkov, kot sta Mongo ali MySQL, vendar je to precej delovno intenzivna naloga. To je posledica dejstva, da podatkovna skladišča ne podpirajo v celoti interakcije z dinamičnim okoljem. Večina baz podatkov zahteva veliko konfiguracijo, vključno z ročno konfiguracijo gruče, ne marajo samodejnega skaliranja in drugih podobnih stvari.
Zato si ne smete komplicirati življenja s poskusi zagona podatkovnega skladišča v Kubernetesu. Organizirajte njihovo delo na tradicionalen način z uporabo znanih storitev in Kubernetesu preprosto zagotovite možnost njihove uporabe.
Za zaključek teme bi vam rad predstavil platformo Cloud RTI, ki temelji na Kubernetesu, na kateri dela moja ekipa. Zagotavlja centralizirano beleženje, spremljanje aplikacij in gruč ter številne druge uporabne funkcije, ki vam bodo prišle prav. Za prikaz spremljanja uporablja različna odprtokodna orodja, kot je Grafana.
Pojavilo se je vprašanje, zakaj uporabljati izravnalnik obremenitve ha-proxy s Kubernetesom. Dobro vprašanje, ker trenutno obstajata 2 ravni uravnoteženja obremenitve. Storitve Kubernetes še vedno prebivajo na navideznih naslovih IP. Ne morete jih uporabiti za vrata na zunanjih gostiteljskih napravah, ker če Amazon preobremeni svojega gostitelja v oblaku, se bo naslov spremenil. Zato postavljamo ha-proxy pred storitve – da ustvarimo bolj statično strukturo za nemoteno komunikacijo prometa s Kubernetesom.
Drugo dobro vprašanje je, kako lahko poskrbite za spremembe sheme baze podatkov, ko izvajate modro/zeleno uvajanje? Dejstvo je, da je ne glede na uporabo Kubernetesa spreminjanje sheme podatkovne baze težka naloga. Zagotoviti morate, da sta stara in nova shema združljivi, nato pa lahko posodobite bazo podatkov in nato posodobite same aplikacije. Bazo podatkov lahko zamenjate med vročim delovanjem in nato posodobite aplikacije. Poznam ljudi, ki so zagnali popolnoma novo gručo baze podatkov z novo shemo, to je možnost, če imate bazo podatkov brez sheme, kot je Mongo, vendar vseeno ni lahka naloga. Če nimate več vprašanj, se vam zahvaljujemo za pozornost!
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com