Kubernetes je izvrstan alat za pokretanje Docker spremnika u klasteriranom proizvodnom okruženju. Međutim, postoje problemi koje Kubernetes ne može riješiti. Za česte produkcijske implementacije potrebna nam je potpuno automatizirana Plavo/zelena implementacija kako bismo izbjegli zastoje u procesu, koji također treba obraditi vanjske HTTP zahtjeve i izvršiti SSL prijenose. Ovo zahtijeva integraciju s balanserom opterećenja kao što je ha-proxy. Drugi izazov je poluautomatsko skaliranje samog klastera Kubernetes kada radi u okruženju oblaka, na primjer djelomično skaliranje klastera noću.
Iako Kubernetes nema ove značajke odmah po završetku, on pruža API koji možete koristiti za rješavanje sličnih problema. Alati za automatiziranu Blue/Green implementaciju i skaliranje Kubernetes klastera razvijeni su u sklopu Cloud RTI projekta koji je nastao na temelju open-source-a.
Ovaj video transkript govori o tome kako postaviti Kubernetes zajedno s drugim komponentama otvorenog koda za stvaranje okruženja spremnog za proizvodnju koje prihvaća kod iz git commita bez zastoja u proizvodnji.
Dakle, nakon što imate pristup svojim aplikacijama iz vanjskog svijeta, možete početi u potpunosti postavljati automatizaciju, odnosno dovesti je do faze u kojoj možete izvršiti git commit i osigurati da taj git commit završi u proizvodnji. Naravno, prilikom implementacije ovih koraka, prilikom implementacije implementacije, ne želimo naići na zastoje. Dakle, svaka automatizacija u Kubernetesu počinje s API-jem.
Kubernetes nije alat koji se može produktivno koristiti izvan okvira. Naravno, možete to raditi, koristiti kubectl i tako dalje, ali ipak je API najzanimljivija i najkorisnija stvar na ovoj platformi. Koristeći API kao skup funkcija, možete pristupiti gotovo svemu što želite raditi u Kubernetesu. sam kubectl također koristi REST API.
Ovo je REST, tako da možete koristiti bilo koji jezik ili alat za rad s ovim API-jem, ali će vam život biti puno lakši prilagođenim bibliotekama. Moj tim je napisao 2 takve biblioteke: jednu za Java/OSGi i jednu za Go. Drugi se ne koristi često, ali u svakom slučaju imate ove korisne stvarčice na raspolaganju. Oni su djelomično licencirani projekt otvorenog koda. Postoji mnogo takvih biblioteka za različite jezike, tako da možete odabrati one koje vam najviše odgovaraju.
Dakle, prije nego počnete automatizirati svoju implementaciju, morate biti sigurni da proces neće biti podložan zastoju. Na primjer, naš tim provodi proizvodne implementacije tijekom sredine dana kada ljudi najviše koriste aplikacije, stoga je važno izbjeći kašnjenja u ovom procesu. Kako bi se izbjegao zastoj, koriste se 2 metode: plava/zelena implementacija ili tekuće ažuriranje. U potonjem slučaju, ako imate 5 pokrenutih replika aplikacije, one se ažuriraju jedna za drugom. Ova metoda radi odlično, ali nije prikladna ako imate različite verzije aplikacije koje se izvode istovremeno tijekom procesa postavljanja. U tom slučaju možete ažurirati korisničko sučelje dok pozadina izvodi staru verziju, a aplikacija će prestati raditi. Stoga je s programerskog stajališta rad u takvim uvjetima prilično težak.
Ovo je jedan od razloga zašto radije koristimo plavo/zelenu implementaciju za automatizaciju implementacije naših aplikacija. Ovom metodom morate osigurati da je samo jedna verzija aplikacije istovremeno aktivna.
Plavo/zeleni mehanizam za implementaciju izgleda ovako. Promet za naše aplikacije primamo putem ha-proxyja koji ga prosljeđuje pokrenutim replikama aplikacije iste verzije.
Kada se napravi nova implementacija, koristimo Deployer, koji dobiva nove komponente i implementira novu verziju. Uvođenje nove verzije aplikacije znači da se "podiže" novi skup replika, nakon čega se te replike nove verzije pokreću u zasebnom, novom modulu. Međutim, ha-proxy ne zna ništa o njima i još im ne usmjerava nikakvo radno opterećenje.
Stoga je prije svega potrebno izvršiti provjeru performansi novih verzija provjere zdravlja kako bi se osiguralo da su replike spremne za servisiranje opterećenja.
Sve komponente implementacije moraju podržavati neki oblik provjere ispravnosti. To može biti vrlo jednostavna provjera HTTP poziva, kada dobijete kod sa statusom 200, ili dublja provjera, u kojoj provjeravate povezanost replika s bazom podataka i drugim servisima, stabilnost veza dinamičkog okruženja , te da li se sve pokreće i radi ispravno. Ovaj proces može biti prilično složen.
Nakon što sustav potvrdi da sve ažurirane replike rade, Deployer će ažurirati konfiguraciju i proslijediti ispravan confd, koji će ponovno konfigurirati ha-proxy.
Tek nakon toga promet će se usmjeriti na pod s replikama nove verzije, a stari pod će nestati.
Ovaj mehanizam nije značajka Kubernetesa. Koncept plavo/zelene implementacije postoji već dosta dugo i uvijek je koristio balanser opterećenja. Prvo sav promet usmjeravate na staru verziju aplikacije, a nakon ažuriranja ga u potpunosti prenosite na novu verziju. Ovaj princip se koristi ne samo u Kubernetesu.
Sada ću vas upoznati s novom komponentom za implementaciju - Deployer, koja obavlja provjere zdravlja, rekonfigurira proxyje i tako dalje. Ovo je koncept koji se ne odnosi na vanjski svijet i postoji unutar Kubernetesa. Pokazat ću vam kako možete izraditi vlastiti koncept Deployera pomoću alata otvorenog koda.
Dakle, prva stvar koju Deployer radi je stvaranje RC replikacijskog kontrolera pomoću Kubernetes API-ja. Ovaj API stvara podove i usluge za daljnju implementaciju, odnosno stvara potpuno novi klaster za naše aplikacije. Čim se RC uvjeri da su replike pokrenute, izvršit će provjeru zdravlja njihove funkcionalnosti. Da bi to učinio, Deployer koristi naredbu GET /health. Pokreće odgovarajuće komponente skeniranja i provjerava sve elemente koji podržavaju rad klastera.
Nakon što su svi moduli prijavili svoje zdravlje, Deployer stvara novi konfiguracijski element - etcd distribuiranu pohranu, koju interno koristi Kubernetes, uključujući pohranu konfiguracije balansera opterećenja. Zapisujemo podatke u etcd, a mali alat koji se zove confd prati etcd za novim podacima.
Ako otkrije bilo kakve promjene početne konfiguracije, generira novu datoteku postavki i prenosi je na ha-proxy. U tom se slučaju ha-proxy ponovno pokreće bez gubljenja veza i adresira opterećenje na nove usluge koje omogućuju rad nove verzije naših aplikacija.
Kao što vidite, unatoč obilju komponenti, ovdje nema ništa komplicirano. Samo trebate obratiti više pažnje na API i itd. Želim vam reći o open-source deployeru koji i mi sami koristimo - Amdatu Kubernetes Deployer.
To je alat za orkestriranje Kubernetes implementacija i ima sljedeće značajke:
- Plavo/zelena implementacija;
- postavljanje vanjskog balansera opterećenja;
- upravljanje deskriptorima postavljanja;
- upravljanje stvarnim raspoređivanjem;
- provjera funkcionalnosti provjera zdravlja tijekom implementacije;
- implementacija varijabli okruženja u mahune.
Ovaj Deployer izgrađen je na temelju Kubernetes API-ja i pruža REST API za upravljanje rukovanjima i implementacijama, kao i Websocket API za strujanje zapisa tijekom procesa implementacije.
Stavlja podatke o konfiguraciji balansera opterećenja u etcd, tako da ne morate koristiti ha-proxy s podrškom izvan kutije, već jednostavno koristite svoju konfiguracijsku datoteku balansera opterećenja. Amdatu Deployer je napisan u Go-u, kao i sam Kubernetes, i licenciran je od strane Apache-a.
Prije nego što sam počeo koristiti ovu verziju programa za implementaciju, koristio sam sljedeći deskriptor implementacije, koji navodi parametre koji su mi potrebni.
Jedan od važnih parametara ovog koda je omogućiti zastavu "useHealthCheck". Moramo navesti da se provjera ispravnosti mora izvršiti tijekom procesa implementacije. Ova se postavka može onemogućiti kada implementacija koristi spremnike trećih strana koje ne treba verificirati. Ovaj deskriptor također označava broj replika i URL sučelja koje ha-proxy treba. Na kraju je zastavica specifikacije modula "podspec", koja poziva Kubernetes za informacije o konfiguraciji priključka, slici itd. Ovo je prilično jednostavan JSON deskriptor.
Drugi alat koji je dio Amdatu projekta otvorenog koda je Deploymentctl. Ima korisničko sučelje za konfiguriranje postavljanja, pohranjuje povijest postavljanja i sadrži web-dojavnike za povratne pozive korisnika i programera trećih strana. Ne možete koristiti korisničko sučelje budući da je sam Amdatu Deployer REST API, ali ovo vam sučelje može olakšati implementaciju bez uključivanja bilo kakvog API-ja. Deploymentctl je napisan u OSGi/Vertxu koristeći Angular 2.
Sada ću demonstrirati gore navedeno na zaslonu koristeći unaprijed snimljenu snimku tako da ne morate čekati. Postavit ćemo jednostavnu Go aplikaciju. Ne brinite ako prije niste isprobali Go, to je vrlo jednostavna aplikacija pa biste je trebali moći shvatiti.
Ovdje stvaramo HTTP poslužitelj koji odgovara samo na /health, tako da ova aplikacija testira samo provjeru zdravlja i ništa drugo. Ako provjera prođe, koristi se JSON struktura prikazana u nastavku. Sadrži verziju aplikacije koju će implementirati implementator, poruku koju vidite na vrhu datoteke i Booleovu vrstu podataka - radi li naša aplikacija ili ne.
Malo sam varao sa zadnjim retkom, jer sam stavio fiksnu boolean vrijednost na vrh datoteke, što će mi u budućnosti pomoći da implementiram čak i "nezdravu" aplikaciju. Pozabavit ćemo se ovime kasnije.
Pa krenimo. Prvo provjeravamo prisutnost pokretanih podova pomoću naredbe ~ kubectl get pods i, na temelju odsutnosti odgovora s naslovnog URL-a, uvjeravamo se da se trenutačno ne provode nikakve implementacije.
Zatim na ekranu vidite sučelje Deploymentctl koje sam spomenuo, u kojem su postavljeni parametri implementacije: prostor imena, naziv aplikacije, verzija implementacije, broj replika, front-end URL, naziv spremnika, slika, ograničenja resursa, broj porta za provjeru ispravnosti, itd. Ograničenja resursa vrlo su važna jer vam omogućuju korištenje najveće moguće količine hardvera. Ovdje također možete pogledati dnevnik implementacije.
Ako sada ponovite naredbu ~ kubectl get pods, možete vidjeti da se sustav "zamrzava" na 20 sekundi, tijekom kojih se ha-proxy rekonfigurira. Nakon toga, kapsula se pokreće, a naša replika se može vidjeti u dnevniku postavljanja.
Iz videa sam izrezao 20 sekundi čekanja i sada možete vidjeti na ekranu da je implementirana prva verzija aplikacije. Sve je to učinjeno samo pomoću korisničkog sučelja.
Sada isprobajmo drugu verziju. Da bih to učinio, mijenjam poruku aplikacije iz "Zdravo, Kubernetes!" na “Hello, Deployer!”, sustav kreira ovu sliku i smjesti je u Docker registar, nakon čega jednostavno ponovo kliknemo na tipku “Deploy” u prozoru Deploymentctl. U tom slučaju, dnevnik implementacije automatski se pokreće na isti način kao što se to dogodilo prilikom implementacije prve verzije aplikacije.
Naredba ~ kubectl get pods pokazuje da su trenutno pokrenute 2 verzije aplikacije, ali sučelje pokazuje da još uvijek izvodimo verziju 1.
Uravnoteživač opterećenja čeka da se provjera ispravnosti završi prije preusmjeravanja prometa na novu verziju. Nakon 20 sekundi prelazimo na curl i vidimo da sada imamo implementiranu verziju 2 aplikacije, a prva je izbrisana.
Ovo je bila implementacija "zdrave" aplikacije. Pogledajmo što će se dogoditi ako za novu verziju aplikacije promijenim parametar Healthy iz true u false, odnosno pokušam implementirati nezdravu aplikaciju koja nije prošla provjeru zdravlja. To se može dogoditi ako su u fazi razvoja aplikacije napravljene pogreške u konfiguraciji, pa je poslana u produkciju u ovom obliku.
Kao što možete vidjeti, implementacija prolazi kroz sve gore navedene korake i ~kubectl get pods pokazuje da oba modula rade. Ali za razliku od prethodne implementacije, zapisnik prikazuje status isteka vremena. Odnosno, zbog činjenice da provjera zdravlja nije uspjela, nova verzija aplikacije ne može se implementirati. Kao rezultat toga, vidite da se sustav vratio na korištenje stare verzije aplikacije, a nova verzija je jednostavno deinstalirana.
Dobra stvar u vezi ovoga je da čak i ako imate ogroman broj istovremenih zahtjeva koji dolaze u aplikaciju, oni neće niti primijetiti prekid rada tijekom implementacije postupka postavljanja. Ako testirate ovu aplikaciju pomoću okvira Gatling, koji joj šalje što više zahtjeva, tada nijedan od tih zahtjeva neće biti odbačen. To znači da naši korisnici neće ni primijetiti ažuriranja verzije u stvarnom vremenu. Ako ne uspije, rad će se nastaviti na staroj verziji, ako bude uspješan, korisnici će prijeći na novu verziju.
Postoji samo jedna stvar koja može zakazati - ako provjera zdravlja uspije, ali aplikacija zakaže čim se na nju primijeni radno opterećenje, odnosno do kolapsa će doći tek nakon završetka implementacije. U tom slučaju morat ćete se ručno vratiti na staru verziju. Dakle, pogledali smo kako koristiti Kubernetes s alatima otvorenog koda dizajniranim za to. Proces implementacije bit će puno lakši ako ove alate ugradite u svoje Build/Deploy cjevovode. U isto vrijeme, da biste započeli implementaciju, možete koristiti ili korisničko sučelje ili potpuno automatizirati ovaj proces koristeći, na primjer, commit to master.
Naš Build Server će stvoriti Docker sliku, gurnuti je u Docker Hub ili bilo koji registar koji koristite. Docker Hub podržava webhook, tako da možemo pokrenuti daljinsku implementaciju putem Deployera na gore prikazan način. Na taj način možete u potpunosti automatizirati implementaciju svoje aplikacije u potencijalnu proizvodnju.
Prijeđimo na sljedeću temu – skaliranje Kubernetes klastera. Imajte na umu da je naredba kubectl naredba za skaliranje. Uz dodatnu pomoć, možemo lako povećati broj replika u našem postojećem klasteru. Međutim, u praksi obično želimo povećati broj čvorova, a ne podova.
U isto vrijeme, tijekom radnog vremena možda ćete morati povećati, a noću, kako biste smanjili troškove Amazonovih usluga, možda ćete morati smanjiti broj pokrenutih instanci aplikacija. To ne znači da će skaliranje samo broja podova biti dovoljno, jer čak i ako je jedan od čvorova u stanju mirovanja, i dalje ćete morati platiti Amazonu za to. Odnosno, uz skaliranje kapsula, morat ćete skalirati i broj korištenih strojeva.
To može biti izazov jer bez obzira na to koristimo li Amazon ili neku drugu uslugu u oblaku, Kubernetes ne zna ništa o broju strojeva koji se koriste. Nedostaje mu alat koji vam omogućuje skaliranje sustava na razini čvora.
Stoga ćemo se morati pobrinuti i za čvorove i za mahune. Lako možemo skalirati pokretanje novih čvorova pomoću AWS API-ja i strojeva grupe Scaling za konfiguraciju broja Kubernetes radnih čvorova. Također možete koristiti cloud-init ili sličnu skriptu za registraciju čvorova u Kubernetes klasteru.
Novi stroj počinje u grupi Scaling, inicira se kao čvor, registrira se u glavnom registru i počinje raditi. Nakon toga možete povećati broj replika za korištenje na rezultirajućim čvorovima. Smanjivanje zahtjeva više truda, jer morate biti sigurni da takav korak ne dovodi do uništavanja već pokrenutih aplikacija nakon isključivanja "nepotrebnih" strojeva. Kako biste spriječili takav scenarij, trebate postaviti čvorove u status "neplanirano". To znači da će zadani planer zanemariti ove čvorove prilikom raspoređivanja DaemonSet mahuna. Raspoređivač neće ništa izbrisati s ovih poslužitelja, ali također tamo neće pokrenuti nove spremnike. Sljedeći korak je izbacivanje drenažnog čvora, odnosno prijenos pokretačkih podova s njega na drugi stroj ili druge čvorove koji za to imaju dovoljan kapacitet. Nakon što se uvjerite da na tim čvorovima više nema spremnika, možete ih ukloniti iz Kubernetesa. Nakon ovoga, oni će jednostavno prestati postojati za Kubernetes. Zatim trebate upotrijebiti AWS API za onemogućavanje nepotrebnih čvorova ili strojeva.
Možete koristiti Amdatu Scalerd, drugi alat za skaliranje otvorenog koda sličan AWS API-ju. Omogućuje CLI za dodavanje ili uklanjanje čvorova u klasteru. Njegova zanimljiva značajka je mogućnost konfiguriranja planera pomoću sljedeće json datoteke.
Prikazani kod smanjuje kapacitet klastera za pola tijekom noćnog razdoblja. Konfigurira i broj dostupnih replika i željeni kapacitet Amazon klastera. Korištenje ovog planera automatski će smanjiti broj čvorova noću i povećati ih ujutro, štedeći troškove korištenja čvorova iz usluge u oblaku kao što je Amazon. Ova značajka nije ugrađena u Kubernetes, ali korištenje Scalerda omogućit će vam skaliranje ove platforme kako god želite.
Želio bih istaknuti da mi mnogi ljudi govore: "Sve je to lijepo, ali što je s mojom bazom podataka, koja je obično statična?" Kako možete pokrenuti ovako nešto u dinamičnom okruženju kao što je Kubernetes? Po mom mišljenju, to ne biste trebali raditi, ne biste trebali pokušavati pokrenuti skladište podataka u Kubernetesu. To je tehnički moguće, a na internetu postoje i tutorijali na tu temu, ali će vam ozbiljno zakomplicirati život.
Da, u Kubernetesu postoji koncept trajnih pohrana i možete pokušati pokrenuti pohrane podataka kao što su Mongo ili MySQL, ali to je prilično radno intenzivan zadatak. To je zbog činjenice da skladišta podataka ne podržavaju u potpunosti interakciju s dinamičkim okruženjem. Većina baza podataka zahtijeva značajnu konfiguraciju, uključujući ručnu konfiguraciju klastera, ne voli automatsko skaliranje i druge slične stvari.
Stoga si ne biste trebali komplicirati život pokušavajući pokrenuti skladište podataka u Kubernetesu. Organizirajte njihov rad na tradicionalan način koristeći poznate usluge i jednostavno omogućite Kubernetesu da ih koristi.
Za kraj teme želim vam predstaviti Cloud RTI platformu temeljenu na Kubernetesu na kojoj moj tim radi. Omogućuje centralizirano bilježenje, praćenje aplikacija i klastera te mnoge druge korisne značajke koje će vam dobro doći. Za prikaz nadzora koristi razne alate otvorenog koda kao što je Grafana.
Bilo je pitanje zašto koristiti ha-proxy load balancer s Kubernetesom. Dobro pitanje jer trenutno postoje 2 razine uravnoteženja opterećenja. Kubernetes usluge i dalje se nalaze na virtualnim IP adresama. Ne možete ih koristiti za priključke na vanjskim host strojevima jer ako Amazon preoptereti svoj cloud host, adresa će se promijeniti. Zbog toga postavljamo ha-proxy ispred usluga - kako bismo stvorili statičniju strukturu za besprijekornu komunikaciju prometa s Kubernetesom.
Još jedno dobro pitanje je kako se možete pobrinuti za promjene sheme baze podataka kada radite plavo/zelenu implementaciju? Činjenica je da je, bez obzira na korištenje Kubernetesa, promjena sheme baze podataka težak zadatak. Morate osigurati da su stara i nova shema kompatibilne, nakon čega možete ažurirati bazu podataka i zatim ažurirati same aplikacije. Bazu podataka možete zamijeniti bez prekida i zatim ažurirati aplikacije. Znam za ljude koji su podigli potpuno novi klaster baze podataka s novom shemom, ovo je opcija ako imate bazu podataka bez sheme kao što je Mongo, ali to ionako nije lak zadatak. Ako nemate više pitanja, hvala vam na pažnji!
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com