Udrulningsstrategier i Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-testning)

Bem. oversættelse: Dette introduktionsmateriale fra Weaveworks præsenterer de mest populære applikationsudrulningsstrategier og beskriver mulighederne for at implementere de mest avancerede af dem ved hjælp af Kubernetes-operatoren Flagger. Det er skrevet i et forståeligt sprog og indeholder illustrative diagrammer, der gør det muligt selv for nybegyndere at forstå emnet.

Diagrammet er hentet fra et andet review af udrulningsstrategier lavet hos Container Solutions

En af de største udfordringer ved udviklingen af cloud native-applikationer i dag er at fremskynde deployment. Med en mikrotjeneste-tilgang arbejder udviklerne allerede med fuldt modulære applikationer og designer dem, så forskellige teams kan skrive kode og foretage ændringer i applikationen samtidig.

Kortere og hyppigere udrulninger har følgende fordele:

• Markedsføringstiden forkortes.
• Nye funktioner når hurtigere ud til brugerne.
• Brugerfeedback når hurtigere frem til udviklingsteamet. Dette indebærer, at teamet kan tilføje funktioner og rette problemer hurtigere.
• Udviklernes moral øges: Det er sjovere at arbejde med flere funktioner under udvikling.

Men med en øget udrulningsfrekvens øges også risikoen for at påvirke applikationens stabilitet eller brugeroplevelsen negativt. Derfor er det vigtigt for driftsteams og DevOps at opbygge processer og styre udrulningsstrategier på en måde, der minimerer risikoen for produktet og brugerne. (Læs mere om automatisering af CI/CD-pipelinen her.)

I denne publikation vil vi diskutere forskellige udrulningsstrategier i Kubernetes, herunder rolling deployment og mere avancerede metoder som canary deployments og deres varianter.

Deploy-strategier

Der findes flere forskellige typer udrulningsstrategier, som man kan bruge afhængigt af formålet. For eksempel kan det være nødvendigt at foretage ændringer i et bestemt miljø til videre test, eller til et undergruppe af brugere/kunder, eller der kan opstå behov for at udføre begrænset test på brugere, før en funktion bliver offentlig tilgængelig.

Rolling (progressiv, 'gradvis' udrulning)

Det er en standard udrulningsstrategi i Kubernetes. Den opgraderer gradvist, én efter én, pods med den gamle version af applikationen til pods med den nye version — uden at forårsage nedetid i klyngen.

Kubernetes venter på, at de nye pods er klar til drift (ved at tjekke dem med readiness-tests), før den begynder at rulle de gamle tilbage. Hvis der opstår et problem, kan denne rullende opdatering stoppes uden at stoppe hele klyngen. I YAML-filen, der beskriver typen af udrulning, erstatter det nye billede det gamle billede:

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

Parametrene for den rullende opdatering kan præciseres i manifestfilen:

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

Recreate (genoprettelse)

I denne enkleste type udrulning dræbes de gamle pods på én gang og erstattes med nye:

Det relevante manifest ser omtrent sådan ud:

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

Blue/Green (blå/grønne udrulninger)

Strategien for blå/grønne udrulninger (nogle gange kaldet rød/sort) indebærer samtidig udrulning af den gamle (grønne) og den nye (blå) version af applikationen. Efter at begge versioner er placeret, får almindelige brugere adgang til den grønne, mens den blå er tilgængelig for QA-teamet til automatiserede tests via en separat service eller direkte port-forwarding:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Når den blå (nye) version er testet og dens udgivelse er godkendt, skifter tjenesten til den, mens den grønne (gamle) rulles tilbage:

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

Canary (kanariefugleudrulninger)

Kanariefugleudrulninger ligner de blå/grønne, men styres bedre og bruger en progressiv trinvist tilgang. Denne type inkluderer flere forskellige strategier, herunder 'skjulte' lanceringer og A/B-test.

Denne strategi anvendes, når det er nødvendigt at teste en ny funktionalitet, typisk i backend af en applikation. Essensen af tilgangen er at oprette to næsten identiske servere: den ene betjener næsten alle brugere, mens den anden, med de nye funktioner, kun betjener en lille undergruppe af brugere, hvorefter resultaterne af deres arbejde sammenlignes. Hvis alt forløber uden fejl, rulles den nye version gradvist ud til hele infrastrukturen.

Selvom denne strategi kan implementeres udelukkende ved hjælp af Kubernetes ved at erstatte gamle pod’er med nye, er det meget mere bekvemt og lettere at bruge en service mesh som Istio.

For eksempel kan du have to forskellige manifester i Git: en almindelig med tag 0.1.0 og en "kanariefugl" med tag 0.2.0. Ved at ændre vægtene i manifestet for den virtuelle gateway i Istio kan du styre trafikfordelingen mellem disse to deployment’er:

En trin-for-trin vejledning til implementering af kanariefugle deployments med Istio kan findes i materialet GitOps Workflows with Istio. (Bem. overs.: Vi har også oversat materialet om kanariefugle udrulninger i Istio her.)

Kanariefugle deployments med Weaveworks Flagger

Weaveworks Flagger gør det nemt og effektivt at styre kanariefugle udrulninger.

Flagger automatiserer arbejdet med dem. Den bruger Istio eller AWS App Mesh til at dirigere og skifte trafik samt Prometheus-metrikker til at analysere resultaterne. Desuden kan analysen af kanariefugle udrulninger suppleres med webhooks til at udføre accepttest, belastningstest og enhver anden type kontroller.

Baseret på Kubernetes deployment’en og, hvis nødvendigt, horisontal skalering af pod’er (HPA), skaber Flagger sæt af objekter (Kubernetes deployment’er, ClusterIP-tjenester og virtuelle tjenester i Istio eller App Mesh) til analyse og implementering af kanariefugle udrulninger:

Ved at implementere en kontrolsløjfe (control loop), skifter Flagger gradvist trafikken til kanariefugle serveren, samtidig med at den måler nøglepræstationsindikatorer, såsom andelen af succesrige HTTP-anmodninger, den gennemsnitlige anmodningsvarighed og sundheden af pod’er. Baseret på analysen af KPI (nøglepræstationsindikatorer) vokser den kanariefugle del enten eller svinder, og analyseresultaterne offentliggøres i Slack. Beskrivelse og demonstration af denne proces kan findes i materialet Progressive Delivery for App Mesh.

Darker (skjulte) eller A/B-udrulninger

Skjult udrulning er en anden variant af kanaristrategien (som Flagger også kan arbejde med). Forskellen mellem skjulte og kanariske udrulninger er, at skjulte udrulninger handler om frontend og ikke backend, som kanariske udrulninger.

Et andet navn for disse udrulninger er A/B-testning. I stedet for at åbne for en ny funktion for alle brugere, tilbys den kun til en begrænset del af dem. Normalt ved disse brugere ikke, at de fungerer som testere (deraf termen "skjult udrulning").

Ved hjælp af funktionalitetsomskiftere (feature toggles) og andre værktøjer kan man overvåge, hvordan brugerne interagerer med den nye funktion, om den fanger deres opmærksomhed, eller om de finder den nye brugergrænseflade forvirrende, samt andre typer metrics.

Flagger og A/B-udrulninger

Ud over vægtet routing kan Flagger også dirigere trafik til en kanariseret server baseret på HTTP-parametre. Ved A/B-testning kan man bruge HTTP-headers eller cookies til at omdirigere en bestemt brugergruppe. Dette er særligt effektivt for frontend-applikationer, der kræver session-affinitet til serveren (session affinity). Yderligere information kan findes i Flagger-dokumentationen.

Forfatteren takker Stefan Prodan, ingeniør hos Weaveworks (og skaber af Flagger), for alle disse fantastiske udrulningsskemaer.

P.S. fra oversætteren

Læs også på vores blog:

• «Oversigt og sammenligning af Ingress controllere til Kubernetes»;
• «werf — vores værktøj til CI/CD i Kubernetes (oversigt og video af præsentationen)»;
• «Bygning og udrulning af ensartede mikrotjenester med werf og GitLab CI»;
• «Hvad er GitOps?».

Kilde: habr.com