Opmerking van de vertaler: Dit overzicht van Weaveworks introduceert de meest populaire applicatiewijzigingsstrategieën en bespreekt de mogelijkheden om de meest geavanceerde daarvan te realiseren met behulp van de Kubernetes-operator Flagger. Het is geschreven in eenvoudige taal en bevat duidelijke schema's die het zelfs beginnende ingenieurs gemakkelijker maken om het onderwerp te begrijpen.
De diagram is afkomstig uit van implementatiestrategieën, gemaakt door Container Solutions
Een van de grootste uitdagingen bij het ontwikkelen van cloud native-applicaties vandaag de dag is het versnellen van de implementatie. Bij een microservices-aanpak werken ontwikkelaars al met volledig modulaire applicaties en ontwerpen ze deze, zodat verschillende teams gelijktijdig code kunnen schrijven en wijzigingen in de applicatie kunnen aanbrengen.
Kortere en frequentere implementaties hebben de volgende voordelen:
- De tijd tot de markt wordt verkort.
- Nieuwe functies komen sneller bij gebruikers.
- Klantfeedback bereikt het ontwikkelingsteam sneller. Dit betekent dat het team functies kan aanvullen en problemen sneller kan verhelpen.
- De moraal van de ontwikkelaars stijgt: met meer functies in ontwikkeling is het interessanter om te werken.
Maar met een toename in de frequentie van releases, neemt ook de kans toe om de betrouwbaarheid van de applicatie of de gebruikerservaring negatief te beïnvloeden. Daarom is het voor operationele teams en DevOps belangrijk om processen te bouwen en implementatiestrategieën te beheren zodat de risico's voor het product en de gebruikers minimaal blijven. (Lees meer over het automatiseren van de CI/CD-pijplijn) .)
In deze publicatie zullen we verschillende implementatiestrategieën in Kubernetes bespreken, inclusief rolling-implementaties en geavanceerdere methoden zoals canary-releases en hun varianten.
Implementatiestrategieën
Er zijn verschillende soorten implementatiestrategieën die je kunt gebruiken, afhankelijk van het doel. Zo kan het nodig zijn om wijzigingen aan te brengen in een omgeving voor verder testen, of in een subset van gebruikers/clienten, of het kan noodzakelijk zijn om een beperkte test uit te voeren bij gebruikers voordat je een bepaalde functie publiek beschikbaar maakt.
Rolling (geleidelijke, 'opbouwende' implementatie)
Dit is de standaard implementatiestrategie in Kubernetes. Het vervangt geleidelijk, één voor één, pods met de oude versie van de applicatie door pods met de nieuwe versie — zonder downtime van het cluster.
Kubernetes wacht tot de nieuwe pods gereed zijn voor gebruik (door deze te controleren met ), voordat het begint met het afschalen van de oude. Als er zich een probleem voordoet, kan deze roll-out worden onderbroken zonder het hele cluster stop te zetten. In het YAML-bestand dat het type deployment beschrijft, vervangt de nieuwe afbeelding de oude afbeelding:
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: 8080De parameters voor de roll-out kunnen worden gespecificeerd in het manifestbestand:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate
In dit eenvoudigste type implementatie worden de oude pods allemaal tegelijk beëindigd en vervangen door nieuwe:
Het bijbehorende manifest ziet er ongeveer zo uit:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green
De blue-green implementatiestrategie (soms ook wel red/black genoemd) omvat gelijktijdige implementatie van de oude (groene) en nieuwe (blauwe) versies van de applicatie. Na het plaatsen van beide versies krijgen gewone gebruikers toegang tot de groene versie, terwijl de blauwe beschikbaar is voor het QA-team voor automatiseringstests via een afzonderlijke service of directe poortdoorsturen:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Nadat de blauwe (nieuwe) versie is getest en de release is goedgekeurd, schakelt de service over naar deze versie en wordt de groene (oude) versie afgeschakeld:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary
Canary-implementaties lijken op blue-green, maar worden beter beheerd en gebruiken een stapsgewijze aanpak. Dit type omvat verschillende strategieën, waaronder "stille" uitrol en A/B-testen.
Deze strategie wordt toegepast wanneer er nieuwe functionaliteit getest moet worden, meestal in de backend van de applicatie. Het idee achter deze aanpak is om twee nagenoeg identieke servers te creëren: één die vrijwel alle gebruikers bedient en de andere, met de nieuwe functies, die slechts een kleine subgroep van gebruikers bedient. Daarna worden de resultaten vergeleken. Als alles zonder fouten verloopt, wordt de nieuwe versie geleidelijk uitgerold naar de volledige infrastructuur.
Hoewel deze strategie uitsluitend met Kubernetes kan worden uitgevoerd door oude pod's door nieuwe te vervangen, is het veel handiger en eenvoudiger om een service mesh zoals Istio te gebruiken.
Bijvoorbeeld, je kunt twee verschillende manifests in Git hebben: een gewone met de tag 0.1.0 en een 'canary' met de tag 0.2.0. Door de gewichten in het Istio virtuele gateway manifest te wijzigen, kun je het verkeer tussen deze twee deployment's beheren:
Een stapsgewijze handleiding voor het implementeren van canary-deployments met Istio vind je in het materiaal . (Opmerking vertaler.: We hebben ook materiaal vertaald over canary releases in Istio. .)
Canary deployments met Weaveworks Flagger
maakt het gemakkelijk en effectief om canary-releases te beheren.
Flagger automatiseert het werk met hen. Het gebruikt Istio of AWS App Mesh voor het routeren en schakelen van verkeer, evenals Prometheus-metrieken voor het analyseren van resultaten. Bovendien kan de analyse van canary deployments worden uitgebreid met webhooks voor acceptatietests, belastingstests en andere soorten controles.
Op basis van de Kubernetes deployment en, indien nodig, horizontale schaalvergroting van pod's (HPA), creëert Flagger sets van objecten (Kubernetes deployment's, ClusterIP-services en virtuele Istio- of App Mesh-services) voor de analyse en implementatie van canary deployments:
Door een controlelus (control loop), schakelt Flagger geleidelijk het verkeer over naar de canary-server, terwijl de belangrijke prestatie-indicatoren worden gemeten, zoals het percentage succesvolle HTTP-verzoeken, de gemiddelde responstijd en de gezondheid van de pod's. Op basis van de KPI-analyse (belangrijke prestatie-indicatoren) groeit of krimpt de canary-kant, en de resultaten van de analyse worden gepubliceerd in Slack. Een beschrijving en demonstratie van dit proces vind je in het materiaal .
Donkere (verborgen) of A/B-implementaties
Verborgen implementatie is een andere variant van de canary-strategie (hiervoor kan Flagger ook werken). Het verschil tussen verborgen en canary-implementaties is dat verborgen implementaties betrekking hebben op de frontend, in tegenstelling tot de backend, zoals bij canary-implementaties.
Een andere naam voor deze implementaties is A/B-testen. In plaats van de nieuwe functie aan alle gebruikers beschikbaar te stellen, wordt deze slechts aan een beperkte groep aangeboden. Gewoonlijk weten deze gebruikers niet dat ze test-pioniers zijn (vandaar de term 'verborgen implementatie').
Met behulp van functionaliteits schakelaars (feature toggles) en andere tools kan worden gevolgd hoe gebruikers interageren met de nieuwe functie, of ze erbij betrokken zijn of de nieuwe gebruikersinterface verwarrend vinden, evenals andere soorten statistieken.
Flagger en A/B-implementaties
Naast gewicht-gebaseerde routering kan Flagger ook het verkeer naar een canary-server omleiden op basis van HTTP-parameters. Bij A/B-testen kunnen HTTP-headers of cookies worden gebruikt om een specifiek segment van gebruikers om te leiden. Dit is vooral effectief in geval van frontend-applicaties die sessie-affiniteit met de server vereisen (session affinity). Verdere informatie is te vinden in de documentatie van Flagger.
De auteur bedankt , ingenieur bij Weaveworks (en maker van Flagger), voor al deze geweldige implementatieschema’s.
P.S. van de vertaler
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
