Canary-distribution är ett mycket effektivt sätt att testa ny kod på en undergrupp av användare. Det minskar avsevärt trafikbelastningen som kan vara problematisk under driftsättningsprocessen, eftersom den bara förekommer inom en viss undergrupp. Den här anteckningen handlar om hur man organiserar en sådan distribution med Kubernetes och distributionsautomatisering. Detta förutsätter att du har viss kunskap om Helm och Kubernetes resurser..
En enkel kanarie-distribution till Kubernetes inkluderar två nyckelresurser: själva tjänsten och distributionsverktyget. Canary-distribution fungerar genom en enda tjänst som kommunicerar med två olika resurser som betjänar uppdateringstrafik. En av dessa resurser kommer att fungera med versionen "kanariefågel" och den andra - med den stabila. I den här situationen kan vi justera antalet kanariefågelversioner för att minska mängden trafik som krävs för underhåll. Om du till exempel föredrar att använda Yaml, så skulle det se ut så här i Kubernetes:
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Selector will route traffic to both deployments.
Det är ännu lättare att föreställa sig ett sådant alternativ på kubectl och in
Canary Deployment Automation
Först och främst behöver vi en Helm-karta, som redan innehåller resurserna som diskuterats ovan. Det borde se ut ungefär så här:
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Grunden för Helm-konceptet är hanteringen av multiversionsutgåvor. Den stabila versionen är vår huvudsakliga stabila kodgren för projektet. Men med hjälp av Helm kan vi distribuera kanariefågeln med vår experimentella kod. Huvudsaken är att behålla trafikutbytet mellan den stabila versionen och Canary-releasen. Vi kommer att hantera allt detta med hjälp av en speciell väljare:
selector:
app.kubernetes.io/name: myapp
Våra både "canary" och stabila distributionsresurser kommer att ange denna etikett på modulerna. Om allt är korrekt konfigurerat kommer vi att se att trafiken kommer att dirigeras till de nyligen utplacerade modulerna under distributionen av kanariefågelversionen av vår Helm-karta. Den stabila versionen av detta kommando skulle se ut så här:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v1 # Goes into app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5
Låt oss nu kolla in vår kanariefågel release. För att distribuera kanariefågelversionen måste vi komma ihåg två saker. Namnet på releasen måste vara annorlunda så att vi inte uppdaterar den nuvarande stabila versionen. Versionen och taggen måste också vara olika så att vi kan distribuera annan kod och identifiera skillnader i resurstaggar.
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v2 # Goes into app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1
Det är faktiskt allt! Om du plingar tjänsten kan du se att kanariefågeluppdateringen bara dirigerar trafik en del av tiden.
Om du letar efter automatiseringsverktyg för distribution som inkluderar den beskrivna logiken, ta en titt på
Källa: will.com