🥇Pengedaran Canary dalam Kubernetes #1: Gitlab CI

Kami akan menggunakan Gitlab CI dan GitOps manual untuk melaksanakan dan menggunakan penggunaan Canary dalam Kubernetes

Artikel daripada siri ini:

(Artikel ini)
Deployment Canary menggunakan ArgoCI
Deployment Canary menggunakan Istio
Penggunaan Canary menggunakan Jenkins-X Istio Flagger

Kami akan melaksanakan penggunaan Canary secara manual melalui GitOps dan mencipta/mengubah suai sumber Kubernetes utama. Artikel ini bertujuan terutamanya untuk pengenalan dengan cara penggunaan berfungsi dalam Kubernetes Canary, kerana terdapat kaedah automasi yang lebih berkesan, yang akan kami pertimbangkan dalam artikel berikut.

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

Penggunaan Canary

Dengan strategi Canary, kemas kini pertama kali digunakan pada subset pengguna sahaja. Melalui pemantauan, data log, ujian manual atau saluran maklum balas lain, keluaran diuji sebelum dikeluarkan kepada semua pengguna.

Penggunaan Kubernetes (kemas kini bergulir)

Strategi lalai untuk Kubernetes Deployment ialah rolling-update, di mana beberapa pod tertentu dilancarkan dengan versi baharu imej. Jika ia dicipta tanpa masalah, pod dengan versi imej lama akan ditamatkan dan pod baharu dibuat selari.

GitOps

Kami menggunakan GitOps dalam contoh ini kerana kami:

menggunakan Git sebagai satu sumber kebenaran
kami menggunakan Operasi Git untuk membina dan menggunakan (tiada arahan selain git tag/merge diperlukan)

Contoh

Mari kita amalkan amalan yang baik - untuk mempunyai satu repositori untuk kod aplikasi dan satu untuk infrastruktur.

Repositori aplikasi

Ini adalah API Python+Flask yang sangat mudah yang mengembalikan respons sebagai JSON. Kami akan membina pakej melalui GitlabCI dan menolak hasilnya ke Pendaftaran Gitlab. Dalam pendaftaran kami mempunyai dua versi keluaran yang berbeza:

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

Satu-satunya perbezaan di antara mereka ialah perubahan dalam fail JSON yang dikembalikan. Kami menggunakan aplikasi ini untuk menggambarkan semudah mungkin versi yang kami berkomunikasi.

Repositori infrastruktur

Dalam lobak ini kami akan menggunakan GitlabCI ke Kubernetes, .gitlab-ci.yml kelihatan seperti ini:

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

Untuk menjalankannya sendiri, anda memerlukan kluster, anda boleh menggunakan Gcloud:

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

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

Anda perlu garpu https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dan buat pembolehubah KUBECONFIG dalam GitlabCI, yang akan mengandungi konfigurasi untuk akses kubectl kepada kluster anda.

Anda boleh membaca tentang cara mendapatkan bukti kelayakan untuk kluster (Gcloud) di sini.

Infrastruktur Yaml

Dalam repositori infrastruktur kami mempunyai perkhidmatan:

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

Dan penempatan dalam 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

Dan satu lagi penempatan dalam 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

Ambil perhatian bahawa aplikasi-deploy tidak mempunyai sebarang replika yang ditentukan lagi.

Melaksanakan penempatan awal

Untuk memulakan penggunaan awal, anda boleh memulakan saluran paip GitlabCI secara manual pada cawangan induk. Selepas itu kubectl harus mengeluarkan yang berikut:

Kita lihat app penempatan dengan 10 replika dan kenari aplikasi dengan 0. Terdapat juga LoadBalancer yang boleh kita akses melalui curl melalui IP Luaran:

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

Kami melihat bahawa aplikasi ujian kami hanya mengembalikan "v1".

Melaksanakan penggunaan Canary

Langkah 1: keluarkan versi baharu untuk sesetengah pengguna

Kami menetapkan bilangan replika kepada 1 dalam fail deploy-canary.yaml dan imej versi baharu:

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

Dalam fail deploy.yaml kami menukar bilangan replika kepada 9:

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

Kami menolak perubahan ini ke repositori dari mana penggunaan akan bermula (melalui GitlabCI) dan lihat hasilnya:

Perkhidmatan kami akan menunjuk kepada kedua-dua penempatan, kerana kedua-duanya mempunyai pemilih apl. Disebabkan oleh rawak lalai Kubernetes, kita sepatutnya melihat respons yang berbeza untuk ~10% permintaan:

Keadaan semasa aplikasi kami (GitOps, diambil daripada Git sebagai Satu Sumber Kebenaran) ialah kehadiran dua penempatan dengan replika aktif, satu untuk setiap versi.

~10% pengguna menjadi biasa dengan versi baharu dan mengujinya secara tidak sengaja. Sekarang adalah masa untuk menyemak ralat dalam log dan data pemantauan untuk mencari masalah.

Langkah 2: Keluarkan versi baharu kepada semua pengguna

Kami memutuskan bahawa semuanya berjalan lancar dan kini kami perlu melancarkan versi baharu kepada semua pengguna. Untuk melakukan ini, kami hanya mengemas kini deploy.yaml memasang versi baharu imej dan bilangan replika bersamaan dengan 10. Dalam deploy-canary.yaml kami menetapkan bilangan replika kembali kepada 0. Selepas penggunaan, hasilnya adalah seperti berikut:

Merumuskan

Bagi saya, menjalankan penggunaan secara manual dengan cara ini membantu memahami betapa mudahnya ia boleh dikonfigurasikan menggunakan k8s. Memandangkan Kubernetes membenarkan anda mengemas kini segala-galanya melalui API, langkah-langkah ini boleh diautomasikan melalui skrip.

Perkara lain yang perlu dilaksanakan ialah titik masuk penguji (LoadBalancer atau melalui Ingress) yang melaluinya hanya versi baharu boleh diakses. Ia boleh digunakan untuk menyemak imbas manual.

Dalam artikel akan datang, kami akan menyemak penyelesaian automatik lain yang melaksanakan kebanyakan perkara yang telah kami lakukan.

Penggunaan Canary dalam Kubernetes #1: Gitlab CI