Notera översättning: Den här översikten från Weaveworks introducerar de mest populära strategierna för programutrullning och visar hur de mest avancerade kan implementeras med Kubernetes Flagger-operatör. Den är skriven på ett enkelt språk och innehåller visuella diagram som gör att även nybörjare kan förstå problemet.
Diagrammet är hämtat från utrullningsstrategier gjorda i Container Solutions
En av de största utmaningarna med att utveckla molnbaserade applikationer idag är att påskynda distributionen. I en mikrotjänstmetod arbetar utvecklare redan med och designar helt modulära applikationer, vilket gör att olika team kan skriva kod samtidigt och göra ändringar i applikationen.
Kortare och mer frekventa driftsättningar har följande fördelar:
- Time to market reduceras.
- Nya funktioner når användarna snabbare.
- Användarfeedback når utvecklingsteamet snabbare. Detta innebär att teamet kan lägga till funktioner och åtgärda problem snabbare.
- Utvecklarmoralen ökar: fler funktioner i utvecklingen är roligare att arbeta med.
Men när frekvensen av utgivningar ökar, ökar också chanserna att negativt påverka applikationens tillförlitlighet eller användarupplevelse. Det är därför det är viktigt för drift- och DevOps-team att bygga processer och hantera implementeringsstrategier på ett sätt som minimerar riskerna för produkten och användarna. (Du kan lära dig mer om CI/CD-pipelineautomatisering .)
I det här inlägget kommer vi att diskutera olika distributionsstrategier i Kubernetes, inklusive rullande distributioner och mer avancerade metoder som kanariefågel-utrullningar och deras variationer.
Implementeringsstrategier
Det finns flera olika typer av distributionsstrategier som du kan använda beroende på ditt mål. Till exempel kan du behöva göra ändringar i en viss miljö för ytterligare testning, eller i en delmängd av användare/klienter, eller så kan du behöva göra begränsade användartester innan du skapar en funktion offentlig.
Rullande (gradvis, "rullande" distribution)
Detta är standardimplementeringsstrategin i Kubernetes. Den ersätter gradvis, en efter en, poddar med den gamla versionen av applikationen med poddar med den nya versionen - utan klusterstopp.
Kubernetes väntar tills nya pods är redo att arbeta (kontrollera dem med ), innan du börjar rulla upp de gamla. Om ett problem uppstår kan denna rullande uppdatering avbrytas utan att stoppa hela klustret. I YAML-filen som beskriver distributionstypen ersätter den nya bilden den gamla bilden:
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: 8080Parametrarna för rollover-uppdatering kan anges i manifestfilen:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Återskapa
I den här enklaste typen av distribution dödas gamla baljor på en gång och ersätts med nya:
Motsvarande manifest ser ut ungefär så här:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blå/grön (blå-grön distributioner)
Den blågröna implementeringsstrategin (ibland även kallad röd/svart) innebär samtidig distribution av de gamla (gröna) och nya (blå) versionerna av applikationen. Efter att ha lagt upp båda versionerna har vanliga användare tillgång till den gröna, medan den blå är tillgänglig för QA-teamet för att automatisera tester genom en separat tjänst eller direkt vidarebefordran av port:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Efter att den blå (nya) versionen har testats och dess release har godkänts, byter tjänsten till den och den gröna (gamla) versionen viks:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanarieöarna (kanariefågel)
Canary-utrullningar liknar blågröna utrullningar, men har bättre kontroll och användning steg-för-steg tillvägagångssätt. Denna typ inkluderar flera olika strategier, inklusive "stealth"-lanseringar och A/B-tester.
Denna strategi används när det finns ett behov av att testa någon ny funktionalitet, vanligtvis i applikationens backend. Kärnan i tillvägagångssättet är att skapa två nästan identiska servrar: en betjänar nästan alla användare, och den andra, med nya funktioner, betjänar endast en liten undergrupp av användare, varefter resultaten av deras arbete jämförs. Om allt går felfritt rullas den nya versionen successivt ut till hela infrastrukturen.
Även om denna strategi uteslutande kan implementeras med hjälp av Kubernetes, genom att ersätta gamla poddar med nya, är det mycket bekvämare och enklare att använda ett servicenät som Istio.
Till exempel kan du ha två olika manifest i Git: ett vanligt manifest med taggen 0.1.0 och ett kanariefågelmanifest med taggen 0.2.0. Genom att ändra vikterna i Istio virtuella gateway-manifest kan du styra distributionen av trafik mellan dessa två distributioner:
För en steg-för-steg-guide för att implementera kanariefågelinstallationer med Istio, se . (Notera. transl.: Vi har även översatt material om utrullningar av kanariefåglar till Istio .)
Canary-utbyggnader med Weaveworks Flagger
låter dig enkelt och effektivt hantera utrullningar av kanariefåglar.
Flagger automatiserar arbetet med dem. Den använder Istio eller AWS App Mesh för att dirigera och byta trafik, och Prometheus-statistik för att analysera resultaten. Dessutom kan analysen av kanariefågelutbyggnader kompletteras med webhooks för att utföra acceptanstest, belastningstester och andra typer av kontroller.
Baserat på Kubernetes-distributionen och, om nödvändigt, horisontell skalning av pods (HPA), skapar Flagger uppsättningar av objekt (Kubernetes-distributioner, ClusterIP-tjänster och virtuella Istio- eller App Mesh-tjänster) för att analysera och implementera kanariefågel-distributioner:
Implementering av kontrollslingan (Styrslinga),Flagger växlar gradvis trafik till kanariefågelservern, samtidigt som den mäter nyckelprestandamått som andelen lyckade HTTP-förfrågningar, genomsnittlig förfrågningslängd och pods hälsa. Baserat på KPI-analysen (Key Performance Indicators) växer kanariefågeln antingen eller kollapsar och resultaten av analysen publiceras i Slack. En beskrivning och demonstration av denna process finns i materialet .
Mörka (dolda) eller A/B-distributioner
Stealth-distribution är en annan variant av kanariefågelstrategin (som Flagger för övrigt också kan arbeta med). Skillnaden mellan stealth- och kanariefågel-utbyggnader är att smyg-utbyggnader handlar om frontend snarare än backend som kanariefågel-utbyggnader.
Ett annat namn för dessa distributioner är A/B-testning. Istället för att göra den nya funktionen tillgänglig för alla användare erbjuds den endast till en begränsad del av dem. Vanligtvis är dessa användare omedvetna om att de är banbrytande testare (därav termen "stealth-deployment").
Använda funktionsbrytare (funktionsväxling) och andra verktyg kan du övervaka hur användare interagerar med den nya funktionen, om de är engagerade av den eller om de tycker att det nya användargränssnittet är förvirrande, och andra typer av mätvärden.
Flagger och A/B-distributioner
Förutom viktbaserad routing kan Flagger även dirigera trafik till kanarieservern baserat på HTTP-parametrar. I A/B-testning kan du använda HTTP-rubriker eller cookies för att rikta in dig på ett specifikt segment av användare. Detta är särskilt effektivt i fallet med frontend-applikationer som kräver sessionsbindning till servern (sessionsaffinitet). Mer information finns i Flagger-dokumentationen.
Författaren är tacksam , Weaveworks ingenjör (och skapare av Flagger), för alla dessa fantastiska distributionsmönster.
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com