Konfigurasi canary release otomatis end-to-end dengan Kruise Rollouts-Microservices Engine-Alibaba Cloud

Rilis canary standar hanya memvalidasi layanan yang Anda deploy, tetapi tidak memverifikasi interaksi layanan tersebut dengan dependensinya di hulu dan hilir. Misalnya, ketika layanan A memanggil layanan B yang kemudian memanggil layanan C, merilis versi canary hanya pada layanan A menyebabkan seluruh jalur permintaan tidak teruji.

Rilis canary ujung ke ujung mengatasi masalah ini dengan membuat traffic lanes. Traffic lane memberi tag pada permintaan di ingress dan menyebarkan tag tersebut melalui setiap layanan dalam rantai panggilan. Setiap layanan memeriksa tag tersebut dan mengarahkan permintaan ke versi canary-nya jika tersedia. Jika suatu layanan tidak memiliki versi canary yang dideploy, permintaan akan diteruskan ke versi dasarnya, tetapi tag tetap dipertahankan agar layanan hilir berikutnya dapat mengarahkan permintaan dengan benar. Hasilnya, traffic canary tetap terisolasi dari ingress hingga layanan hilir terakhir, sehingga Anda dapat memvalidasi perubahan beberapa layanan sekaligus sebelum mempromosikannya ke produksi.

Panduan ini mengintegrasikan Kruise Rollouts dengan Microservices Governance dari Microservices Engine (MSE) dalam kluster Container Service for Kubernetes (ACK). Setelah menyelesaikan langkah-langkah berikut, permintaan bertag akan mengalir melalui versi canary dari beberapa layanan, sementara traffic produksi tetap tidak terganggu.

Cara kerja Kruise Rollouts

Kruise Rollouts adalah komponen progressive delivery dari OpenKruise. Anda dapat menggunakan Kruise Rollouts untuk melakukan rilis canary, penyebaran biru-hijau, dan Pengujian A/B. Berbeda dengan alat yang mengharuskan Anda mengganti tipe workload, Kruise Rollouts beroperasi sebagai bypass component: Deployment, StatefulSet, atau CloneSet yang sudah ada tetap tidak berubah, dan Kruise Rollouts mengoordinasikan proses canary secara paralel. Proses rilis dapat diotomatisasi dalam batch dan dijeda berdasarkan metrik dari Managed Service for Prometheus. Anda hanya perlu membuat resource Rollouts di kluster ACK untuk mengotomatisasi rilis dan pembaruan aplikasi. Kruise Rollouts mendukung integrasi tanpa hambatan dengan Helm dan platform PaaS dengan biaya rendah.

Siklus hidup rilis canary

Ketika gambar Deployment berubah, Kruise Rollouts mengikuti urutan berikut:

Jeda pembaruan rolling native Deployment.
Buat Pod canary dengan versi gambar baru.
Konfigurasikan pengarahan traffic sehingga permintaan yang sesuai mencapai Pod canary.
Tunggu persetujuan manual (atau pemeriksaan metrik otomatis).
Jika disetujui, promosikan versi canary ke semua Pod menggunakan pembaruan rolling.
Hapus Pod canary dan kembalikan pengarahan traffic native.

Kruise Rollouts canary release architecture

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Kluster ACK yang menjalankan Kubernetes 1.19 atau lebih baru. Untuk informasi selengkapnya, lihat Buat Kluster ACK yang dikelola.
kubectl-kruise terinstal. Untuk informasi selengkapnya, lihat kubectl-kruise.
Microservices Governance diaktifkan. Untuk informasi selengkapnya, lihat Aktifkan Microservices Governance.

Langkah 1: Instal komponen yang diperlukan

Instal ack-kruise

Masuk ke ACK console. Pada panel navigasi di sebelah kiri, klik Clusters.
Pada halaman Clusters, temukan kluster target Anda dan klik namanya. Di panel navigasi sebelah kiri, pilih Operations > Add-ons.
Pada halaman Manage Components, klik tab Manage Applications.
Temukan kartu ack-kruise dan klik Install.
Pada dialog konfirmasi, klik OK.

Instal MSE Ingress Controller

Buat resource MseIngressConfig dan IngressClass untuk mengaktifkan ingress berbasis MSE di kluster Anda. Untuk langkah-langkah detail, lihat Gunakan MSE Ingresses untuk mengakses aplikasi di kluster ACK.

Aktifkan Microservices Governance

Aktifkan Microservices Governance untuk aplikasi target Anda. Untuk langkah-langkah detail, lihat Aktifkan Microservices Governance untuk aplikasi layanan mikro di kluster ACK.

Langkah 2: Deploy aplikasi demo

Demo ini menggunakan tiga aplikasi Spring Cloud — A, B, dan C — yang membentuk rantai panggilan: A memanggil B, yang kemudian memanggil C. Server Nacos menangani penemuan layanan, dan instans MySQL menyediakan penyimpanan data.

Buat resource aplikasi

Buat file bernama mse-demo.yaml dengan konten berikut:

Lihat file mse-demo.yaml

    # Service for application A
    apiVersion: v1
    kind: Service
    metadata:
      name: spring-cloud-a
    spec:
      ports:
        - name: http
          port: 20001
          protocol: TCP
          targetPort: 20001
      selector:
        app: spring-cloud-a
    ---
    # Deployment for application A (base version)
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: spring-cloud-a
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: spring-cloud-a
      template:
        metadata:
          annotations:
            msePilotCreateAppName: spring-cloud-a
          labels:
            app: spring-cloud-a
        spec:
          containers:
            - env:
                - name: JAVA_HOME
                  value: /usr/lib/jvm/java-1.8-openjdk/jre
              image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-a:mse-2.0.0
              imagePullPolicy: Always
              name: spring-cloud-a
              ports:
                - containerPort: 20001
    ---
    # Deployment for application B (base version)
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: spring-cloud-b
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: spring-cloud-b
      template:
        metadata:
          annotations:
            msePilotCreateAppName: spring-cloud-b
          labels:
            app: spring-cloud-b
        spec:
          containers:
            - env:
                - name: JAVA_HOME
                  value: /usr/lib/jvm/java-1.8-openjdk/jre
              image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-b:mse-2.0.0
              imagePullPolicy: Always
              name: spring-cloud-b
    ---
    # Deployment for application C (base version)
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: spring-cloud-c
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: spring-cloud-c
      template:
        metadata:
          annotations:
            msePilotCreateAppName: spring-cloud-c
          labels:
            app: spring-cloud-c
        spec:
          containers:
            - env:
                - name: JAVA_HOME
                  value: /usr/lib/jvm/java-1.8-openjdk/jre
              image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-c:mse-2.0.0
              imagePullPolicy: Always
              name: spring-cloud-c
    ---
    # Nacos service discovery server
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nacos-server
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nacos-server
      template:
        metadata:
          labels:
            app: nacos-server
        spec:
          containers:
          - env:
            - name: MODE
              value: standalone
            image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/nacos-server:v2.1.2
            imagePullPolicy: Always
            name: nacos-server
          dnsPolicy: ClusterFirst
          restartPolicy: Always
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nacos-server
    spec:
      type: ClusterIP
      ports:
        - name: nacos-server-8848-8848
          port: 8848
          protocol: TCP
          targetPort: 8848
        - name: nacos-server-9848-9848
          port: 9848
          protocol: TCP
          targetPort: 9848
      selector:
        app: nacos-server
    ---
    # MySQL database
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: demo-mysql
      name: demo-mysql
    spec:
      ports:
        - port: 3306
          targetPort: 3306
      selector:
        app: demo-mysql
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: demo-mysql
    spec:
      selector:
        matchLabels:
          app: demo-mysql
      replicas: 1
      strategy:
        type: Recreate
      template:
        metadata:
          labels:
            app: demo-mysql
        spec:
          containers:
            - args:
                - --character-set-server=utf8mb4
                - --collation-server=utf8mb4_unicode_ci
              env:
                - name: MYSQL_ROOT_PASSWORD
                  value: root
              image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/demo-mysql:3.0.1
              name: demo-mysql
              ports:
                - containerPort: 3306

Deploy aplikasi:
```
    kubectl apply -f mse-demo.yaml
```

Buat resource Ingress

Buat file bernama mse-ingress.yaml dengan konten berikut:

Lihat file mse-ingress.yaml

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        mse.ingress.kubernetes.io/service-subset: ""
      name: spring-cloud-a
    spec:
      ingressClassName: mse
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: spring-cloud-a
                    port:
                      number: 20001
                path: /
                pathType: Prefix

Terapkan konfigurasi Ingress:
```
    kubectl apply -f mse-ingress.yaml
```

Verifikasi deployment

Dapatkan alamat IP eksternal Ingress: Output yang diharapkan:

    kubectl get ingress

    NAME              CLASS    HOSTS   ADDRESS        PORTS   AGE
    spring-cloud-a    <none>   *       EXTERNAL_IP    80      12m

Kirim permintaan uji. Ganti <EXTERNAL_IP> dengan alamat IP dari output sebelumnya: Output yang diharapkan: Output ini mengonfirmasi bahwa rantai panggilan A -> B -> C berfungsi dan ketiga layanan menjalankan versi dasar.
```
    curl http://<EXTERNAL_IP>/a -H "User-Agent: xiaoming"
```
```
    A[192.168.42.115][config=base] -> B[192.168.42.118] -> C[192.168.42.101]
```

Langkah 3: Konfigurasikan rilis canary ujung ke ujung

Definisikan resource Rollout dan TrafficRouting

Dalam demo ini, rilis canary dilakukan dalam tiga batch:

Dilakukan Pengujian A/B. Permintaan yang berisi header[User-Agent]=xiaoming diarahkan ke versi canary. Permintaan lainnya diarahkan ke versi dasar.
Separuh Pod menjalankan versi canary, dan separuh permintaan diarahkan ke versi canary.
Semua Pod menjalankan versi canary, dan semua permintaan diarahkan ke versi canary.

Buat dan terapkan resource Rollout sebagai berikut:

Buat file bernama rollout.yaml dengan konten berikut:

Lihat file rollout.yaml

    # Rollout configuration for application A
    apiVersion: rollouts.kruise.io/v1alpha1
    kind: Rollout
    metadata:
      name: rollout-a
      annotations:
        rollouts.kruise.io/trafficrouting: mse-traffic
    spec:
      objectRef:
        workloadRef:
          apiVersion: apps/v1
          kind: Deployment
          name: spring-cloud-a
      strategy:
        canary:
          steps:
          - pause: {}
            replicas: 1
          patchPodTemplateMetadata:
            labels:
              alicloud.service.tag: gray
              opensergo.io/canary-gray: gray
    ---
    # Rollout configuration for application B
    apiVersion: rollouts.kruise.io/v1alpha1
    kind: Rollout
    metadata:
      name: rollout-b
      annotations:
        rollouts.kruise.io/trafficrouting: mse-traffic
    spec:
      objectRef:
        workloadRef:
          apiVersion: apps/v1
          kind: Deployment
          name: spring-cloud-b
      strategy:
        canary:
          steps:
            - pause: {}
              replicas: 1
          patchPodTemplateMetadata:
            labels:
              alicloud.service.tag: gray
              opensergo.io/canary-gray: gray
    ---
    # Rollout configuration for application C
    apiVersion: rollouts.kruise.io/v1alpha1
    kind: Rollout
    metadata:
      name: rollout-c
      annotations:
        rollouts.kruise.io/trafficrouting: mse-traffic
    spec:
      objectRef:
        workloadRef:
          apiVersion: apps/v1
          kind: Deployment
          name: spring-cloud-c
      strategy:
        canary:
          steps:
            - pause: {}
              replicas: 1
          patchPodTemplateMetadata:
            labels:
              alicloud.service.tag: gray
              opensergo.io/canary-gray: gray
    ---
    # TrafficRouting: defines how canary traffic is identified and routed
    apiVersion: rollouts.kruise.io/v1alpha1
    kind: TrafficRouting
    metadata:
      name: mse-traffic
    spec:
      objectRef:
      - service: spring-cloud-a
        ingress:
          classType: mse
          name: spring-cloud-a
      strategy:
        matches:
        # Route requests with User-Agent: xiaoming to the canary version
        - headers:
          - type: Exact
            name: User-Agent
            value: xiaoming
        requestHeaderModifier:
          set:
          - name: x-mse-tag
            value: gray

Apa yang terjadi saat Anda menerapkan konfigurasi ini:

Setiap resource Rollout memantau sebuah Deployment. Saat gambar Deployment berubah, Kruise Rollouts:

Menjeda pembaruan rolling native.
Membuat satu Pod canary (replicas: 1) dengan versi gambar baru.
Menerapkan label patchPodTemplateMetadata ke Pod canary:
- alicloud.service.tag: gray — memberi tahu MSE Microservices Governance untuk mengenali Pod ini sebagai bagian dari grup canary (gray).
- opensergo.io/canary-gray: gray — mengaktifkan pengarahan traffic lane yang kompatibel OpenSergo di seluruh rantai panggilan.
Menjeda dan menunggu persetujuan manual sebelum mempromosikan.

Resource TrafficRouting menetapkan aturan pemisahan traffic:

Permintaan dengan header User-Agent: xiaoming sesuai dengan aturan canary.
requestHeaderModifier menyisipkan header x-mse-tag: gray ke permintaan yang sesuai. MSE menyebarkan header ini melalui seluruh rantai panggilan, memungkinkan pengarahan canary ujung ke ujung. Setiap layanan dalam rantai memeriksa header ini dan mengarahkan ke Pod canary-nya jika tersedia.

Deploy resource Rollout:
```
    kubectl apply -f rollout.yaml
```
Verifikasi status Rollout: Jika output menunjukkan STATUS=Healthy, resource Rollout siap digunakan.
```
    kubectl get rollouts rollout-a -n default
    kubectl get rollouts rollout-c -n default
```

Picu rilis canary

Kruise Rollouts adalah konfigurasi sekali pakai. Setelah resource Rollout dideploy, picu rilis canary dengan memperbarui gambar Deployment Anda — tidak diperlukan konfigurasi Rollout tambahan. Selain kubectl, Anda juga dapat menggunakan Helm atau Vela untuk mendeploy Deployment ke kluster Anda.

Dalam mse-demo.yaml, perbarui versi gambar untuk spring-cloud-a dan spring-cloud-c dari mse-2.0.0 menjadi mse-2.0.1: Aplikasi B tetap pada mse-2.0.0. Karena B tidak memiliki versi canary, permintaan yang diarahkan ke jalur canary melewati versi dasar B tetapi tetap melanjutkan ke versi canary C. Ini menunjukkan traffic lane ujung ke ujung: bahkan ketika suatu layanan di tengah rantai tidak memiliki deployment canary, tag canary tetap dipertahankan dan layanan hilir tetap mengarahkan dengan benar.
```
    # In the spring-cloud-a Deployment
    image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-a:mse-2.0.1

    # In the spring-cloud-c Deployment
    image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-c:mse-2.0.1
```
Terapkan Deployment yang diperbarui:
```
    kubectl apply -f mse-demo.yaml
```

Periksa progres Rollout: Output yang diharapkan:

Field	Value	Meaning
`STATUS`	`Progressing`	Rilis canary sedang berlangsung
`CANARY_STATE`	`StepPaused`	Batch canary telah dideploy dan rollout menunggu persetujuan manual

    kubectl get rollouts rollout-a -n default
    kubectl get rollouts rollout-c -n default

    NAME         STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                        AGE
    rollout-a    Progressing   1             StepPaused     Rollout is in step(1/1), and you need manually confirm to enter the next step   41m
    rollout-c    Progressing   1             StepPaused     Rollout is in step(1/1), and you need manually confirm to enter the next step   41m

Verifikasi dan promosikan versi canary

Kirim permintaan uji canary dengan menyertakan header User-Agent: xiaoming: Traffic canary mengalir melalui versi canary A dan C, sementara B menggunakan versi dasarnya. Verifikasi perilaku melalui log aplikasi dan metrik pemantauan.
```
    curl http://<EXTERNAL_IP>/a -H "User-Agent: xiaoming"
```
Setelah memastikan versi canary berfungsi sesuai harapan, setujui rollout untuk mempromosikannya ke produksi. Jalankan perintah berikut untuk setiap Rollout yang memiliki versi canary yang dideploy (dalam demo ini, rollout-a dan rollout-c). Ganti <rollouts-demo> dengan nama resource Rollouts:
```
    rollout.rollouts.kruise.io/<rollouts-demo> approved
```

Kembalikan rilis canary

Jika versi canary tidak memenuhi harapan, kembalikan versi gambar dalam mse-demo.yaml ke nilai aslinya dan terapkan kembali:

kubectl apply -f mse-demo.yaml

Tidak diperlukan perubahan pada resource Rollout. Kruise Rollouts mendeteksi perubahan Deployment dan menangani rollback secara otomatis.

Fitur rilis canary ujung ke ujung dari Microservices Governance menyediakan jalur lalu lintas, yang sangat mempermudah verifikasi selama pengujian dan rilis. Anda dapat menggunakan Microservices Governance bersama Kruise Rollouts untuk meningkatkan stabilitas aplikasi online secara signifikan dalam proses DevOps.