Container Service for Kubernetes:Lakukan rilis canary dengan Ingress ALB di kluster ACK

Prasyarat

Lengkapi hal-hal berikut:

• Dua vSwitch di zona berbeda dalam VPC yang sama dengan kluster ACK. Lihat Buat dan kelola vSwitch.

• ALB Ingress controller telah diinstal di kluster. Lihat Kelola ALB Ingress controller.

  Untuk cluster khusus ACK, berikan izin kepada kluster untuk mengakses ALB Ingress. Lihat Otorisasi cluster khusus ACK untuk mengakses ALB Ingress controller.

• AlbConfig telah dibuat. Lihat Buat AlbConfig.

• kubectl telah terhubung ke kluster ACK. Lihat Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.

Anotasi canary

Setiap Ingress canary harus memiliki anotasi alb.ingress.kubernetes.io/canary: "true". Tanpa anotasi ini, Ingress canary akan bentrok dengan Ingress produksi alih-alih melakukan routing secara paralel.

Anotasi berikut mengontrol pemisahan lalu lintas:

Prioritas aturan: berbasis header > berbasis cookie > berbasis bobot.

Catatan penggunaan

• Aturan berbasis header dan cookie tidak dapat berada dalam satu Ingress yang sama dengan aturan berbasis bobot. Gunakan Ingress terpisah atau aturan routing kustom untuk kondisi kompleks.

• Host Ingress canary harus identik dengan host Ingress produksi.

• Tetapkan prioritas eksplisit menggunakan alb.ingress.kubernetes.io/order ketika beberapa Ingress canary berbagi host, alih-alih mengandalkan pengurutan leksikografis.

Langkah 1: Sebarkan layanan produksi

Sebarkan Penyebaran (Deployment), Service, dan Ingress produksi.

1. Buat tea-deploy.yaml dan 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

2. Buat tea-svc.yaml dan 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

3. Buat tea-ingress.yaml dan 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: Sebarkan layanan canary dan aturan routing

Sebarkan layanan canary dengan dua Ingress canary: satu melakukan routing berdasarkan header, satunya membagi lalu lintas sisa berdasarkan bobot.

Sebelum menerapkan Ingress canary:

• Tetapkan alb.ingress.kubernetes.io/canary: "true" pada setiap Ingress canary. Tanpa itu, Ingress canary akan bentrok dengan Ingress produksi.

• Bidang host harus identik dengan host Ingress produksi (demo.domain.ingress.top dalam contoh ini).

• Aturan berbasis header dan berbasis bobot harus berada pada Ingress terpisah.

1. Buat canary-deploy.yaml dan terapkan:

   apiVersion: apps/v1
   kind: Deployment
   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

2. Buat canary-svc.yaml dan 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

3. Buat Ingress canary berbasis header. Permintaan dengan location: hz diarahkan ke canary-svc; header lain dilewatkan ke aturan berikutnya. Buat canary-header-ingress.yaml dan 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

4. Buat Ingress canary berbasis bobot. Permintaan yang tidak cocok dibagi 50/50 antara layanan produksi dan canary. Buat canary-weight-ingress.yaml dan 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 sama 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

1. 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

2. 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 semua permintaan yang cocok ke canary.

3. Verifikasi bahwa permintaan tanpa header yang cocok 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. Header yang tidak cocok (misalnya, location: bj) mengikuti pemisahan berbasis bobot yang sama.

Langkah 3: Promosikan versi baru

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

1. 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

2. Hapus Ingress canary:

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

3. 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 ditinggalkan.

Langkah selanjutnya

• Lihat Konfigurasi Ingress ALB lanjutan untuk pengalihan HTTP ke HTTPS, aturan routing kustom, dan lainnya.

• Lihat FAQ Ingress untuk troubleshooting.