🥇 Kanarie-ontplooiing in Kubernetes #2: Argo-ontplooiings

Ons sal die k8s-inheemse Argo Rollouts-ontplooiingsbeheerder en GitlabCI gebruik om Kanariese ontplooiings na Kubernetes te laat loop

https://unsplash.com/photos/V41PulGL1z0

Artikels in hierdie reeks

Kanarie-ontplooiing in Kubernetes #1: Gitlab CI
(Hierdie artikel)
Kanarie-ontplooiing met behulp van Istio
Kanarie-ontplooiing met behulp van Jenkins-X Istio Flagger

Kanarie-ontplooiing

Ons hoop jy lees eerste deel, waar ons kortliks verduidelik het wat Canary Deployments is. Ons het ook gewys hoe om dit te implementeer met behulp van standaard Kubernetes-hulpbronne.

Argo-ontplooiings

Argo Rollouts is 'n Kubernetes-inheemse ontplooiingsbeheerder. Dit verskaf 'n CRD (Custom Resource Definition) vir Kubernetes. Danksy dit kan ons 'n nuwe entiteit gebruik: Rollout, wat blougroen en kanarie-ontplooiings bestuur met verskeie konfigurasie-opsies.

Argo-uitrolbeheerder wat deur 'n pasgemaakte hulpbron gebruik word Rollout, Maak voorsiening vir bykomende ontplooiingstrategieë soos blougroen en kanarie vir Kubernetes. Hulpbron Rollout bied funksionaliteit ekwivalent Deployment, slegs met bykomende ontplooiingstrategieë.
hulpbron Deployments het twee strategieë vir ontplooiing: RollingUpdate и Recreate. Alhoewel hierdie strategieë vir die meeste gevalle geskik is, word addisionele strategieë gebruik vir ontplooiing na bedieners op 'n baie groot skaal, soos blougroen of kanarie, wat nie in die Ontplooiingsbeheerder beskikbaar is nie. Om hierdie strategieë in Kubernetes te gebruik, moes gebruikers skrifte bo-op hul Ontplooiings skryf. Die Argo-uitrolbeheerder stel hierdie strategieë bloot as eenvoudige, verklarende, konfigureerbare parameters.
https://argoproj.github.io/argo-rollouts

Daar is ook Argo CI, wat 'n gerieflike webkoppelvlak bied vir gebruik met ontplooiings, ons sal daarna in die volgende artikel kyk.

Installeer Argo Rollouts

Bedienerkant

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

In ons infrastruktuurraap (sien hieronder) het ons reeds install.yaml bygevoeg as i/k8s/argo-rollouts/install.yaml. Op hierdie manier sal GitlabCI dit in die groep installeer.

Kliëntkant (kubectl-inprop)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Voorbeeld Toepassing

Dit is goeie praktyk om aparte bewaarplekke vir toepassingskode en infrastruktuur te hê.

Bewaarplek vir die toepassing

Kim Wuestkamp/k8s-deployment-example-app

Dit is 'n baie eenvoudige Python+Flask API wat 'n antwoord as JSON gee. Ons sal die pakket met 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 JSON-lêer wat teruggestuur word. Ons gebruik hierdie toepassing om so maklik as moontlik te visualiseer met watter weergawe ons kommunikeer.

Infrastruktuurbewaarplek

In hierdie bewaarplek sal ons GitlabCI gebruik vir ontplooiing na Kubernetes, .gitlab-ci.yml lyk soos volg:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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.

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

Infrastruktuur Yaml

Binne die infrastruktuurbewaarplek het ons diens:

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

en uitrol.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout werk dieselfde as Ontplooiing. As ons nie 'n opdateringstrategie (soos kanarie hier) stel nie, sal dit optree soos die verstek-rollende opdatering-ontplooiing.

Ons definieer twee stappe in yaml vir kanarie-ontplooiing:

10% van die verkeer na kanarie (wag vir handleiding OK)
50% verkeer na kanarie (wag 2 minute en gaan dan voort na 100%)

Voer aanvanklike ontplooiing uit

Na die aanvanklike ontplooiing sal ons hulpbronne soos volg lyk:

En ons kry slegs 'n antwoord vanaf die eerste weergawe van die toepassing:

Voer Kanarie-ontplooiing uit

Stap 1: 10% verkeer

Om 'n kanarie-ontplooiing te begin, moet ons net die beeldweergawe verander soos ons gewoonlik met ontplooiings doen:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

En ons druk veranderinge, so Gitlab CI ontplooi en ons sien die veranderinge:

As ons nou toegang tot die diens kry:

Puik! Ons is in die middel van ons kanarie-ontplooiing. Ons kan die vordering sien deur te hardloop:

kubectl argo rollouts get rollout rollout-canary

Stap 2: 50% verkeer:

Kom ons gaan nou aan na die volgende stap: herlei 50% van die verkeer. Ons het hierdie stap gekonfigureer om handmatig uitgevoer te word:

kubectl argo rollouts promote rollout-canary # continue to step 2

En ons toepassing het 50% van die antwoorde van nuwe weergawes teruggestuur:

En ontplooiingsoorsig:

Wonderlik.

Stap 3: 100% verkeer:

Ons stel dit so op dat die 2%-stap na 50 minute outomaties eindig en die 100%-stap begin:

En die toepassingsuitset:

En ontplooiingsoorsig:

Kanarie-ontplooiing is voltooi.

Meer voorbeelde met Argo-uitrol

Daar is meer voorbeelde hier, soos hoe om omgewingsvoorskoue en vergelykings op te stel op grond van kanarie:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Video oor Argo-uitrol en Argo CI

Ek beveel hierdie video regtig aan, dit wys hoe Argo Rollouts en Argo CI saamwerk:

Totale

Ek hou baie van die idee om CRD's te gebruik wat die skep van bykomende tipes ontplooiings of replikasets bestuur, verkeer herlei, ens. Werk met hulle verloop glad. Volgende wil ek die integrasie met Argo CI toets.

Dit blyk egter dat daar 'n groot samesmelting van Argo CI en Flux CI kom, so ek kan wag totdat die nuwe vrystelling uitkom: Argo Flux.

Het jy enige ervaring met Argo Rollouts of Argo CI gehad?

Lees ook ander artikels op ons blog:

Bron: will.com

Kanarie-ontplooiing in Kubernetes #2: Argo-ontplooiing