Penebaran kenari adalah cara yang sangat efektif untuk menguji kode baru pada sekelompok pengguna. Ini secara signifikan mengurangi beban lalu lintas, yang dapat menyebabkan masalah selama proses penempatan, karena hanya terjadi dalam subkelompok tertentu. Artikel ini dikhususkan untuk bagaimana mengatur penyebaran serupa menggunakan Kubernetes dan otomatisasi penyebaran.
Diasumsikan bahwa Anda mengetahui sesuatu tentang sumber daya Helm dan Kubernetes .
Penyebaran kenari sederhana Kubernetes mencakup dua sumber daya utama: layanan itu sendiri dan alat penyebaran. Penempatan kenari berfungsi melalui satu layanan, yang berinteraksi dengan dua sumber berbeda yang melayani pembaruan lalu lintas. Salah satu sumber daya ini akan bekerja dengan versi "kenari", dan yang kedua dengan yang stabil. Dalam situasi ini, kita dapat menyesuaikan jumlah versi kenari untuk mengurangi jumlah lalu lintas yang diperlukan untuk pemeliharaan. Jika, misalnya, Anda lebih suka menggunakan Yaml, maka akan terlihat seperti ini di Kubernetes:
kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 ... image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 ... image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments.
Lebih mudah membayangkan opsi seperti itu di kubectl, dan
dokumentasi Kubernetes bahkan memiliki tutorial lengkap tentang skenario ini. Tetapi pertanyaan utama dari postingan ini adalah bagaimana kita akan mengotomatiskan proses ini menggunakan Helm.
Otomatisasi penyebaran kenari
Pertama-tama, kita membutuhkan Peta Grafik Helm, yang sudah termasuk sumber daya yang kita bahas di atas. Seharusnya terlihat seperti ini:
~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml
Dasar dari konsep Helm adalah manajemen rilis multi-versi. Versi stabil adalah cabang stabil utama kami dari kode proyek. Tetapi dengan Helm, kami dapat menggunakan rilis kenari dengan kode eksperimental kami. Hal utama adalah untuk menjaga pertukaran lalu lintas antara versi stabil dan rilis kenari. Kami akan mengelola semua ini menggunakan pemilih khusus:
selector: app.kubernetes.io/name: myapp
Sumber daya "kenari" dan penempatan stabil kami akan menunjukkan label ini pada modul. Jika semuanya diatur dengan benar, maka selama penyebaran versi kenari dari grafik Helm kami, kami akan melihat bahwa lalu lintas akan diarahkan ke modul yang baru digunakan. Versi stabil dari perintah ini akan terlihat seperti ini:
helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5
Sekarang mari kita periksa rilis kenari kita. Untuk menggunakan versi kenari, kita perlu mengingat dua hal. Nama rilis harus berbeda sehingga kami tidak menggulung pembaruan pada versi stabil saat ini. Versi dan tag juga harus berbeda sehingga kami dapat menggunakan kode yang berbeda dan mengidentifikasi perbedaan berdasarkan label sumber daya.
helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1
Itu saja, sebenarnya! Jika Anda melakukan ping layanan, Anda dapat melihat bahwa kenari memperbarui rute hanya sebagian waktu.
Jika Anda mencari alat otomasi penyebaran yang menyertakan logika yang dijelaskan, maka periksa
Deliverybot dan
alat otomasi Helm di GitHub . Grafik Helm yang digunakan untuk mengimplementasikan metode yang dijelaskan di atas ada di Github,
di sini . Secara umum, ini adalah tinjauan teoretis tentang bagaimana menerapkan penyebaran versi kenari dalam praktiknya, dengan konsep dan contoh spesifik.