Napomena prevoda: Ovaj pregledni materijal iz Weaveworks uvodi u najpopularnije strategije implementacije aplikacija i objašnjava mogućnost realizacije najnaprednijih od njih uz pomoć Kubernetes operatora Flagger. Napisan je jednostavnim jezikom i sadrži ilustrativne dijagrame, što omogućava razumevanje i početnicima inženjerima.
Dijagram preuzet iz strategija implementacije, koji je napravljen u Container Solutions
Jedan od najvećih problema u razvoju cloud native aplikacija danas je ubrzanje izbacivanja. Uz mikroservisni pristup, programeri već rade s potpuno modularnim aplikacijama i projektuju ih, omogućavajući različitim timovima da istovremeno pišu kod i vrše izmene u aplikaciji.
Kraće i češće implementacije imaju sledeće prednosti:
- Smanjuje se vreme do izlaska na tržište.
- Nove funkcije brže dolaze do korisnika.
- Povratne informacije korisnika brže stižu do tima programera. To znači da tim može brže dodavati funkcionalnosti i ispravljati probleme.
- Povećava se moral programera: s većim brojem funkcija u razvoju, rad je zanimljiviji.
Ali povećanje učestalosti objavljivanja takođe povećava šanse za negativan uticaj na pouzdanost aplikacije ili korisničko iskustvo. Stoga je timovima za rad i DevOps važno da izgrade procese i upravljaju strategijama implementacije na način da minimiziraju rizik za proizvod i korisnike. (Saznajte više o automatizaciji CI/CD procesa možete .)
U ovoj publikaciji raspravljaćemo o različitim strategijama implementacije u Kubernetes-u, uključujući rolling implementacije i naprednije metode kao što su kanarinske (canary) implementacije i njihove varijante.
Strategije implementacije
Postoji nekoliko različitih tipova strategija implementacije koje se mogu koristiti u zavisnosti od cilja. Na primer, možda ćete želeti da izvršite izmene u određenoj okolini za dalja testiranja, ili u podskupini korisnika/klijenata, ili će biti potrebno izvršiti ograničeno testiranje na korisnicima pre nego što neka funkcionalnost postane javna.
Rolling (postepena, 'nakladna' implementacija)
To je standardna strategija implementacije u Kubernetesu. Ona postepeno, jedan za drugim, zamjenjuje podove sa starom verzijom aplikacije podovima sa novom verzijom — bez zastoja klastera.
Kubernetes čeka da novi podovi postanu spremni za rad (provjeravajući ih uz pomoć ), prije nego što započne gašenje starih. Ako se pojavi problem, tako se primjenjivanje može prekinuti, a da se ne zaustavi cijeli klaster. U YAML datoteci koja opisuje tip implementacije, nova slika zamjenjuje staru sliku:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Parametre primjene možete pojasniti u manifest datoteci:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (ponovno kreiranje)
U ovom najjednostavnijem tipu implementacije, stari podovi se sve odjednom završavaju i zamjenjuju novima:
Odgovarajući manifest izgleda otprilike ovako:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (plavo-zelene implementacije)
Strategija plavo-zelenog implementiranja (ponekad se još naziva red/black, tj. crveno/crno) predviđa simultano implementiranje stare (zelene) i nove (plave) verzije aplikacije. Nakon postavljanja obje verzije, obični korisnici imaju pristup zelenoj, dok je plava dostupna QA timu za automatizaciju testiranja putem posebne usluge ili direktnog propuštanja portova:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Nakon što je plava (nova) verzija bila testirana i njen izdanje je odobreno, usluga se prebacuje na nju, a zelena (stara) se gasi:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanarinske implementacije)
Kanarinske implementacije su slične plavo-zelenim, ali se bolje upravljaju i koriste postepeni pristup. Ovom tipu pripada nekoliko različitih strategija, uključujući „skrivene“ lansiranja i A/B testiranje.
Ova strategija se primenjuje kada je potrebno isprobati neku novu funkcionalnost, obično u pozadini aplikacije. Suština pristupa je da se kreiraju dva praktično identična servera: jedan servisira gotovo sve korisnike, dok drugi, sa novim funkcijama, servisira samo malu podgrupu korisnika, nakon čega se rezultati njihovog rada upoređuju. Ako sve prođe bez grešaka, nova verzija se postepeno uvodi u celu infrastrukturu.
Iako se ova strategija može realizovati isključivo putem Kubernetesa, zamenjujući stare pod-ove novima, mnogo je lakše i praktičnije koristiti service mesh poput Istio.
Na primer, možete imati dva različita manifesta u Gitu: običan sa oznakom 0.1.0 i "kanarinac" sa oznakom 0.2.0. Menjajući težine u manifestu virtuelnog gateway-a Istio, možete upravljati raspodelom saobraćaja između ova dva deployment-a:
Korak po korak vodič za implementaciju kanarinskih deploy-ovanja uz Istio možete pronaći u materijalu . (Napomena za prijevod.: Takođe smo preveli materijal o kanarinskim postavkama u Istio .)
Kanarinske postavke sa Weaveworks Flagger
omogućava lako i efikasno upravljanje kanarinskim postavkama.
Flagger automatizuje rad s njima. Koristi Istio ili AWS App Mesh za usmeravanje i prebacivanje saobraćaja, kao i metrike Prometheus za analizu rezultata. Pored toga, analiza kanarinskih postavki može se dopuniti webhook-ovima za izvođenje prihvatnih (acceptance) testova, testova opterećenja i drugih vrsta provera.
Na osnovu Kubernetes deployment-a i, ako je potrebno, horizontalnog skaliranja pod-ova (HPA), Flagger kreira skupove objekata (Kubernetes deploy-amenti, ClusterIP servisi i virtuelni servisi Istio ili App Mesh) za analizu i implementaciju kanarinskih postavki:
Implementirajući kontrolni sistem (control loop), Flagger postepeno prebacuje saobraćaj na kanarinski server, istovremeno mereći ključne pokazatelje performansi, kao što su udeo uspešnih HTTP zahteva, prosečno vreme zahteva i zdravlje pod-ova. Na osnovu analize KPI (ključnih pokazatelja uspešnosti), kanarinski deo ili raste ili se smanjuje, a rezultati analize se objavljuju u Slack-u. Opis i prikaz ovog procesa možete pronaći u materijalu .
Tamno (skriveno) ili A/B raspoređivanje
Skriveno raspoređivanje je još jedna varijacija kanarinog pristupa (uz koji, usput, Flagger također može raditi). Razlika između skrivenog i kanarinog raspoređivanja je u tome što se skrivena raspoređivanja bave frontend-om, a ne backend-om, kao kod kanarinog.
Drugo ime za ova raspoređivanja je A/B testiranje. Umesto da svim korisnicima otkriju novu funkciju, ona se nudi samo ograničenoj grupi. Obično ti korisnici ne znaju da su testeri pioniri (odakle i naziv "skriveno raspoređivanje").
Uz pomoć prekidača funkcionalnosti (feature toggles) i drugih alata može se pratiti kako korisnici interaguju s novom funkcijom, da li ih privlači ili smatraju da je novi korisnički interfejs zbunjujući, i drugim tipovima metrika.
Flagger i A/B raspoređivanja
Pored usmjeravanja na osnovu težine, Flagger također može usmjeriti promet na kanarinski server zavisno od HTTP parametara. Kod A/B testiranja, mogu se koristiti HTTP zaglavlja ili kolačići za preusmjeravanje specifičnog segmenta korisnika. Ovo je posebno efikasno u slučajevima frontend aplikacija koje zahtevaju vezanost sesije za server (session affinity). Dodatne informacije možete pronaći u dokumentaciji Flagger.
Autor se zahvaljuje , inženjeru iz Weaveworks (i kreatoru Flaggers), za sve ove fantastične sheme raspoređivanja.
P.S. od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
