Notu. traduko: Ĉi tiu promenado de Weaveworks prezentas la plej popularajn aplikaĵajn strategiojn kaj kiel vi povas efektivigi la plej altnivelajn per la funkciigisto de Flagger Kubernetes. Ĝi estas skribita en simpla lingvo kaj enhavas vidajn diagramojn, kiuj ebligas eĉ komencajn inĝenierojn kompreni la aferon.
Diagramo prenita de lanĉaj strategioj faritaj en Container Solutions
Unu el la plej grandaj defioj en evoluigado de nubaj denaskaj aplikoj hodiaŭ estas deplojrapideco. Kun mikroserva aliro, programistoj jam laboras kun kaj dizajnas plene modulajn aplikojn, permesante al malsamaj teamoj skribi kodon kaj fari ŝanĝojn al la aplikaĵo samtempe.
Pli mallongaj kaj pli oftaj deplojoj havas la sekvajn avantaĝojn:
- Reduktita tempo al merkatado.
- Novaj funkcioj atingas uzantojn pli rapide.
- Uzantaj komentoj atingas la evoluteamon pli rapide. Ĉi tio signifas, ke la teamo povas aldoni funkciojn kaj ripari problemojn pli rapide.
- La moralo de programistoj altiĝas: pli da funkcioj en evoluo estas pli amuza labori kun.
Sed kiam la ofteco de eldonoj pliiĝas, la ŝancoj negative influi la fidindecon aŭ uzantan sperton de la programo ankaŭ pliiĝas. Tial gravas por operacioj kaj DevOps-teamoj konstrui procezojn kaj administri deplojajn strategiojn en maniero kiel minimumigi riskon por la produkto kaj uzantoj. (Por lerni pli pri aŭtomatigo de la CI/CD-dukto, vidu .)
En ĉi tiu afiŝo, ni diskutos diversajn Kubernetes-deplojajn strategiojn, inkluzive de ruliĝantaj deplojoj kaj pli altnivelaj metodoj kiel kanariaj landoj kaj iliaj varioj.
Deplojstrategioj
Estas pluraj malsamaj specoj de deplojstrategioj kiuj povas esti uzataj depende de la celo. Ekzemple, vi eble bezonos fari ŝanĝojn al iu medio por plua testado, aŭ al subaro de uzantoj/klientoj, aŭ vi eble bezonos fari limigitajn testadojn ĉe uzantoj antaŭ ol fari funkcion. publiko.
Ruliĝanta (laŭgrada, ruliĝanta deplojo)
Ĉi tiu estas la norma deploja strategio por Kubernetes. Ĝi iom post iom, unu post la alia, anstataŭigas podojn kun la malnova versio de la aplikaĵo per podojn kun la nova versio - sen grapo-malfunkcio.
Kubernetes atendas ke novaj podoj estu pretaj por iri (kontrolante ilin per ) antaŭ ol komenci kunvolvigi la malnovajn. Se problemo okazas, tia ruliĝanta ĝisdatigo povas esti ĉesigita sen haltigi la tutan areton. En la deplojo tipo YAML-dosiero, la nova bildo anstataŭigas la malnovan bildon:
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: 8080La parametroj de la ruliĝanta ĝisdatigo povas esti specifitaj en la manifestdosiero:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Rekrei (rekrei)
En ĉi tiu plej simpla speco de deplojo, malnovaj balgoj estas tuj mortigitaj kaj anstataŭigitaj per novaj:
La responda manifesto aspektas kiel ĉi tio:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blua/Verda (bluverdaj deplojoj)
La blu-verda deplojo strategio (foje ankaŭ referita kiel ruĝa / nigra, t.e. ruĝ-nigra) implikas la samtempan deplojon de la malnova (verda) kaj nova (blua) versioj de la aplikaĵo. Post kiam ambaŭ versioj estas gastigitaj, la verda estas havebla al la ĝenerala uzanto, dum la blua estas disponebla por la QA-teamo por aŭtomatigi testojn per aparta servo aŭ rekta havena plusendado:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Post kiam la blua (nova) versio estis testita kaj aprobita por liberigo, la servo estas ŝanĝita al ĝi, kaj la verda (malnova) estas minimumigita:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanario (kanariaj deplojoj)
Kanariaj ruliĝoj similas al bluverdaj, sed pli bone kontrolitaj kaj uzataj paŝo post paŝo alproksimiĝo. Pluraj malsamaj strategioj falas en ĉi tiun kategorion, inkluzive de kaŝaj lanĉoj kaj A/B-testado.
Ĉi tiu strategio estas uzata kiam iu nova funkcieco devas esti provita, kutime en la backend de la aplikaĵo. La esenco de la aliro estas krei du preskaŭ identajn servilojn: unu servas preskaŭ ĉiujn uzantojn, kaj la alia, kun novaj funkcioj, servas nur malgrandan subgrupon de uzantoj, post kiuj la rezultoj de ilia laboro estas komparitaj. Se ĉio iras sen eraroj, la nova versio estas iom post iom disvastigita al la tuta infrastrukturo.
Kvankam ĉi tiu strategio povas esti efektivigita ekskluzive uzante Kubernetes, anstataŭigante malnovajn podojn per novaj, estas multe pli oportune kaj pli facile uzi servomaŝon kiel Istio.
Ekzemple, vi eble havas du malsamajn Git-manifestojn: regula kun etikedo 0.1.0 kaj kanaria kun etikedo 0.2.0. Ŝanĝante la pezojn en la manifesto de Istio Virtual Gateway, vi povas kontroli la distribuadon de trafiko inter ĉi tiuj du deplojoj:
Paŝo-post-paŝa gvidilo pri efektivigado de kanariaj deplojoj kun Istio troveblas en . (Notu. transl.: Ni ankaŭ tradukis materialon pri kanariaj ruliloj en Istio .)
Kanariaj deplojoj kun Weaveworks Flagger
permesas facilan kaj efikan kontrolon de kanariaj ruloj.
Flagger aŭtomatigas labori kun ili. Ĝi uzas Istio aŭ AWS App Mesh por direkti kaj ŝanĝi trafikon, kaj Prometheus-metrikon por analizi la rezultojn. Krome, la analizo de kanariaj deplojoj povas esti kompletigita per rethokoj por fari akceptajn testojn, ŝarĝtestojn kaj ajnajn aliajn specojn de kontroloj.
Surbaze de la disfaldiĝo de Kubernetes kaj, se necese, de skalopodoj (HPA), Flagger kreas arojn de objektoj (Kubernetes-deplojoj, ClusterIP-servoj kaj Istio aŭ App Mesh virtualaj servoj) por analizi kaj efektivigi kanariajn deplojojn:
Efektivigo de kontrolbuklo (kontrolbuklo)Flagger iom post iom ŝanĝas trafikon al la kanaria servilo dum mezurado de ŝlosilaj agado-metrikoj kiel ekzemple HTTP-peto-sukcesprocento, averaĝa petodaŭro kaj podsano. Surbaze de la analizo de KPIoj (Key Performance Indicators), la kanaria parto aŭ kreskas aŭ ŝrumpas, kaj la rezultoj de la analizo estas publikigitaj al Slack. Priskribo kaj pruvo de ĉi tiu procezo troveblas en la materialo .
Malhelaj (kaŝaj) aŭ A/V-deplojoj
Stealth-deplojo estas alia vario de la kanaria strategio (kun kiu, cetere, Flagger ankaŭ povas labori). La diferenco inter sekretaj kaj kanariaj deplojoj estas, ke sekretaj deplojoj traktas la antaŭan finaĵon kaj ne la malantaŭan finaĵon kiel kanariaj deplojoj faras.
Alia nomo por ĉi tiuj deplojoj estas A/B-testado. Anstataŭ malfermi aliron al nova funkcio al ĉiuj uzantoj, ĝi estas ofertita nur al limigita parto de ili. Tipe, ĉi tiuj uzantoj ne konscias, ke ili estas pioniraj testistoj (tial la esprimo "silenta deplojo").
Kun funkcioŝaltiloj (funkciaj ŝanĝas) kaj aliaj iloj, vi povas kontroli kiel uzantoj interagas kun nova funkcio, ĉu ili estas toksomaniuloj al ĝi aŭ trovas la novan uzantinterfacon konfuza, kaj aliajn specojn de metrikoj.
Flagger kaj A/B Deplojoj
Krom pezbalancita vojigo, Flagger ankaŭ povas direkti trafikon al la kanaria servilo bazita sur HTTP-parametroj. A/B-testado povas uzi HTTP-kapojn aŭ kuketojn por redirekti specifan segmenton de uzantoj. Ĉi tio estas precipe efika en la kazo de fasad-aplikoj, kiuj postulas, ke la sesio estu ligita al la servilo. (sesionafineco). Pliaj informoj troveblas en la dokumentaro de Flagger.
La aŭtoro estas dankema , inĝeniero de Weaveworks (kaj kreinto de Flagger), por ĉiuj ĉi tiuj mirindaj deplojskemoj.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com