Lakukan canary release dengan ALB Ingress menggunakan anotasi canary - Container Service for Kubernetes

Ingress ALB mendukung rilis canary berdasarkan header permintaan, cookie, dan bobot. Gunakan anotasi canary untuk mengarahkan sebagian lalu lintas ke versi layanan baru selama peningkatan, validasi versi baru di lingkungan produksi, lalu promosikan saat siap.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Dua vSwitch di zona berbeda, ditempatkan dalam virtual private cloud (VPC) yang sama dengan kluster ACK. Lihat Buat dan kelola vSwitch.
ALB Ingress controller terinstal di kluster. Lihat Kelola ALB Ingress controller.
Untuk menggunakan Ingress ALB di Cluster khusus ACK, pertama-tama berikan izin yang diperlukan kepada kluster tersebut. Lihat Otorisasi Cluster khusus ACK untuk mengakses ALB Ingress controller.
AlbConfig telah dibuat. Lihat Buat AlbConfig.
kubectl terhubung ke kluster ACK. Lihat Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.

Anotasi canary

Semua Ingress canary memerlukan anotasi alb.ingress.kubernetes.io/canary: "true". Tanpa anotasi ini, Ingress canary akan bentrok dengan Ingress produksi alih-alih melakukan routing bersamaan dengannya.

Anotasi berikut mengontrol cara lalu lintas dipisah:

Anotasi	Deskripsi
`alb.ingress.kubernetes.io/canary`	Diatur ke `"true"` untuk menandai Ingress ini sebagai canary. Wajib ada di setiap Ingress canary.
`alb.ingress.kubernetes.io/canary-by-header`	Kunci header permintaan yang akan dicocokkan. Permintaan yang membawa header ini diarahkan ke layanan canary.
`alb.ingress.kubernetes.io/canary-by-header-value`	Nilai header yang akan dicocokkan. Harus digunakan bersamaan dengan `canary-by-header`—tidak berpengaruh jika `canary-by-header` tidak diatur.
`alb.ingress.kubernetes.io/canary-weight`	Persentase traffic (0–100) yang diarahkan ke layanan canary untuk permintaan yang tidak sesuai dengan aturan header atau cookie. Nilai `0` tidak mengirimkan traffic; nilai `100` mengirimkan seluruh traffic.
`alb.ingress.kubernetes.io/order`	Mengontrol urutan evaluasi aturan routing. Nilai valid: 1–1000. Default: `10`. Nilai lebih rendah berarti prioritas lebih tinggi. Secara default, urutan aturan mengikuti urutan leksikografis namespace dan nama Ingress.

Prioritas aturan: Saat beberapa aturan canary aktif, aturan tersebut dievaluasi dalam urutan berikut: berbasis header > berbasis cookie > berbasis bobot.

Catatan penggunaan

Aturan berbasis header dan berbasis cookie tidak dapat dikombinasikan dengan aturan berbasis bobot pada Ingress yang sama. Konfigurasikan pada Ingress terpisah, atau gunakan aturan routing kustom untuk kondisi yang lebih kompleks.
Host dalam Ingress canary harus persis sesuai dengan host dalam Ingress produksi.
Gunakan alb.ingress.kubernetes.io/order untuk mengatur prioritas eksplisit ketika beberapa Ingress canary berbagi host yang sama, alih-alih mengandalkan pengurutan leksikografis.

Langkah 1: Deploy layanan produksi

Deploy Penyebaran, Layanan, dan Ingress untuk versi produksi.

Buat tea-deploy.yaml dengan konten berikut lalu terapkan:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx:latest
        ports:
        - containerPort: 80

kubectl apply -f tea-deploy.yaml

Buat tea-svc.yaml dengan konten berikut lalu terapkan:

apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: NodePort

kubectl apply -f tea-svc.yaml

Buat tea-ingress.yaml dengan konten berikut lalu terapkan:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tea-ingress
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top  # Ganti dengan nama domain Anda, yang di-resolve ke IP load balancer.
     http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

kubectl apply -f tea-ingress.yaml

Langkah 2: Deploy layanan canary dan aturan routing

Deploy versi layanan baru bersama dua Ingress canary: satu yang mengarahkan permintaan dengan header tertentu ke canary, dan satu lagi yang membagi lalu lintas tersisa berdasarkan bobot.

Sebelum menerapkan Ingress canary, perhatikan persyaratan berikut:

Atur alb.ingress.kubernetes.io/canary: "true" pada setiap Ingress canary. Tanpa anotasi ini, Ingress canary akan bentrok dengan Ingress produksi.
Bidang host harus persis sesuai dengan host Ingress produksi (demo.domain.ingress.top dalam contoh ini).
Aturan berbasis header dan berbasis bobot harus berada di Ingress terpisah.

Buat canary-deploy.yaml dengan konten berikut lalu terapkan:

apiVersion: apps/v1
kind: Penyebaran
metadata:
  name: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: canary
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - name: canary
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx:latest
        ports:
        - containerPort: 80

kubectl apply -f canary-deploy.yaml

Buat canary-svc.yaml dengan konten berikut lalu terapkan:

apiVersion: v1
kind: Service
metadata:
  name: canary-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: canary
  type: NodePort

kubectl apply -f canary-svc.yaml

Buat Ingress canary berbasis header. Semua permintaan yang membawa location: hz diarahkan ke canary-svc. Permintaan dengan header lain dilewatkan ke aturan pencocokan berikutnya. Buat canary-header-ingress.yaml dengan konten berikut lalu terapkan:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: canary-weight-ingress
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top  # Harus sama persis dengan host Ingress produksi.
      http:
        paths:
          - backend:
              service:
                name: canary-svc
                port:
                  number: 80
            path: /
            pathType: Prefix

kubectl apply -f canary-header-ingress.yaml

Buat Ingress canary berbasis bobot. Permintaan yang tidak sesuai dengan aturan header dibagi 50/50 antara layanan produksi dan canary. Buat canary-weight-ingress.yaml dengan konten berikut lalu terapkan:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: canary-weight-ingress
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top  # Harus persis sesuai dengan host Ingress produksi.
      http:
        paths:
          - backend:
              service:
                name: canary-svc
                port:
                  number: 80
            path: /
            pathType: Prefix

kubectl apply -f canary-weight-ingress.yaml

Verifikasi rilis canary

Dapatkan alamat instans ALB:

kubectl get ing

Output yang diharapkan:

NAME                    CLASS   HOSTS                     ADDRESS                                              PORTS   AGE
canary-header-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m23s
canary-weight-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m16s
tea-ingress             alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      7m5s

Verifikasi bahwa permintaan yang membawa location: hz selalu mencapai canary:
```
for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" -H "location:hz" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done
```
Semua 10 tanggapan mengembalikan new. Aturan header memiliki prioritas tertinggi dan mengarahkan 100% permintaan yang sesuai ke canary.
Verifikasi bahwa permintaan tanpa header yang sesuai dibagi ~50/50:
```
for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done
```
Tanggapan bergantian antara new (canary) dan old (produksi), kira-kira separuh-separuh. Permintaan yang membawa header tidak sesuai (misalnya, location: bj) mengikuti pemisahan berbasis bobot yang sama.

Langkah 3: Promosikan versi baru

Setelah canary berjalan stabil, alihkan seluruh lalu lintas produksi ke layanan baru dan bersihkan Ingress canary.

Perbarui tea-ingress.yaml agar mengarah ke canary-svc:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tea-ingress
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: canary-svc  # Diubah dari tea-svc.
            port:
              number: 80

kubectl apply -f tea-ingress.yaml

Hapus Ingress canary:

kubectl delete ing canary-weight-ingress canary-header-ingress

Verifikasi bahwa seluruh lalu lintas mencapai versi baru:
```
for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done
```
Semua 10 tanggapan mengembalikan new. Versi layanan lama sepenuhnya tidak digunakan lagi.

Langkah selanjutnya

Untuk konfigurasi Ingress ALB lanjutan termasuk pengalihan HTTP-ke-HTTPS dan aturan routing kustom, lihat Konfigurasi Ingress ALB lanjutan.
Untuk panduan troubleshooting, lihat FAQ Ingress.

Referensi

Troubleshooting masalah Ingress ALB