Canary Deployment dengan Istio

Photo by Andy Chilton on Unsplash

Proses deployment aplikasi sangat bervariasi kompleksitasnya. Ada yang super mudah seperti Heroku, Netlify dan sejenisnya. Ada pula yang cukup kompleks jika sudah mulai menggunakan teknologi seperti Docker, Kubernetes dan lain sebagainya. Kembali ke arsitektur dari aplikasi yang akan di-deploy.

Untuk arsitektur yang kompleks dan membutuhkan berbagai teknologi, ada beberapa macam strategi deployment agar prosesnya berjalan dengan risiko dan down-time seminimum/senihil mungkin. Setidaknya empat strategi berikut umum digunakan jika menggunakan Kubernetes. Dua strategi pertama sudah tersedia secara out of the box:

Untuk mempermudah diskusi, asumsikan kita memiliki 3 replicas

Recreate

Hapus semua 3 replicas lama. Setelah semuanya terhapus, nyalakan 3 replicas baru.

Rolling Update

• Nyalakan 2 replica baru
• Matikan 1 replica lama
• Nyalakan 1 replica baru
• Matikan 2 replica lama

Pada prakteknya jumlah yang dimatikan dan dinyalan pada tiap langkahnya tergantung konfigurasi maxUnavailable dan maxSurge

Blue/Green

• Nyalakan 3 replica baru, biarkan 3 replica lama tetap menyala
• Arahkan Load Balancer ke 3 replica baru tersebut
• Lakukan test
• Jika tidak ada masalah, hapus 3 replica lama
• Jika ada masalah, arahkan balik Load Balancer ke 3 replica lama dan matikan 3 replica baru

Canary

• Nyalakan secukupnya replica baru, biarkan replica lama tetap menyala
• Atur Load Balancer agar mengarahkan sebagian traffic ke replica baru
• Lakukan test (atau biarkan x% customer lakukan test dan perhatikan metricnya)
• Jika hasilnya bagus, perlahan-lahan naikkan jumlah traffic ke replica baru

Strategi Canary ini sayangnya tidak out of the box tersedia di Kubernetes, tetapi bisa diakali dengan mengatur rasio replica lama:replica baru. Contoh: Untuk mengarahkan 20% traffic ke replica baru, atur agar rasio replica lama:replica baru = 4:1 (seminimnya 4 replica:1 replica).

Namun bagaimana jika ingin mengarahkan 1% traffic ke deployment terbaru? (replica lama:replica baru = 99:1). Tentunya tidak efisien jika perlu menyalakan 100 replicas untuk ini.

Istio

Istio adalah Service Mesh untuk memudahkan pengaturan network dan interaksi antar microservice, mencakup: pengaturan traffic, keamanan, monitoring, dan performa.

Bagaimana Istio membantu Canary deployment?

(source code lengkap demo ini di https://github.com/hijup/playground/tree/master/istio)

1. Berdasarkan persentase:

Cukup mudah, kurang lebih hanya diperlukan konfigurasi berikut. 10% traffic akan diarahkan ke versi canary, sedangkan 90% akan ke versi lama. Angka ini independen dengan jumlah replica (bisa dengan hanya 1 replica lama dan 1 replica baru)

- destination:
    host: frontend.playground.svc.cluster.local
    subset: v1-canary
  weight: 10
- destination:
    host: frontend.playground.svc.cluster.local
    subset: v1
  weight: 90

2. Berdasarkan domain

Konfigurasi berikut mengarahkan canary.example.com ke versi canary, sementara www.example.com ke versi lama.

...
hosts:
  - "canary.example.com"
http:
- route:
  - destination:
      host: frontend.playground.svc.cluster.local
      subset: v1-canary
---
...
hosts:
  - "www.example.com"
http:
- route:
  - destination:
      host: frontend.playground.svc.cluster.local
      subset: v1

3. Berdasarkan HTTP header

Konfigurasi berikut mengarahkan HTTP request dengan canary header = true ke deployment canary. (bisa menggunakan extension seperti ini untuk mengubah header di browser)

http:
- match:
  - headers:
      canary:
        exact: "true"
  route:
  - destination:
      host: frontend.playground.svc.cluster.local
      subset: v1-canary
- route:
  - destination:
      host: frontend.playground.svc.cluster.local
      subset: v1

Bonus: Mirroring

Istio mampu juga melakukan Mirroring, di mana 100% traffic diduplicate — secara fire-and-forget — ke service non utama. Ini bisa untuk menguji service dengan test case perilaku di production environment, tanpa resiko apapun (asalkan mutable statenya terpisah).

TIL ketika membuat demo ini:

• Istio versi terbaru (1.0.3) memiliki bug kritikal: https://github.com/istio/istio/issues/6085#issuecomment-437471410
• istio-pilot membutuhkan memory cukup besar (memory: 2048Mi )

P.S. Jika teman-teman menyukai artikel semacam ini, silakan subscribe ke newsletter kita dan dapatkan notifikasi artikel terbaru langsung di inbox kamu!