Service Mesh

Sebelum masuk ke hal teknis, kita akan membahas tentang apa itu service mesh sendiri. Service mesh merupakan metode yang menyediakan sebuah policy-based tentang bagaimana cara microservices berkomunikasi berdasarkan pola perilaku yang diinginkan pada microservices tersebut. Secara gampangnya adalah services mesh memudahkan kita untuk mengatur manajemen dari microservices yang kita punya.

Beberapa fitur yang dimiliki service mesh adalah:

• Observability (monitoring, logging, tracing)
• Traffic Control (canary release, A/B test)
• Service Resiliency (retry, timeout)
• Security (mTLS, Policy, JWT)

Untuk lanjutan tetang beberapa dokumentasi dan penjelasan lebih silahkan cek link dibawah ini

• Istio
• Linkerd

Oke, setelah dari penjelasan ringan tentang service mesh, untuk Canary release ini akan menggunakan salah satu tool service mesh yaitu Istio.

Canary Release

Canary release atau beberapa orang menyebutnya juga dengan Canary Deployment adalah suatu metode strategi untuk mengurangi resiko dalam melakukan release suatu aplikasi secara perlahan meluncurkan perubahan ke sebagian kecil pengguna sebelum meluncurkanya sampai ke tahap full release. Maksud dari ke sebagian kecil penggunakan adalah sample set untuk uji coba release aplikasi yang sudah direncanakan.

Beberapa contoh sample set

• Random
• Representative (By Geography, Time, User Patterns)
• Granularity
• Resource Mapping

Some Example

Tool service mesh seperti Istio ini berjalan diatas infrastruktur Kubernetes. Pertama siapkan objek konfigurasi Deployment dan minimal ada dua macam deployment untuk menentukan subset version pada Canary Release.

# First Deployment
apiVersion: extensions/v1beta1
kind: Deployment
---
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: backsite
        version: v1 # Untuk versi pertama
    spec:
      containers:
---

# Second Deployment
apiVersion: extensions/v1beta1
kind: Deployment
---
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: backsite
        version: v2 # Untuk versi kedua
    spec:
      containers:
---

Kemudian apply deployment dan objek konfigurasi service.

Istio berkomunikasi dengan API Server Kubernetes menggunakan CRD (Custom Resource Definitions) sehingga Istio dapat membuat objek konfigurasinya sendiri pada klaster kubernetes. Dibawah ini merupakan objek konfigurasi Gateway yang digunakan untuk membuka akses traffic masuk pada lingkungan service mesh Istio yang bersifat isolation.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: backsite-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

Langkah selanjutnya adalah menentukan traffic routing dari traffic yang masuk / ingress ke dalam deployment pod dan service yang sudah diterapkan. Fungsi tersebut dapat diatasi dengan objek konfigurasi Virtual Service pada Istio.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
---
spec:
  hosts:
  - "*"
  gateways:
  - backsite-gateway
  http:
    - route:
      - destination:
          host: backsite-svc
          subset: v1
        weight: 90
      - destination:
          host: backsite-svc
          subset: v2
        weight: 10

Pada section weight Virtual Service diatas, deployment atau pod pertama akan memberikan load sebesar 90% dan deployment kedua hanya 10%. Jadi ketika ada traffic masuk request ke dalam service yang sama maka besar kemungkinan akan dilayani oleh deployment pertama. Setelah mengimplementasikan Virtual Service untuk traffic routing, selanjutnya adalah menerapkan aturan traffic yang digunakan pada Virtual Service dan objek konfigurasi Istio tersebut dimiliki oleh Destination Rule. Berikut contoh potongan YAML file untuk Destination Rule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
---
spec:
  host: backsite-svc
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Aturan dari yaml diatas adalah untuk subset pertama harus dimiliki oleh label deployment pertama dan begitu selanjutnya untuk subset kedua harus dimiliki oleh label deployment kedua.

Lakukan pengujian dengan cara melakukan request ke Istio-ingressgateway dan ketika ingin melakukan perubahan nilai weight edit saja objek konfigurasi Virtual Service.

Berikut contoh kasus Canary Release hanya untuk pengguna mobile dan traffic diarahkan ke deployment pertama saja

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-header
---
  http:
  - match:
    - headers:
        user-agent:
          regex: '^.*(Android|iPhone).*$'
    route:
    - destination:
        host: somesite-svc
        subset: v1

Thanks

Full code : github