🥇Kanári bevezetés a Kubernetes #1-ben: Gitlab CI

Gitlab CI-t és kézi GitOps-t fogunk használni a Canary-telepítés megvalósításához és használatához a Kubernetesben

Cikkek ebből a sorozatból:

(Ez a cikk)
Canary Deployment az ArgoCI használatával
Canary Deployment az Istio segítségével
Kanári bevetés a Jenkins-X Istio Flagger használatával

A Canary telepítését manuálisan hajtjuk végre a GitOps-on keresztül, és létrehozzuk/módosítjuk a fő Kubernetes-erőforrásokat. Ez a cikk elsősorban a bevezetést szolgálja hogyan működik a telepítés a Kubernetes Canary-ban, mivel vannak hatékonyabb automatizálási módszerek, amelyeket a következő cikkekben tárgyalunk.

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

Kanári bevetés

A Canary-stratégia esetében a frissítések először csak a felhasználók egy részére vonatkoznak. Felügyelet, naplózási adatok, kézi tesztelés vagy más visszacsatolási csatornák révén a kiadás tesztelésre kerül, mielőtt az összes felhasználó számára elérhetővé válik.

Kubernetes telepítés (folyamatos frissítés)

A Kubernetes Deployment alapértelmezett stratégiája a gördülő frissítés, ahol bizonyos számú pod-ok indulnak el a képek új verzióival. Ha probléma nélkül hozták létre, akkor a képek régi verzióival rendelkező sorba rendezések megszűnnek, és ezzel párhuzamosan új sorba rendezések jönnek létre.

GitOps

Ebben a példában GitOpsot használunk, mert:

a Git az igazság egyetlen forrásaként használva
Git Operations-t használunk a felépítéshez és a telepítéshez (nincs szükség más parancsokra, mint a git tag/merge)

Példa

Vegyünk egy jó gyakorlatot – legyen egy tárhely az alkalmazáskódhoz és egy az infrastruktúra számára.

Alkalmazástár

Ez egy nagyon egyszerű Python+Flask API, amely JSON-ként ad vissza választ. A csomagot a GitlabCI-n keresztül készítjük, és az eredményt a Gitlab Registry-be küldjük. A rendszerleíró adatbázisban két különböző kiadási verzió található:

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

Az egyetlen különbség köztük a visszaadott JSON-fájl változása. Ezzel az alkalmazással a lehető legegyszerűbben vizualizáljuk, hogy melyik verzióval kommunikálunk.

Infrastruktúra adattár

Ebben a fehérrépában GitlabCI-n keresztül telepítjük a Kubernetesre, .gitlab-ci.yml a következő:

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

A saját maga futtatásához szüksége lesz egy fürtre, használhatja a Gcloudot:

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

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

El kell villázni https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure és hozzon létre egy változót KUBECONFIG a GitlabCI-ben, amely tartalmazza a hozzáféréshez szükséges konfigurációt kubectl a klaszteredhez.

Itt olvashat arról, hogyan szerezhet be hitelesítési adatokat egy fürthöz (Gcloud) itt.

Infrastruktúra Yaml

Az infrastruktúra adattárban a következő szolgáltatásaink vannak:

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

És bevetés 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

És egy újabb bevetés 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

Vegye figyelembe, hogy az app-deploy még nem rendelkezik replikákkal.

Kezdeti telepítés végrehajtása

A kezdeti üzembe helyezés elindításához manuálisan elindíthatja a GitlabCI folyamatot a fő ágon. Azt követően kubectl a következőket kell kiadnia:

Látjuk app telepítés 10 replikával és app-canary 0-val. Van egy LoadBalancer is, ahonnan elérhetjük curl Külső IP-n keresztül:

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

Látjuk, hogy tesztalkalmazásunk csak „v1”-et ad vissza.

Kanári bevetés végrehajtása

1. lépés: Adjon ki új verziót egyes felhasználók számára

A replikák számát 1-re állítottuk a deploy-canary.yaml fájlban és az új verziójú képben:

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

Fájlban deploy.yaml a replikák számát 9-re változtattuk:

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

Ezeket a változtatásokat áthelyezzük abba a tárolóba, ahonnan a központi telepítés elindul (a GitlabCI-n keresztül), és ennek eredménye:

Szolgáltatásunk mindkét telepítésre mutat, mivel mindkettő rendelkezik alkalmazásválasztóval. A Kubernetes alapértelmezett véletlenszerűsítése miatt a kérések ~10%-ára eltérő válaszokat kell látnunk:

Alkalmazásunk (GitOps, a Git mint egyetlen igazságforrásból átvett) jelenlegi állapota két központi telepítés jelenléte aktív replikákkal, mindegyik verzióhoz egy.

A felhasználók ~10%-a megismeri az új verziót, és akaratlanul is teszteli. Itt az ideje, hogy ellenőrizze a hibákat a naplókban és a megfigyelési adatokban, hogy megtalálja a problémákat.

2. lépés: Az új verzió kiadása minden felhasználó számára

Úgy döntöttünk, hogy minden jól ment, és most minden felhasználó számára ki kell terjesztenünk az új verziót. Ehhez egyszerűen frissítjük deploy.yaml a kép új verziójának telepítése és a replikák száma 10. In deploy-canary.yaml a replikák számát visszaállítjuk 0-ra. A telepítés után az eredmény a következő lesz:

Összefoglalva

Számomra a telepítés kézi futtatása így segít megérteni, milyen könnyen konfigurálható a k8s használatával. Mivel a Kubernetes lehetővé teszi, hogy mindent API-n keresztül frissítsen, ezek a lépések szkripteken keresztül automatizálhatók.

Egy másik dolog, amit implementálni kell, egy tesztelő belépési pont (LoadBalancer vagy Ingressen keresztül), amelyen keresztül csak az új verzió érhető el. Kézi böngészéshez használható.

A jövőbeli cikkeinkben más automatizált megoldásokat is megvizsgálunk, amelyek megvalósítják a legtöbbet.

Olvassa el blogunk további cikkeit is:

Forrás: will.com

Kanári telepítés Kubernetes #1-ben: Gitlab CI