Note Iwwersetzung: Dësen Iwwerbléck vu Weaveworks stellt déi populärste Applikatioun Rollout Strategien vir a weist wéi déi meescht fortgeschratt kënne implementéiert ginn mam Kubernetes Flagger Bedreiwer. Et ass an enger einfacher Sprooch geschriwwen an enthält visuell Diagrammer déi et erlaben och Ufänger Ingenieuren d'Thema ze verstoen.
D'Diagramm ass geholl aus Ausrollstrategien gemaach a Container Léisunge
Eng vun de gréissten Erausfuerderunge bei der Entwécklung vun Cloud-native Uwendungen haut ass d'Beschleunigung vun der Détachement. An enger Microservices Approche schaffen d'Entwéckler scho mat a designen komplett modulär Uwendungen, wat verschidden Teams erlaabt gläichzäiteg Code ze schreiwen an Ännerungen un der Applikatioun ze maachen.
Kuerz a méi heefeg Deployementer hunn déi folgend Virdeeler:
- Zäit fir de Maart gëtt reduzéiert.
- Nei Features erreechen Benotzer méi séier.
- Benotzer Feedback erreecht d'Entwécklungsteam méi séier. Dëst bedeit datt d'Team Features ka addéieren an Themen méi séier fixéieren.
- Entwéckler Moral erhéicht: méi Features an der Entwécklung si méi lëschteg mat ze schaffen.
Awer wéi d'Frequenz vun de Verëffentlechungen eropgeet, klammen d'Chancen och negativ op d'Zouverlässegkeet vun der Applikatioun oder d'Benotzererfarung. Dofir ass et wichteg fir Operatiounen an DevOps Teams fir Prozesser ze bauen an Deploymentstrategien ze managen op eng Manéier déi de Risiko fir d'Produkt an d'Benotzer miniméiert. (Dir kënnt méi iwwer CI / CD Pipeline Automatioun léieren .)
An dësem Post wäerte mir verschidde Deploymentstrategien an Kubernetes diskutéieren, dorënner Rolling Deployment a méi fortgeschratt Methoden wéi Kanaresch Rollouts an hir Variatiounen.
Deployment Strategien
Et gi verschidde verschidden Aarte vun Deploymentstrategien déi Dir benotze kënnt ofhängeg vun Ärem Zil. Zum Beispill musst Dir Ännerunge fir e bestëmmten Ëmfeld fir weider Tester maachen, oder un e Subset vu Benotzer / Clienten, oder Dir musst limitéiert Benotzertesten maachen ier Dir eng Feature maacht ëffentlech.
Rolling (graduell, "rolling" Deployment)
Dëst ass d'Standard Deployment Strategie a Kubernetes. Et ersetzt graduell, een nom aneren, Pods mat der aler Versioun vun der Applikatioun mat Pods mat der neier Versioun - ouni Cluster Downtime.
Kubernetes waart bis nei Pods prett sinn ze schaffen (kontrolléiert se mat ), ier Dir ufänkt déi al ze rullen. Wann e Problem geschitt ass, kann dës Rolling Update ofgebrach ginn ouni de ganze Cluster ze stoppen. An der YAML Datei, déi den Deploymenttyp beschreift, ersetzt dat neit Bild dat alt Bild:
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: 8080D'Rollover Update Parameter kënnen an der Manifestdatei spezifizéiert ginn:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreéieren
An dësem einfachsten Typ vun Ofbau ginn al Pods op eemol ëmbruecht an duerch nei ersat:
Dat entspriechend Manifest gesäit sou eppes aus:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blo/Gréng (blo-gréng Deployementer)
Déi blo-gréng Deploymentstrategie (heiansdo och rout / schwaarz genannt) beinhalt d'simultan Deployment vun der aler (gréng) an neier (blo) Versioun vun der Applikatioun. Nodeems Dir béid Versioune gepost hutt, hunn regelméisseg Benotzer Zougang zum gréngen, während de bloe verfügbar ass fir d'QA Team fir Tester duerch e separaten Service oder direkten Port Forwarding ze automatiséieren:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Nodeems déi blo (nei) Versioun getest gouf a seng Verëffentlechung guttgeheescht gouf, wiesselt de Service op et, an déi gréng (al) Versioun ass geklappt:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanaresch (Kanaresch Deployment)
Kanaresch Rollouts sinn ähnlech wéi blo-gréng Rollouts, awer hu besser Kontroll a Gebrauch Schrëtt fir Schrëtt Approche. Dësen Typ enthält verschidde verschidde Strategien, dorënner "stealth" lancéiert an A / B Testen.
Dës Strategie gëtt benotzt wann et néideg ass e puer nei Funktionalitéit ze probéieren, normalerweis am Backend vun der Applikatioun. D'Essenz vun der Approche ass zwee bal identesch Serveren ze kreéieren: een déngt bal all Benotzer, an deen aneren, mat neie Funktiounen, déngt nëmmen eng kleng Ënnergrupp vu Benotzer, no deenen d'Resultater vun hirer Aarbecht verglach ginn. Wann alles ouni Feeler geet, gëtt déi nei Versioun no an no an d'ganz Infrastruktur ausgerullt.
Och wann dës Strategie exklusiv mat Kubernetes implementéiert ka ginn, al Pods mat neien ersetzen, ass et vill méi praktesch a méi einfach e Service Mesh wéi Istio ze benotzen.
Zum Beispill, Dir hutt vläicht zwee verschidde Manifestatiounen am Git: e reguläre Manifest mam Tag 0.1.0 an e Kanaresch Manifest mam Tag 0.2.0. Andeems Dir d'Gewiichter am Istio virtuelle Paart Manifest ännert, kënnt Dir d'Verdeelung vum Traffic tëscht dësen zwou Deployementer kontrolléieren:
Fir e Schrëtt-vun-Schrëtt Guide fir d'Ëmsetzung vun Kanaresch Deployementer mat Istio ëmzesetzen, kuckt . (Note. iwwersat.: Mir hunn och Material iwwer Kanaresch Rollouts an Istio iwwersat .)
Canary Deployments mat Weaveworks Flagger
erlaabt Iech einfach an effektiv Kanaresch Rollouts ze verwalten.
Flagger automatiséiert Aarbecht mat hinnen. Et benotzt Istio oder AWS App Mesh fir Traffic ze routen an ze wiesselen, a Prometheus Metriken fir d'Resultater ze analyséieren. Zousätzlech kann d'Analyse vu Kanaresch Deployementer mat Webhooks ergänzt ginn fir Akzeptanztests, Laaschtester an all aner Aarte vu Kontrollen ze maachen.
Baséierend op der Kubernetes Deployment an, wann néideg, horizontaler Skaléierung vu Pods (HPA), erstellt Flagger Sets vun Objekter (Kubernetes Deployments, ClusterIP Servicer an Istio oder App Mesh virtuelle Servicer) fir Kanaresch Deployementer ze analyséieren an ëmzesetzen:
Ëmsetzung vun der Kontroll Loop (Kontrollschleife), Flagger schalt lues a lues de Traffic op de Kanaresch Server, a gläichzäiteg moosst Schlësselleistungsmetriken wéi de Prozentsaz vun erfollegräichen HTTP-Ufroen, duerchschnëttlech Ufro-Dauer, a Pod-Gesondheet. Baséierend op der KPI (Key Performance Indicators) Analyse, wächst de Kanaresch entweder wächst oder kollapst an d'Resultater vun der Analyse ginn am Slack publizéiert. Eng Beschreiwung an Demonstratioun vun dësem Prozess kann am Material fonnt ginn .
Däischter (verstoppt) oder A/B Deployment
Stealth Deployment ass eng aner Variatioun vun der Kanaresch Strategie (déi, iwwregens, Flagger och ka schaffen). Den Ënnerscheed tëscht Stealth a Kanaresch Deployementer ass datt Stealth Deployementer sech mam Frontend beschäftegen anstatt dem Backend wéi Kanaresch Deployementer.
En aneren Numm fir dës Deployementer ass A/B Testen. Amplaz déi nei Feature fir all Benotzer verfügbar ze maachen, gëtt se nëmmen e limitéierten Deel vun hinnen ugebueden. Typesch sinn dës Benotzer net bewosst datt se Pionéier Tester sinn (also de Begrëff "Stealth Deployment").
Benotzt Funktionalitéit Schalter (Feature Toggle) an aner Tools, Dir kënnt iwwerwaachen wéi d'Benotzer mat der neier Feature interagéieren, ob se dovun engagéiert sinn, oder ob se déi nei User-Interface konfus fannen, an aner Zorte vu Metriken.
Flagger an A/B Deployment
Zousätzlech zu Gewiicht-baséiert Routing, kann Flagger och Traffic op de Kanaresch Server op Basis vun HTTP-Parameteren routen. An A/B Testen kënnt Dir HTTP Header oder Cookien benotzen fir e spezifescht Segment vun de Benotzer ze zielen. Dëst ass besonnesch effektiv am Fall vu Frontend Uwendungen déi Sessiounsbindung un de Server erfuerderen (Sessioun Affinitéit). Méi Informatioun fannt Dir an der Flagger Dokumentatioun.
Den Auteur dréckt Dankbarkeet aus , Weaveworks Ingenieur (a Schëpfer vu Flagger), fir all dës erstaunlech Deploymentmuster.
PS vum Iwwersetzer
Liest och op eisem Blog:
- «";
- «";
- «";
- «".
Source: will.com