🥇 Kanarie-ontplooiing in Kubernetes #1: Gitlab CI

Ons sal Gitlab CI en handleiding GitOps gebruik om Canary-ontplooiing in Kubernetes te implementeer en te gebruik

Artikels uit hierdie reeks:

(Hierdie artikel)
Kanarie-ontplooiing met behulp van ArgoCI
Kanarie-ontplooiing met behulp van Istio
Kanarie-ontplooiing met behulp van Jenkins-X Istio Flagger

Ons sal die Kanarie-ontplooiing handmatig via GitOps uitvoer en die hoof Kubernetes-hulpbronne skep/wysig. Hierdie artikel is hoofsaaklik bedoel vir inleiding met hoe ontplooiing in Kubernetes Canary werk, aangesien daar meer effektiewe metodes van outomatisering is, wat ons in die volgende artikels sal oorweeg.

https://www.norberteder.com/canary-deployment/

Kanarie-ontplooiing

Met die Kanariese strategie word opdaterings eers op slegs 'n subset van gebruikers toegepas. Deur monitering, logdata, handmatige toetsing of ander terugvoerkanale word die vrystelling getoets voordat dit aan alle gebruikers vrygestel word.

Kubernetes-ontplooiing (rollende opdatering)

Die verstekstrategie vir Kubernetes-ontplooiing is deurlopende opdatering, waar 'n sekere aantal peule met nuwe weergawes van die beelde bekendgestel word. As hulle sonder probleme geskep is, word peule met ou weergawes van beelde beëindig, en nuwe peule word parallel geskep.

GitOps

Ons gebruik GitOps in hierdie voorbeeld omdat ons:

gebruik Git as 'n enkele bron van waarheid
ons gebruik Git Operations vir bou en ontplooiing (geen bevele anders as git tag/merge is nodig nie)

Voorbeeld

Kom ons neem 'n goeie praktyk - om een bewaarplek vir toepassingskode en een vir infrastruktuur te hê.

Toepassingsbewaarplek

Dit is 'n baie eenvoudige Python+Flask API wat 'n antwoord as JSON gee. Ons sal die pakket via GitlabCI bou en die resultaat na die Gitlab-register stoot. In die register het ons twee verskillende weergawes:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Die enigste verskil tussen hulle is die verandering in die teruggestuurde JSON-lêer. Ons gebruik hierdie toepassing om so maklik as moontlik te visualiseer met watter weergawe ons kommunikeer.

Infrastruktuurbewaarplek

In hierdie raap sal ons via GitlabCI na Kubernetes ontplooi, .gitlab-ci.yml is soos volg:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

Om dit self te laat loop, sal jy 'n cluster nodig hê, jy kan Gcloud gebruik:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Jy moet vurk https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure en skep 'n veranderlike KUBECONFIG in GitlabCI, wat die konfigurasie vir toegang sal bevat kubectl na jou groepie.

U kan lees oor hoe om geloofsbriewe vir 'n groepering te kry (Gcloud) hier.

Infrastruktuur Yaml

In die infrastruktuurbewaarplek het ons diens:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

En ontplooiing in deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

En nog 'n ontplooiing in deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Let daarop dat app-ontplooiing nog geen replikas gedefinieer het nie.

Voer aanvanklike ontplooiing uit

Om die aanvanklike ontplooiing te begin, kan u die GitlabCI-pyplyn handmatig op die hooftak begin. Na dit kubectl moet die volgende uitvoer:

Ons sien app ontplooiing met 10 replikas en app-kanarie met 0. Daar is ook 'n LoadBalancer waaruit ons toegang kan kry deur curl via eksterne IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Ons sien dat ons toetstoepassing slegs "v1" terugstuur.

Voer Kanariese ontplooiing uit

Stap 1: stel 'n nuwe weergawe vir sommige gebruikers vry

Ons stel die aantal replikas op 1 in die deploy-canary.yaml lêer en die nuwe weergawe beeld:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

In lêer deploy.yaml ons het die aantal replikas verander na 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Ons stoot hierdie veranderinge na die bewaarplek vanwaar die ontplooiing sal begin (via GitlabCI) en sien as gevolg daarvan:

Ons diens sal na beide ontplooiings verwys, aangesien albei die toepassingkieser het. As gevolg van Kubernetes se verstek ewekansigheid, behoort ons verskillende antwoorde vir ~10% van versoeke te sien:

Die huidige toestand van ons toepassing (GitOps, geneem uit Git as 'n enkele bron van waarheid) is die teenwoordigheid van twee ontplooiings met aktiewe replikas, een vir elke weergawe.

~10% van gebruikers raak vertroud met 'n nuwe weergawe en toets dit onbedoeld. Dit is nou die tyd om te kyk vir foute in die logs en moniteringsdata om probleme op te spoor.

Stap 2: Stel die nuwe weergawe vry aan alle gebruikers

Ons het besluit dat alles goed verloop en nou moet ons die nuwe weergawe aan alle gebruikers bekend stel. Om dit te doen, werk ons eenvoudig op deploy.yaml die installering van 'n nuwe weergawe van die beeld en die aantal replikas gelyk aan 10. In deploy-canary.yaml ons stel die aantal replikas terug na 0. Na ontplooiing sal die resultaat soos volg wees:

Opsomming

Vir my help dit om die implementering met die hand op hierdie manier te laat verstaan hoe maklik dit gekonfigureer kan word met behulp van k8s. Aangesien Kubernetes jou toelaat om alles via 'n API op te dateer, kan hierdie stappe deur middel van skrifte geoutomatiseer word.

Nog iets wat geïmplementeer moet word, is 'n toetser-ingangspunt (LoadBalancer of via Ingress) waardeur slegs toegang tot die nuwe weergawe verkry kan word. Dit kan gebruik word vir handmatige blaai.

In toekomstige artikels sal ons na ander outomatiese oplossings kyk wat die meeste van wat ons gedoen het implementeer.

Lees ook ander artikels op ons blog:

Bron: will.com

Kanarie-ontplooiing in Kubernetes #1: Gitlab CI