Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Ni uzos la k8s-denaskan Argo Rollouts deplojregilon kaj GitlabCI por ruli Kanariajn deplojojn al Kubernetes

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

https://unsplash.com/photos/V41PulGL1z0

Artikoloj en ĉi tiu serio

Kanaria Deplojo

Ni esperas, ke vi legas unua parto, kie ni mallonge klarigis kio estas Kanariaj Deplojoj. Ni ankaŭ montris kiel efektivigi ĝin uzante normajn rimedojn de Kubernetes.

Argo-Elvolviĝoj

Argo Rollouts estas denaska deplojregilo de Kubernetes. Ĝi provizas CRD (Persona Rimeda Difino) por Kubernetes. Danke al ĝi, ni povas uzi novan enton: Rollout, kiu administras bluverdajn kaj kanariajn deplojojn kun diversaj agordaj elektoj.

Argo Rollouts-regilo uzata de kutima rimedo Rollout, Ebligas pliajn deplojajn strategiojn kiel bluverda kaj kanaria por Kubernetes. Rimedo Rollout provizas ekvivalentan funkciecon Deployment, nur kun kromaj deplojstrategioj.
rimedo Deployments havas du strategiojn por deplojo: RollingUpdate и Recreate. Kvankam ĉi tiuj strategioj taŭgas por la plej multaj kazoj, por deplojo al serviloj sur tre granda skalo, kromaj strategioj estas uzataj, kiel bluverda aŭ kanaria, kiuj ne estas disponeblaj en la Deploja regilo. Por uzi ĉi tiujn strategiojn en Kubernetes, uzantoj devis skribi skriptojn aldone al siaj Deplojoj. La Argo Rollouts Controller elmontras ĉi tiujn strategiojn kiel simplajn, deklarajn, agordeblajn parametrojn.
https://argoproj.github.io/argo-rollouts

Ankaŭ ekzistas Argo CI, kiu disponigas oportunan interfacon por uzi kun Rollouts, ni rigardos tion en la sekva artikolo.

Instalado de Argo Rollouts

Servila flanko

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

En nia infrastruktura napo (vidu sube) ni jam aldonis install.yaml kiel i/k8s/argo-rollouts/install.yaml. Tiel GitlabCI instalos ĝin en la areton.

Klienta flanko (kubectl kromaĵo)

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

Ekzempla Apliko

Estas bona praktiko havi apartajn deponejojn por aplika kodo kaj infrastrukturo.

Deponejo por la aplikaĵo

Kim Wuestkamp/k8s-deployment-example-app

Ĉi tio estas tre simpla Python+Flask API, kiu resendas respondon kiel JSON. Ni konstruos la pakaĵon uzante GitlabCI kaj puŝos la rezulton al la Gitlab-Registro. En la registro ni havas du malsamajn eldonversiojn:

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

La nura diferenco inter ili estas la JSON-dosiero resendita. Ni uzas ĉi tiun aplikaĵon por vidi kiel eble plej facile, kun kiu versio ni komunikas.

Infrastruktura deponejo

En ĉi tiu deponejo ni uzos GitlabCI por deplojo al Kubernetes, .gitlab-ci.yml aspektas jene:

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

Por ruli ĝin mem vi bezonos grapolon, vi povas uzi Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Vi devas forkiĝi https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure kaj kreu variablon KUBECONFIG en GitlabCI, kiu enhavos la agordon por aliro kubectl al via areto.

estas Vi povas legi pri kiel akiri akreditaĵojn por areto (Gcloud).

Infrastrukturo Yaml

Ene de la infrastruktura deponejo ni havas servon:

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

kaj rollout.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 funkcias same kiel Deployment. Se ni ne fiksas ĝisdatigan strategion (kiel kanario ĉi tie) ĝi kondutos kiel la defaŭlta ruliĝanta-ĝisdatigo Deplojo.

Ni difinas du paŝojn en yaml por kanaria deplojo:

  1. 10% de trafiko al kanario (atendu manlibron OK)
  2. 50% trafiko al kanario (atendu 2 minutojn poste daŭrigu al 100%)

Farante komencan deplojon

Post la komenca deplojo, niaj rimedoj aspektos jene:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kaj ni ricevas respondon nur de la unua versio de la aplikaĵo:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Farante Kanarian Deplojon

Paŝo 1: 10% trafiko

Por komenci kanarian deplojon, ni nur bezonas ŝanĝi la bildoversion kiel ni kutime faras kun deplojoj:

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
...

Kaj ni puŝas ŝanĝojn, do Gitlab CI efektivigas kaj ni vidas la ŝanĝojn:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Nun se ni aliras la servon:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Bonege! Ni estas en la mezo de nia kanaria deplojo. Ni povas vidi la progreson kurante:

kubectl argo rollouts get rollout rollout-canary

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Paŝo 2: 50% trafiko:

Nun ni transiru al la sekva paŝo: redirekti 50% de la trafiko. Ni agordis ĉi tiun paŝon por ruliĝi permane:

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

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kaj nia aplikaĵo resendis 50% de la respondoj de novaj versioj:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kaj revizio pri lanĉado:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Mirinda.

Paŝo 3: 100% trafiko:

Ni aranĝas ĝin tiel ke post 2 minutoj la 50% paŝo finiĝas aŭtomate kaj la 100% paŝo komenciĝas:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kaj la aplikaĵa eligo:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kaj revizio pri lanĉado:

Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado

Kanaria deplojo estas kompleta.

Pli da ekzemploj kun Argo Rollouts

Estas pli da ekzemploj ĉi tie, kiel kiel agordi antaŭrigardojn kaj komparojn de medio surbaze de kanario:

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

Video pri Argo Rollouts kaj Argo CI

Mi vere rekomendas ĉi tiun videon, ĝi montras kiel Argo Rollouts kaj Argo CI funkcias kune:

La rezulto

Mi tre ŝatas la ideon uzi CRD-ojn, kiuj administras la kreadon de pliaj specoj de deplojoj aŭ kopiaroj, alidirektas trafikon ktp. Labori kun ili iras glate. Poste mi ŝatus testi la integriĝon kun Argo CI.

Tamen, ŝajnas esti granda fuzio de Argo CI kaj Flux CI venanta, do mi eble atendas ĝis la nova eldono aperos: Argo Flukso.

Ĉu vi havis sperton kun Argo Rollouts aŭ Argo CI?

Legu ankaŭ aliajn artikolojn en nia blogo:

fonto: www.habr.com

Aldoni komenton