🥇Kubernetes-implementatiestrategieën: rollen, opnieuw maken, blauw/groen, kanarie, donker (A/B-testen)

Opmerking. vertaling: Deze walkthrough van Weaveworks introduceert de meest populaire strategieën voor het uitrollen van applicaties en hoe u de meest geavanceerde kunt implementeren met de Flagger Kubernetes-operator. Het is geschreven in eenvoudige taal en bevat visuele diagrammen waarmee zelfs beginnende ingenieurs het probleem kunnen begrijpen.

Schema overgenomen van nog een recensie uitrolstrategieën gemaakt in Container Solutions

Een van de grootste uitdagingen bij het ontwikkelen van cloud-native applicaties vandaag de dag is de implementatiesnelheid. Met een microservicebenadering werken ontwikkelaars al met en ontwerpen ze volledig modulaire applicaties, waardoor verschillende teams tegelijkertijd code kunnen schrijven en wijzigingen in de applicatie kunnen aanbrengen.

Kortere en frequentere implementaties hebben de volgende voordelen:

Kortere time-to-market.
Nieuwe functies komen sneller bij gebruikers.
Gebruikersfeedback bereikt het ontwikkelteam sneller. Dit betekent dat het team sneller functies kan toevoegen en problemen kan oplossen.
Het moreel van de ontwikkelaar stijgt: meer functies in ontwikkeling zijn leuker om mee te werken.

Maar naarmate de frequentie van releases toeneemt, neemt ook de kans toe dat de betrouwbaarheid of gebruikerservaring van de app negatief wordt beïnvloed. Daarom is het belangrijk voor operationele en DevOps-teams om processen op te bouwen en implementatiestrategieën te beheren op een manier die het risico voor het product en de gebruikers minimaliseert. (Zie voor meer informatie over het automatiseren van de CI/CD-pijplijn hier.)

In dit bericht bespreken we verschillende Kubernetes-implementatiestrategieën, waaronder rollende implementaties en meer geavanceerde methoden zoals canary-implementaties en hun variaties.

Implementatiestrategieën

Er zijn verschillende soorten implementatiestrategieën die kunnen worden gebruikt, afhankelijk van het doel. U moet bijvoorbeeld mogelijk wijzigingen aanbrengen in een bepaalde omgeving voor verder testen, of in een subset van gebruikers/clients, of u moet mogelijk beperkte tests uitvoeren op gebruikers voordat u een functie maakt openbaar.

Rolling (geleidelijke, rollende implementatie)

Dit is de standaard implementatiestrategie voor Kubernetes. Het vervangt geleidelijk, één voor één, de pods met de oude versie van de applicatie door pods met de nieuwe versie - zonder downtime van het cluster.

Kubernetes wacht tot nieuwe pods klaar zijn voor gebruik (controleert ze met gereedheidstesten) voordat u doorgaat met het oprollen van de oude. Als er een probleem optreedt, kan een dergelijke doorlopende update worden afgebroken zonder het hele cluster te stoppen. In het YAML-bestand van het implementatietype 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: 8080

De parameters van de doorlopende update kunnen worden opgegeven in het manifestbestand:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Herscheppen (herscheppen)

Bij dit eenvoudigste type implementatie worden oude pods allemaal tegelijk gedood en vervangen door nieuwe:

Het bijbehorende manifest ziet er ongeveer zo uit:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blauw/Groen (blauw-groene implementaties)

De blauw-groene implementatiestrategie (soms ook wel rood/zwart genoemd, d.w.z. rood-zwart) houdt in dat de oude (groene) en nieuwe (blauwe) versies van de applicatie gelijktijdig worden geïmplementeerd. Zodra beide versies zijn gehost, is de groene beschikbaar voor de algemene gebruiker, terwijl de blauwe beschikbaar is voor het QA-team om tests te automatiseren via een aparte service of directe port forwarding:

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 goedgekeurd voor vrijgave, wordt de service daarop overgeschakeld en wordt de groene (oude) versie geminimaliseerd:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Kanarie (kanarie-implementaties)

Kanarie-uitrol is vergelijkbaar met blauwgroen, maar beter gecontroleerd en gebruikt progressief stap voor stap aanpak. Verschillende strategieën vallen in deze categorie, waaronder geheime lanceringen en A/B-testen.

Deze strategie wordt gebruikt wanneer een nieuwe functionaliteit moet worden getest, meestal in de backend van de applicatie. De essentie van de aanpak is om twee vrijwel identieke servers te creëren: de ene bedient bijna alle gebruikers en de andere, met nieuwe functies, bedient slechts een kleine subgroep van gebruikers, waarna de resultaten van hun werk worden vergeleken. Als alles foutloos verloopt, wordt de nieuwe versie stapsgewijs uitgerold naar de volledige infrastructuur.

Hoewel deze strategie exclusief kan worden geïmplementeerd met behulp van Kubernetes, waarbij oude pods worden vervangen door nieuwe, is het veel handiger en gemakkelijker om een servicemesh zoals Istio te gebruiken.

U kunt bijvoorbeeld twee verschillende Git-manifesten hebben: een normale met een tag van 0.1.0 en een kanarie met een tag van 0.2.0. Door de gewichten in het Istio Virtual Gateway-manifest te wijzigen, kunt u de verdeling van het verkeer tussen deze twee implementaties beheren:

Een stapsgewijze handleiding voor het implementeren van canary-implementaties met Istio is te vinden in GitOps-workflows met Istio. (Opmerking. vert.: We hebben ook materiaal vertaald over kanariebroodjes in Istio hier.)

Canarische implementaties met Weaveworks Flagger

Weaveworks-vlagger maakt een gemakkelijke en efficiënte controle van kanarierollen mogelijk.

Flagger automatiseert het werken met hen. Het gebruikt Istio of AWS App Mesh om verkeer te routeren en om te schakelen, en Prometheus-statistieken om de resultaten te analyseren. Daarnaast kan de analyse van kanarie-implementaties worden aangevuld met webhooks voor het uitvoeren van acceptatietesten, belastingtesten en andere soorten controles.

Op basis van de implementatie van Kubernetes en, indien nodig, scale-out pods (HPA), maakt Flagger sets van objecten (Kubernetes-implementaties, ClusterIP-services en Istio of App Mesh virtuele services) om kanarie-implementaties te analyseren en te implementeren:

Implementeren van een controlelus (regellus)Flagger schakelt het verkeer geleidelijk over naar de canary-server terwijl belangrijke prestatiestatistieken worden gemeten, zoals het slagingspercentage van HTTP-verzoeken, de gemiddelde duur van het verzoek en de status van de pod. Op basis van de analyse van KPI's (Key Performance Indicators) groeit of krimpt het kanariedeel en worden de resultaten van de analyse gepubliceerd in Slack. Een beschrijving en demonstratie van dit proces is te vinden in het materiaal Progressieve levering voor app-mesh.

Donkere (verborgen) of A/B-implementaties

Stealth-implementatie is een andere variant van de kanariestrategie (waar Flagger trouwens ook mee kan werken). Het verschil tussen stealth- en kanarie-implementaties is dat stealth-implementaties te maken hebben met de voorkant en niet met de backend zoals kanarie-implementaties dat doen.

Een andere naam voor deze implementaties is A/B-testen. In plaats van de toegang tot een nieuwe functie voor alle gebruikers open te stellen, wordt deze slechts aan een beperkt deel van hen aangeboden. Meestal weten deze gebruikers niet dat ze baanbrekende testers zijn (vandaar de term "stille implementatie").

Met functieschakelaars (functie wisselt) en andere tools, kunt u controleren hoe gebruikers omgaan met een nieuwe functie, of ze er verslaafd aan zijn of de nieuwe gebruikersinterface verwarrend vinden, en andere soorten statistieken.

Flagger- en A/B-implementaties

Naast gewogen routering kan Flagger ook verkeer naar de canary-server routeren op basis van HTTP-parameters. A/B-testen kunnen HTTP-headers of cookies gebruiken om een specifiek segment van gebruikers om te leiden. Dit is vooral effectief in het geval van frontend-applicaties waarbij de sessie aan de server moet worden gebonden. (sessie affiniteit). Meer informatie is te vinden in de Flagger-documentatie.

De auteur is dankbaar Stefan Prodán, ingenieur van Weaveworks (en maker van Flagger), voor al deze geweldige implementatieschema's.

Kubernetes-implementatiestrategieën: rollen, opnieuw maken, blauw/groen, kanarie, donker (A/B-testen)