Otomatiskan Keputusan Canary Release di Kubernetes Cluster Anda

Chao Zhang

Chao Zhang

December 30, 2022

Technology

Latar Belakang

Saat ini, microservices telah menjadi pola arsitektur perangkat lunak yang khas dan banyak digunakan. Layanan-layanan tersebut terhubung secara longgar dan berkolaborasi melalui API. Pola microservice memungkinkan setiap aplikasi dapat di-deploy dan di-maintain secara independen, sehingga rilis menjadi lebih sering. Seperti yang kita ketahui, rilis memiliki risiko; Anda tidak pernah tahu apakah ada bug dalam versi baru. Itulah mengapa orang menggunakan strategi seperti canary release dan blue-green deployment untuk secara bertahap meluncurkan versi terbaru mereka dan mengurangi risiko.

Canary Release membagi lalu lintas menjadi dua kelompok layanan target, yaitu kelompok stabil dan kelompok canary. API Gateway, seperti Apache APISIX, secara efisien dan aman mengekspos arsitektur microservice ke API. API Gateway ini dilengkapi dengan fitur canary release. Biasanya ada dua cara untuk memutuskan bagaimana membagi lalu lintas: cara berbasis bobot dan cara ekspresi predikat.

Cara Berbasis Bobot

Cara Berbasis Bobot

Pengguna perlu menentukan proporsi lalu lintas yang akan menuju ke kelompok canary. Pada gambar di atas, 95% lalu lintas akan diteruskan ke layanan stabil, sedangkan 5% lainnya akan diteruskan ke layanan canary.

Cara Ekspresi Predikat

Cara Berbasis Predikat

Cara ekspresi predikat permintaan menunjukkan bahwa hanya lalu lintas yang sesuai dengan karakteristik tertentu yang akan menuju ke kelompok canary. Misalnya, hanya permintaan HTTP dengan header permintaan X-Debug dan nilai aktualnya yang akan mencapai layanan canary.

Mengotomatisasi Canary Release

Ketika Anda mengoperasikan API gateway dengan memanggil API atau dashboard, akan ada jeda waktu dalam menyesuaikan rasio lalu lintas (untuk cara berbasis bobot) atau predikat (untuk cara ekspresi predikat). Saat ini, semakin banyak pengguna yang menggunakan Kubernetes untuk mengatur microservices mereka. Bisakah orang memulai canary release begitu versi layanan baru dibuat? Dalam artikel ini, saya akan menunjukkan cara menggunakan API7 Cloud untuk mengotomatisasi canary release di kluster Kubernetes Anda.

Apa itu API7 Cloud

API7 Cloud adalah platform SaaS multi-lokasi yang dapat digunakan di berbagai cloud untuk meng-deploy, mengontrol, memvisualisasikan, dan memantau API dalam skala besar. Jalankan API Anda di mana saja, tetapi kelola semuanya di satu tempat. API7 Cloud menggunakan Apache APISIX sebagai API Gateway untuk mengekspos API Anda secara efisien dan aman.

API7 Cloud

Untuk menggunakan API7 Cloud, Anda harus meng-deploy Apache APISIX pada infrastruktur Anda, seperti Docker dan Kubernetes. Anda dapat menggunakan Cloud CLI untuk mempermudah proses deployment.

# Konfigurasikan token akses dari konsol API7 Cloud.
cloud-cli configure --token {YOUR TOKEN}

# Deploy Apache APISIX (versi 2.15.1) ke namespace apisix, dengan hanya satu replika.
cloud-cli deploy kubernetes \
  --name my-apisix \
  --namespace apisix \
  --replica-count 1 \
  --apisix-image apache/apisix:2.15.1-centos

Canary Release adalah salah satu fitur bawaan API7 Cloud. Pengguna dapat mengonfigurasi aturan canary release melalui konsol atau memanggil API7 Cloud Open API. Tujuan kami adalah mengotomatisasi keputusan canary release, jadi kami akan menggunakan cara yang terakhir.

Skenario

Misalkan di kluster Kubernetes kami, ada aplikasi error-page sederhana yang selalu mengembalikan pesan kesalahan. Kami sedang meluncurkan versi 2.0 dan ingin menggunakan strategi canary release untuk mengurangi risiko rilis. Selain itu, kami juga ingin membuat seluruh proses ini otomatis. Oleh karena itu, kami membuat canary release controller, yang memantau perubahan dalam sumber daya layanan Kubernetes, kemudian membuat/mengubah canary release di API7 Cloud melalui API7 Cloud Go SDK. Kami hanya menggunakan cara berbasis bobot untuk membagi lalu lintas. Semua komponen, termasuk Apache APISIX API Gateway, akan di-deploy di Kubernetes sehingga diagramnya akan terlihat seperti ini:

Diagram

Canary release controller memantau perubahan layanan dan bereaksi sesuai dengan beberapa anotasi, khususnya:

  • Jika layanan mengandung anotasi api7.cloud/published-service, canary release controller akan mencoba membuat Aplikasi di API7 Cloud.
  • Jika layanan memiliki anotasi api7.cloud/published-canary-service, canary release controller akan mencoba mengatur aturan canary release di API7 Cloud dan anotasi api7.cloud/published-service-canary-percentage akan menentukan persentasenya.

Perhatikan bahwa controller ini tidak mandiri (tidak menghapus Aplikasi jika layanan dihapus), tetapi cukup untuk menunjukkan proses canary release yang otomatis.

Mari Mulai!

Mari kita mulai dengan meng-deploy Apache APISIX dan canary release controller. Seperti yang disebutkan di atas, kami menggunakan Cloud CLI untuk meng-deploy Apache APISIX. Kami juga memiliki dua file YAML (error-page/manifest-v1.yaml dan controller/manifest.yaml) untuk meng-deploy aplikasi error-page dan canary release controller.

  1. Harap siapkan kluster Kubernetes yang tersedia jika Anda ingin menjalankan perintah berikut.
  2. Canary release controller memerlukan token akses untuk memanggil API7 Cloud API. Kami mengambil token sesuai dengan dokumen ini dan menyimpan token tersebut dalam secret K8s.
kubectl create namespace canary-release-demo
# Deploy versi v1 error-page.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v1.yaml -n canary-release-demo

# Buat secret K8s untuk menyimpan token akses API7 Cloud.
kubectl create secret generic api7-cloud --namespace canary-release-demo --from-literal token={Your Access Token}

# Deploy canary release controller.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/controller/manifest.yaml -n canary-release-demo

# Periksa apakah semua workload berjalan normal.
kubectl get all -n canary-release-demo

Periksa Proxy

Mari publikasikan layanan ini dengan menambahkan anotasi.

kubectl annotate service -n canary-release-demo error-page-v1 "api7.cloud/published-service=error-page"

Canary release controller akan memantau perubahan ini dan membuat Aplikasi di API7 Cloud. Sekarang mari kita akses Apache APISIX untuk melihat apakah proxy berfungsi normal.

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s

Jika semuanya berjalan dengan baik, Anda akan melihat {"error": "injected by error_page service", "version": "v1"}.

Saat ini, canary release controller membuat API "match-everything" di Aplikasi, dan Host-nya sama dengan nama Aplikasi (error-page).

Luncurkan V2

Kami ingin meluncurkan versi 2 untuk aplikasi error page. Pertama, kami meng-deploy versi 2 dengan menerapkan manifest-v2.yaml. Kami menambahkan anotasi canary release ke layanan error-page-v2.

kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v2.yaml -n canary-release-demo

# Beri tahu canary release controller bahwa kami mengaktifkan canary release untuk error-page-v2, dan persentasenya adalah 10%.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-canary-service=true" "api7.cloud/published-service-canary-percentage=10"

# Mulai canary.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service=error-page"

Sekarang mari kita kirim 100 permintaan ke Apache APISIX lagi dan lihat apakah beberapa permintaan diteruskan ke layanan canary error-page-v2.

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Hanya sekitar 10% permintaan yang akan mencapai error-page-v2 (tidak tepat 10% karena strategi internal Apache APISIX dalam memilih backend) jika semuanya berjalan dengan baik.

Rollback

Kami menemukan bahwa versi 2 tidak stabil dan ingin mengembalikannya. Sebelum melakukannya, kami akan menghentikan canary terlebih dahulu, jadi kami mengubah persentase menjadi 0. Kemudian kirim permintaan ke Apache APISIX lagi.

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=0" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Anda akan melihat semua permintaan sekarang menuju ke error-page-v1.

Rilis

Setelah beberapa waktu, kami yakin versi 2 cukup stabil, dan kami ingin semua permintaan mencapai versi 2. Kemudian kami dapat menonaktifkan aplikasi error page versi 1. Jadi kami mengubah persentase menjadi 100%.

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=100" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Sekarang semua permintaan diproksi ke error-page-v2. Dan error-page-v1 dapat dinonaktifkan dengan aman.

Ringkasan

Canary release adalah senjata efektif untuk rilis. Namun, menyesuaikan strategi canary release mungkin terlambat. Artikel ini menunjukkan cara mengoperasikan canary release secara deklaratif dan mengotomatisasi canary release hingga batas tertentu. Beberapa orang mungkin mengejar canary release yang sepenuhnya otomatis dengan bantuan komponen GitOps. Misalnya, dengan menggunakan Argo Rollouts, seseorang dapat secara otomatis mempromosikan atau mengembalikan layanan. Argo Rollouts mengkueri metrik layanan dan mengintegrasikan dengan ingress controllers untuk mengubah CRD mereka. Pada akhirnya, API Gateway akan meneruskan permintaan dalam proporsi yang benar ke versi canary.

Referensi

Kode sumber untuk error page dan canary release controller: https://github.com/tokers/canary-release-automation-demo.

Tags:
API Gateway Concept
API7 Cloud
Kubernetes