Gunakan Argo CD untuk mengimplementasikan rilis canary ujung ke ujung dan penyebaran layanan aplikasi - Alibaba Cloud Service Mesh

Argo CD memantau perubahan pada orkestrasi aplikasi di repositori Git, membandingkan konfigurasi aplikasi dengan status aplikasi terkait di kluster, serta secara otomatis menerapkan perubahan tersebut ke kluster. Argo CD juga memungkinkan Anda untuk secara manual menerapkan perubahan ke kluster. Jika Anda ingin meluncurkan versi baru aplikasi mikro dengan risiko minimal dan melakukan transisi yang mulus sambil memverifikasi fitur baru secara bertahap, Anda dapat menggunakan Argo CD untuk mengimplementasikan rilis canary ujung ke ujung layanan aplikasi. Argo CD menggunakan metode penjadwalan trafik yang halus dan manajemen versi untuk memastikan transisi tanpa hambatan antara versi lama dan baru, meminimalkan dampak pada layanan online, serta meningkatkan stabilitas dan keandalan sistem.

Prasyarat

Sebuah instance Service Mesh (ASM) Edisi Enterprise atau Ultimate telah dibuat, dengan versi instansinya minimal 1.20.6.27. Untuk informasi lebih lanjut, lihat Buat Instance ASM dan Perbarui Instance ASM.
Sebuah kluster Container Service for Kubernetes (ACK) telah ditambahkan ke instance ASM. Untuk informasi lebih lanjut, lihat Tambahkan Kluster ke Instance ASM.
Argo CD telah diinstal dan gateway masuk telah dibuat. Untuk informasi lebih lanjut, lihat Langkah 1 hingga Langkah 3 di Integrasi Argo CD dengan ASM untuk Mengimplementasikan GitOps.
Klien kubectl telah terhubung ke kluster. Untuk informasi lebih lanjut, lihat Dapatkan File kubeconfig Kluster dan Gunakan kubectl untuk Terhubung ke Kluster.

Informasi latar belakang

Argo CD memungkinkan Anda untuk mengimplementasikan pendekatan GitOps dalam menyebarkan dan menerbitkan layanan aplikasi. Sebagai pengembang, Anda dapat mendefinisikan sumber daya aplikasi dan manajemen trafik menggunakan file YAML dan mengirimkan definisi tersebut ke repositori Git. Sumber daya aplikasi mencakup Deployments dan Services, sedangkan sumber daya manajemen trafik mencakup VirtualServices, Gateways, dan DestinationRules. Argo CD memantau status sumber daya di kluster dan membandingkannya dengan orkestrasi sumber daya yang diharapkan di repositori Git. Ketika sumber daya berubah di repositori Git, Argo CD secara otomatis menyinkronkan perubahan tersebut ke sumber daya di kluster. Argo CD juga memungkinkan Anda untuk secara manual menyinkronkan perubahan tersebut.

ASM memungkinkan Anda menggunakan jalur lalu lintas untuk mengisolasi Services dari versi tertentu aplikasi atau aplikasi dengan karakteristik tertentu ke dalam lingkungan runtime yang independen. Ini membantu Anda mengimplementasikan rilis canary ujung ke ujung layanan sebuah aplikasi. Pada instance ASM versi 1.20.6.27 atau lebih baru, Anda dapat menggunakan CustomResourceDefinitions (CRDs) ASMSwimLaneGroup dan ASMSwimLane untuk mendefinisikan jalur lalu lintas. Anda dapat menggunakan Argo CD untuk mengelola kedua CRD ini guna mengimplementasikan rilis canary ujung ke ujung. Untuk informasi lebih lanjut, lihat Ikhtisar Jalur Lalu Lintas.

Langkah 1: Gunakan Argo CD untuk menyebarkan layanan aplikasi dan aturan jalur lalu lintas

Buat aplikasi tiruan dan implementasikan rilis canary ujung ke ujung aplikasi tersebut.

Di antarmuka pengguna Argo CD, klik NEW APP dan atur parameter.

Parameter	Deskripsi
Application Name	Nama aplikasi. Untuk contoh ini, masukkan `mock`.
SYNC POLICY	Kebijakan sinkronisasi aplikasi. Untuk contoh ini, pilih `Automatic`. Ini berarti bahwa definisi sumber daya terbaru di repositori Git disinkronkan secara otomatis ketika definisi sumber daya di repositori Git berubah. Jika Anda memilih `PRUNE RESOURCES`, sumber daya akan dihapus ketika definisinya tidak lagi ada di repositori Git.
Repository URL	URL repositori Git dari mana Anda ingin menyinkronkan definisi sumber daya. Untuk contoh ini, masukkan `https://github.com/AliyunContainerService/asm-labs.git`. Anda dapat membuat fork repositori Git dan memodifikasi kode YAML di repositori Git yang difork.
Revision	Tag Git atau nama cabang repositori Git dari mana definisi sumber daya disinkronkan. Untuk contoh ini, masukkan `argocd-asm`.
Path	Jalur kode di repositori Git dari mana definisi sumber daya disinkronkan. Untuk contoh ini, masukkan jalur `argo-cd/swimlane` tempat sumber daya yang digunakan oleh contoh berikut berada.
Cluster URL	Titik akhir server API Kubernetes dari kluster ke mana definisi sumber daya disinkronkan. Untuk contoh ini, masukkan `https://kubernetes.default.svc`. Ini adalah titik akhir server API Kubernetes dari kluster di mana Argo CD diinstal.

Setelah mengatur parameter, klik CREATE di bagian atas halaman.
Di halaman Applications antarmuka pengguna Argo CD, Anda dapat melihat status aplikasi mock yang baru saja dibuat.
Klik aplikasi mock untuk melihat status sinkronisasi sumber daya.
Anda dapat melihat bahwa selain sumber daya Deployments dan Services, repositori Git juga berisi sumber daya seperti VirtualServices, Gateways, ASMSwimLaneGroup, dan ASMSwimLane.

Langkah 2: Verifikasi rilis canary ujung ke ujung menggunakan jalur lalu lintas

Dalam contoh ini, CRD ASMSwimLaneGroup dan ASMSwimLane digunakan untuk mengisolasi v1 dan v2 dari Services. Anda dapat membuat layanan virtual untuk memungkinkan gateway masuk meneruskan permintaan ke dua versi Services tersebut dengan rasio 1:1. Anda dapat mengakses gateway masuk berulang kali untuk memverifikasi rilis canary ujung ke ujung.

Dapatkan alamat IP publik gateway masuk di Konsol ASM. Untuk informasi lebih lanjut, lihat bagian "Langkah 2: Dapatkan Alamat IP Gateway Masuk ASM" dari topik Integrasi KServe dengan ASM untuk Mengimplementasikan Layanan Inferensi Berdasarkan Model AI Cloud-Native.
Jalankan perintah berikut untuk mengonfigurasi variabel lingkungan.
xxx.xxx.xxx.xxx adalah alamat IP yang diperoleh di sublangkah 1.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```

Jalankan perintah berikut untuk mengakses gateway masuk berulang kali:

for i in {1..100}; do curl http://${ASM_GATEWAY_IP}/mock; echo ''; sleep 1; done;

Output yang Diharapkan:

-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
...

Output menunjukkan bahwa aplikasi mock mencakup tiga Services, yaitu mocka, mockb, dan mockc. Setiap Service memiliki dua versi, v1 dan v2. Tiga Services dipanggil dalam urutan berikut: mocka > mockb > mockc. Permintaan dikirim ke versi v1 dan v2 aplikasi mock dengan rasio hampir 1:1. Selain itu, versi v1 dan v2 dari Services dipanggil secara independen. Rilis canary ujung ke ujung diimplementasikan sesuai harapan.

Operasi terkait

Publikasikan versi baru dari sebuah Service

Gambar berikut menunjukkan struktur file repositori Git sampel yang digunakan dalam contoh ini.

File	Deskripsi
mock-v1.yaml mock-v2.yaml	Menentukan penyebaran v1 dan v2 dari Services mocka, mockb, dan mockc.
swimlanegroup.yaml	Menentukan grup jalur. Grup jalur terkait dengan satu atau lebih jalur. Grup jalur mendefinisikan informasi yang dibagi di antara beberapa jalur lalu lintas. Informasi tersebut mencakup `services` dan `ingress`. Bidang services menentukan Services untuk mana jalur lalu lintas perlu dibuat. Bidang ingress menentukan gateway Istio melalui mana Services di grup jalur diakses.
swimlanes.yaml	Menentukan jalur. Dua CRD ASMSwimLane digunakan untuk mendefinisikan dua jalur untuk Services v1 dan v2. Bidang `labelSelector` digunakan untuk membedakan versi berbeda dari Services di sebuah jalur.
mock-route.yaml	Menentukan gateway Istio dan layanan virtual yang berlaku untuk gateway masuk. Sumber daya ini mengontrol cara gateway masuk meneruskan permintaan ke Services di sebuah jalur.

Untuk menerbitkan versi baru dari sebuah Service, Anda dapat membuat fork cabang argocd-asm repositori Git sampel https://github.com/AliyunContainerService/asm-labs.git, memodifikasi sumber daya YAML sebelumnya di jalur argo-cd/swimlane, dan kemudian mengirimkan modifikasi ke repositori Git jarak jauh. Setelah Anda mengirimkan modifikasi, Argo CD secara otomatis menyinkronkan perubahan di repositori Git. Anda harus memasukkan URL repositori Git yang difork di bidang Repository URL di Langkah 1.

Sebagai contoh, Anda menerbitkan versi v3 dari Services mocka, mockb, dan mockc. Anda harus melakukan modifikasi berikut pada sumber daya YAML di repositori Git:

Buat file argo-cd/swimlane/mock-v3.yaml.

File YAML mendefinisikan penyebaran versi v3 dari Services mocka, mockb, dan mockc.

Tampilkan Kode YAML

apiVersion: apps/v1
kind: Deployment
metadata:
 name: mocka-v3
 labels:
 app: mocka
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mocka
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mocka
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mocka
 - name: upstream_url
 value: "http://mockb:8000/"
 ports:
 - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: mockb-v3
 labels:
 app: mockb
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mockb
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mockb
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mockb
 - name: upstream_url
 value: "http://mockc:8000/"
 ports:
 - containerPort: 8000

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: mockc-v3
 labels:
 app: mockc
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mockc
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mockc
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mockc
 ports:
 - containerPort: 8000

Ubah konten di file argo-cd/swimlane/swimlanes.yaml menjadi kode YAML di blok kode berikut.

Dalam contoh ini, sebuah CRD ASMSwimLane bernama v3 ditambahkan ke file. CRD ASMSwimLane tersebut terkait dengan CRD ASMSwimLaneGroup bernama mock dan menentukan bahwa pod dengan label version:v3 menjalankan Services v3.

Tampilkan Kode YAML

apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v1
spec:
 labelSelector:
 version: v1
---
apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v2
spec:
 labelSelector:
 version: v2
---
apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v3
spec:
 labelSelector:
 version: v3

Ubah konten di file argo-cd/swimlane/mock-route.yaml menjadi kode YAML di blok kode berikut.

Dalam contoh ini, layanan virtual bernama mock di file dimodifikasi untuk menambahkan Service mocka versi v3 ke tujuan rute. Bidang subset menentukan nama jalur lalu lintas. Bidang weight di layanan virtual dimodifikasi. Rasio untuk rilis canary Services v1, v2, dan v3 diubah menjadi 6:3:1.

Tampilkan Kode YAML

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
 name: ingressgateway
 namespace: istio-system
spec:
 selector:
 istio: ingressgateway
 servers:
 - port:
 number: 80
 name: http
 protocol: HTTP
 hosts:
 - '*'
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 name: mock
 namespace: istio-system
spec:
 gateways:
 - ingressgateway
 hosts:
 - '*'
 http:
 - match:
 - uri:
 exact: /mock
 route:
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v1
 weight: 60
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v2
 weight: 30
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v3
 weight: 10