🥇Penerapan Canary di Kubernetes #1: Gitlab CI

Kami akan menggunakan Gitlab CI dan GitOps manual untuk mengimplementasikan dan menggunakan penerapan Canary di Kubernetes

Artikel dari seri ini:

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

Kami akan melakukan penerapan Canary secara manual melalui GitOps dan membuat/memodifikasi sumber daya utama Kubernetes. Artikel ini ditujukan terutama untuk pengenalan dengan cara kerja penerapan di Kubernetes Canary, karena ada metode otomatisasi yang lebih efektif, yang akan kita bahas di artikel berikut.

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

Penyebaran Canary

Dengan strategi Canary, pembaruan pertama kali diterapkan hanya pada sebagian pengguna saja. Melalui pemantauan, data log, pengujian manual, atau saluran umpan balik lainnya, rilis diuji sebelum dirilis ke semua pengguna.

Penerapan Kubernetes (pembaruan berkelanjutan)

Strategi default untuk Penerapan Kubernetes adalah pembaruan berkelanjutan, di mana sejumlah pod diluncurkan dengan versi image baru. Jika pod tersebut dibuat tanpa masalah, pod dengan image versi lama akan dihentikan, dan pod baru akan dibuat secara paralel.

GitOps

Kami menggunakan GitOps dalam contoh ini karena kami:

menggunakan Git sebagai satu-satunya sumber kebenaran
kami menggunakan Operasi Git untuk pembuatan dan penerapan (tidak diperlukan perintah selain git tag/merge)

Contoh

Mari kita praktikkan dengan baik - memiliki satu repositori untuk kode aplikasi dan satu lagi untuk infrastruktur.

Repositori aplikasi

Ini adalah API Python+Flask yang sangat sederhana yang mengembalikan respons sebagai JSON. Kami akan membangun paket melalui GitlabCI dan memasukkan hasilnya ke Gitlab Registry. Di registri kami memiliki dua versi rilis berbeda:

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

Satu-satunya perbedaan di antara keduanya adalah perubahan pada file JSON yang dikembalikan. Kami menggunakan aplikasi ini untuk memvisualisasikan semudah mungkin dengan versi mana kami berkomunikasi.

Repositori infrastruktur

Di lobak ini kami akan menyebarkan melalui GitlabCI ke Kubernetes, .gitlab-ci.yml adalah sebagai berikut:

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 cluster, Anda dapat 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 bercabang https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dan membuat variabel KUBECONFIG di GitlabCI, yang akan berisi konfigurasi untuk akses kubectl ke klaster Anda.

Anda dapat membaca tentang cara mendapatkan kredensial untuk sebuah cluster (Gcloud) di sini.

Infrastruktur Yaml

Di repositori infrastruktur kami memiliki layanan:

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 di 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 penerapan lainnya 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

Perhatikan bahwa penerapan aplikasi belum menentukan replika apa pun.

Melakukan penerapan awal

Untuk memulai penerapan awal, Anda dapat memulai pipeline GitlabCI secara manual di cabang master. Setelah itu kubectl harus menampilkan yang berikut:

Kami melihat app penerapan dengan 10 replika dan app-canary dengan 0. Ada juga LoadBalancer yang dapat kita akses melalui curl melalui IP Eksternal:

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

Kami melihat bahwa aplikasi pengujian kami hanya mengembalikan "v1".

Menjalankan penerapan Canary

Langkah 1: rilis versi baru untuk beberapa pengguna

Kami menetapkan jumlah replika ke 1 di file deploy-canary.yaml dan gambar versi baru:

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 file deploy.yaml kami mengubah jumlah replika menjadi 9:

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

Kami memasukkan perubahan ini ke repositori tempat penerapan akan dimulai (melalui GitlabCI) dan melihat hasilnya:

Layanan kami akan mengarah ke kedua penerapan, karena keduanya memiliki pemilih aplikasi. Karena pengacakan default Kubernetes, kita akan melihat respons berbeda untuk ~10% permintaan:

Keadaan aplikasi kita saat ini (GitOps, diambil dari Git sebagai Single Source Of Truth) adalah adanya dua penerapan dengan replika aktif, satu untuk setiap versi.

~10% pengguna terbiasa dengan versi baru dan secara tidak sengaja mengujinya. Sekarang saatnya memeriksa kesalahan pada log dan memantau data untuk menemukan masalah.

Langkah 2: Rilis versi baru ke semua pengguna

Kami memutuskan bahwa semuanya berjalan dengan baik dan sekarang kami perlu meluncurkan versi baru untuk semua pengguna. Untuk melakukan ini, kami cukup memperbarui deploy.yaml menginstal versi baru dari gambar dan jumlah replika sama dengan 10. Masuk deploy-canary.yaml kita atur jumlah replika kembali ke 0. Setelah penerapan, hasilnya adalah sebagai berikut:

Menyimpulkan

Bagi saya, menjalankan penerapan secara manual dengan cara ini membantu memahami betapa mudahnya dikonfigurasi menggunakan k8s. Karena Kubernetes memungkinkan Anda memperbarui semuanya melalui API, langkah-langkah ini dapat diotomatiskan melalui skrip.

Hal lain yang perlu diterapkan adalah titik masuk penguji (LoadBalancer atau melalui Ingress) yang hanya dapat diakses oleh versi baru. Ini dapat digunakan untuk penelusuran manual.

Di artikel mendatang, kami akan melihat solusi otomatis lainnya yang menerapkan sebagian besar hal yang telah kami lakukan.

Penerapan Canary di Kubernetes #1: Gitlab CI