🥇Pengedaran Canary dalam Kubernetes #2: Pelancaran Argo

Kami akan menggunakan pengawal penempatan Argo Rollouts asli k8s dan GitlabCI untuk menjalankan penempatan Canary kepada Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikel dalam siri ini

Penggunaan Canary dalam Kubernetes #1: Gitlab CI
(Artikel ini)
Deployment Canary menggunakan Istio
Penggunaan Canary menggunakan Jenkins-X Istio Flagger

Penggunaan Canary

Kami harap anda membaca bahagian pertama, di mana kami menerangkan secara ringkas apa itu Canary Deployments. Kami juga menunjukkan cara untuk melaksanakannya menggunakan sumber Kubernetes standard.

Pelancaran Argo

Argo Rollouts ialah pengawal penggunaan asli Kubernetes. Ia menyediakan CRD (Definisi Sumber Tersuai) untuk Kubernetes. Terima kasih kepadanya, kami boleh menggunakan entiti baharu: Rollout, yang menguruskan penggunaan biru-hijau dan kenari dengan pelbagai pilihan konfigurasi.

Pengawal Argo Rollouts yang digunakan oleh sumber tersuai Rollout, Membenarkan strategi penggunaan tambahan seperti biru-hijau dan kenari untuk Kubernetes. Sumber Rollout menyediakan fungsi yang setara Deployment, hanya dengan strategi penggunaan tambahan.
sumber Deployments mempunyai dua strategi untuk penempatan: RollingUpdate и Recreate. Walaupun strategi ini sesuai untuk kebanyakan kes, untuk penempatan ke pelayan pada skala yang sangat besar, strategi tambahan digunakan, seperti biru-hijau atau kenari, yang tidak tersedia dalam pengawal Deployment. Untuk menggunakan strategi ini dalam Kubernetes, pengguna perlu menulis skrip di atas Deployment mereka. Pengawal Argo Rollouts mendedahkan strategi ini sebagai parameter yang mudah, deklaratif dan boleh dikonfigurasikan.
https://argoproj.github.io/argo-rollouts

Terdapat juga Argo CI, yang menyediakan antara muka web yang mudah untuk digunakan dengan Pelancaran, kami akan melihatnya dalam artikel seterusnya.

Memasang Argo Rollouts

Bahagian pelayan

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

Dalam lobak infrastruktur kami (lihat di bawah) kami telah menambah install.yaml sebagai i/k8s/argo-rollouts/install.yaml. Dengan cara ini GitlabCI akan memasangnya ke dalam kelompok.

Bahagian pelanggan (pemalam kubectl)

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

Contoh Permohonan

Adalah amalan yang baik untuk mempunyai repositori berasingan untuk kod dan infrastruktur aplikasi.

Repositori untuk aplikasi

Kim Wuestkamp/k8s-deployment-example-app

Ini adalah API Python+Flask yang sangat mudah yang mengembalikan respons sebagai JSON. Kami akan membina pakej menggunakan 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 fail JSON yang dikembalikan. Kami menggunakan aplikasi ini untuk menggambarkan semudah mungkin versi yang kami berkomunikasi.

Repositori infrastruktur

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

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

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.

ia adalah Anda boleh membaca tentang cara mendapatkan bukti kelayakan untuk kluster (Gcloud).

Infrastruktur Yaml

Di dalam repositori infrastruktur kami mempunyai perkhidmatan:

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

dan 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 berfungsi sama seperti Deployment. Jika kami tidak menetapkan strategi kemas kini (seperti kenari di sini) ia akan berkelakuan seperti Deployment kemas kini rolling lalai.

Kami mentakrifkan dua langkah dalam yaml untuk penggunaan kenari:

10% daripada trafik ke kenari (tunggu manual OK)
50% trafik ke kenari (tunggu 2 minit kemudian teruskan ke 100%)

Melaksanakan penempatan awal

Selepas penggunaan awal, sumber kami akan kelihatan seperti ini:

Dan kami mendapat respons hanya daripada versi pertama aplikasi:

Melakukan Deployment Canary

Langkah 1: 10% trafik

Untuk memulakan penggunaan kenari, kita hanya perlu menukar versi imej seperti yang biasa kita lakukan dengan penempatan:

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

Dan kami menolak perubahan, jadi Gitlab CI menggunakan dan kami melihat perubahannya:

Sekarang jika kita mengakses perkhidmatan:

Hebat! Kami berada di tengah-tengah penyebaran kenari kami. Kita boleh melihat kemajuan dengan menjalankan:

kubectl argo rollouts get rollout rollout-canary

Langkah 2: 50% trafik:

Sekarang mari kita beralih ke langkah seterusnya: mengubah hala 50% daripada trafik. Kami mengkonfigurasi langkah ini untuk dijalankan secara manual:

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

Dan aplikasi kami mengembalikan 50% daripada respons daripada versi baharu:

Dan semakan pelancaran:

Hebat.

Langkah 3: 100% trafik:

Kami menyediakannya supaya selepas 2 minit langkah 50% tamat secara automatik dan langkah 100% bermula:

Dan output aplikasi:

Dan semakan pelancaran:

Pengerahan Canary selesai.

Lebih banyak contoh dengan Argo Rollouts

Terdapat lebih banyak contoh di sini, seperti cara menyediakan pratonton persekitaran dan perbandingan berdasarkan kanari:

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

Video tentang Argo Rollouts dan Argo CI

Saya sangat mengesyorkan video ini, ia menunjukkan cara Argo Rollouts dan Argo CI berfungsi bersama:

Jumlah

Saya sangat menyukai idea menggunakan CRD yang menguruskan penciptaan jenis penempatan atau replika tambahan, mengubah hala lalu lintas, dsb. Bekerja dengan mereka berjalan lancar. Seterusnya saya ingin menguji integrasi dengan Argo CI.

Walau bagaimanapun, nampaknya terdapat penggabungan besar Argo CI dan Flux CI akan datang, jadi saya mungkin menunggu sehingga keluaran baharu keluar: Argo Flux.

Adakah anda mempunyai pengalaman dengan Argo Rollouts atau Argo CI?

Penggunaan Canary dalam Kubernetes #2: Pelancaran Argo