Traffic Split di Apache APISIX Ingress Controller

Fei Han

March 27, 2021

Products

Traffic Split adalah fitur yang membagi dan mengirimkan lalu lintas ke beberapa layanan backend. Solusi seperti API Gateway (misalnya Apache APISIX dan Traefik), Service Mesh (misalnya Istio dan Linkerd) mampu melakukan pembagian lalu lintas dan mengimplementasikan fungsionalitas seperti Canary Release dan Blue-Green Deployment.

Traffic split juga merupakan fitur utama dalam Ingress Controller. Sebagai lapisan ingress di kluster Kubernetes, diinginkan untuk mengurangi risiko akibat rilis versi baru aplikasi dengan menyiapkan beberapa aturan pembagian lalu lintas di ingress controller, sehingga hanya jumlah lalu lintas yang dapat dikontrol yang akan diarahkan ke instance yang baru dirilis. Dalam artikel ini, kami akan memperkenalkan pembagian lalu lintas (juga disebut canary release) di Ingress Nginx dan Kong Ingress Controller, dan pada akhirnya kami akan menjelaskan pembagian lalu lintas di Apache APISIX Ingress Controller.

(PS: Untuk deskripsi yang lebih ringkas, kami menggunakan istilah "canary app" untuk menggambarkan layanan backend yang diarahkan setelah aturan canary terpenuhi, dan istilah "stable app" untuk menggambarkan layanan backend yang diarahkan karena aturan canary tidak terpenuhi, misalnya, canary dan stable app adalah "foo-canary" dan "foo" secara berturut-turut dalam diagram berikut.)

1.png

Ingress Nginx

Ingress Nginx mendukung canary release, yang dikontrol oleh anotasi "nginx.ingress.kubernetes.io/canary", dan mendukung beberapa anotasi untuk menyesuaikan fitur ini.

  • nginx.ingress.kubernetes.io/canary-by-header

Tujuan ditentukan oleh nilai header (yang ditunjukkan oleh nginx.ingress.kubernetes.io/canary-by-header), Canary app akan diarahkan jika nilainya adalah "always", sebaliknya stable app akan diarahkan (nilai header adalah "never").

  • nginx.ingress.kubernetes.io/canary-by-header-value

Anotasi ini memperluas nginx.ingress.kubernetes.io/canary-by-header, sekarang nilai header tidak perlu lagi "always" atau "never".

  • nginx.ingress.kubernetes.io/canary-by-header-pattern

Mirip dengan nginx.ingress.kubernetes.io/canary-by-header, tetapi nilainya adalah ekspresi reguler yang kompatibel dengan PCRE.

  • nginx.ingress.kubernetes.io/canary-by-cookie

Gunakan bidang data dalam header Cookie untuk menentukan layanan backend.

  • nginx.ingress.kubernetes.io/canary-weight

Tetapkan nilai bobot antara 0 dan 100, lalu lintas akan dikirim sesuai dengan bobot ini, bobot 0 berarti semua lalu lintas akan diarahkan ke canary app dan bobot 100 akan mengarahkan semua lalu lintas ke stable app.

Cuplikan YAML berikut mengarahkan permintaan yang path URI-nya diawali dengan "/get" dan User-Agent cocok dengan pola ".Mozilla." ke canary app "foo-canary".

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/canary: "true"
      nginx.ingress.kubernetes.io/canary-by-header: "User-Agent"
      nginx.ingress.kubernetes.io/canary-by-header-pattern:
".*Mozilla.*"
  name: ingress-v1beta1

Kong

Kong Gateway memiliki plugin canary release dan mengekspos plugin ini ke ingress controller-nya melalui sumber daya KongPlugin. Administrator/Pengguna perlu membuat objek KongPlugin dan mengisi aturan canary release, menyuntikkan anotasi "konghq.com/plugins" ke Kubernetes Service target. Atau Anda dapat membuat objek KongClusterPlugin untuk membuat aturan canary ini berlaku di seluruh kluster.

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: foo-canary
config:
  percentage: 30
  upstream_host: foo.com
  upstream_fallback: false
  upstream_port: 80
plugin: canary
---
apiVersion: v1
kind: Service
metadata:
  name: foo-canary
  labels:
    app: foo
  annotations:
    konghq.com/plugins: foo-canary
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http
  selector:
    app: foo
    canary: true

Kasus di atas menandai layanan "foo-canary" sebagai "canary", dan membuat aturan canary release untuk mengarahkan 30% lalu lintas ke layanan ini.

Apache APISIX

Apache APISIX membagi lalu lintas dengan aturan kustom melalui plugin traffic-split, dan Apache APISIX Ingress Controller mengimplementasikan fitur pembagian lalu lintas ke ApisixRoute (sebagai dukungan utama, tanpa bergantung pada anotasi) melalui plugin ini dan kemampuan pencocokan rute yang fleksibel di ApisixRoute.

Berbasis Bobot

Dengan mengonfigurasi beberapa Kubernetes Services, aturan canary berbasis bobot dapat diterapkan seperti:

apiVersion: apisix.apache.org/v2alpha1
kind: ApisixRoute
metadata:
  name: foo-route
spec:
  http:
    - name: rule1
      match:
        hosts:
          - foo.org
        paths:
          - /get*
      backends:
        - serviceName: foo-canary
          servicePort: 80
          weight: 10
        - serviceName: foo
          servicePort: 80
          weight: 5

Kasus di atas mengarahkan ⅔ permintaan yang Host-nya adalah "foo.org" dan dengan prefiks path URI "/get" ke layanan "foo-canary" dan sisanya ke foo.

Bobot untuk layanan canary bisa sangat kecil untuk verifikasi skala kecil, dan memperbesar bobot dengan memodifikasi ApisixRoute hingga semua lalu lintas diarahkan ke layanan canary, menyelesaikan rilis sepenuhnya.

Berbasis Aturan

Bidang Exprs di ApisixRoute memungkinkan pengguna untuk mengonfigurasi aturan pencocokan rute kustom, di sisi lain, beberapa aturan rute dapat dikelompokkan ke dalam satu objek ApisixRoute, sehingga ada cara yang mulus untuk mengimplementasikan pembagian lalu lintas berbasis aturan.

apiVersion: apisix.apache.org/v2alpha1
kind: ApisixRoute
metadata:
  name: foo-route
spec:
  http:
    - name: rule1
      priority: 1
      match:
        hosts:
          - foo.org
        paths:
          - /get*
      backends:
        - serviceName: foo
          servicePort: 80
    - name: rule2
      priority: 2
      match:
        hosts:
          - foo.org
        paths:
          - /get*
        exprs:
          - subject:
              scope: Query
              name: id
            op: In
            set:
              - "3"
              - "13"
              - "23"
              - "33"
      backends:
        - serviceName: foo-canary
          servicePort: 80

Permintaan yang Host-nya adalah "foo.org", prefiks path URI adalah "/get" akan dipisahkan menjadi dua bagian:

  • Parameter id yang nilainya adalah 3, 13, 23, atau 33 akan memenuhi rule2, dan diteruskan ke foo-canary;
  • Yang lainnya akan memenuhi rule1 dan diarahkan ke foo.

Ringkasan

Pembagian lalu lintas (Canary release) di Ingress Nginx mendukung skema berbasis bobot dan berbasis aturan header, tetapi bergantung pada anotasi, yang semantiknya lemah; Cara Kong hanya mendukung konfigurasi canary release berdasarkan bobot, skenarionya agak sempit, dan konfigurasinya rumit (Anda perlu mengonfigurasi beberapa sumber daya); Sebaliknya, traffic split di Apache APISIX Ingress Controller fleksibel dan mudah dikonfigurasi, bekerja dengan baik untuk skema pembagian lalu lintas berbasis bobot dan berbasis aturan.

Tags:
APISIX Ingress Controller
Alternatives to Kong
Traffic Management