Implementasikan rilis canary untuk layanan inferensi berdasarkan NGINX Ingress controller - Container Service for Kubernetes

Dalam mode Raw Deployment, Anda dapat mengimplementasikan rilis canary untuk aplikasi berdasarkan gateway. Topik ini menjelaskan cara mengimplementasikan rilis canary untuk layanan inferensi dan memperbarui layanan inferensi dari versi v1 ke v2. Dalam contoh ini, NGINX Ingress controller digunakan sebagai gateway.

Prasyarat

Komponen ack-kserve telah diinstal.
Klien Arena telah diinstal.

Prosedur

Topik ini menjelaskan dua kebijakan rilis canary untuk meningkatkan layanan inferensi dari v1 ke v2:

Pembagian trafik berdasarkan permintaan
Arahkan permintaan yang foo headers disetel ke bar ke model-v2-svc Service. Permintaan lainnya secara default diarahkan ke model-svc Service.
Pembagian trafik berdasarkan bobot Service
Arahkan 20% permintaan ke model-v2-svc Service dan sisa permintaan ke model-svc Service.

Untuk informasi lebih lanjut tentang cara menggunakan NGINX Ingress controller untuk mengimplementasikan rilis canary, lihat Gunakan NGINX Ingress controller untuk mengimplementasikan rilis canary dan rilis blue-green.

Langkah 1: Terapkan dan verifikasi layanan inferensi

v1

Terapkan layanan inferensi v1 dari model canary.

arena serve kserve \
    --name=model-v1 \
    --image=kube-ai-registry.cn-shanghai.cr.aliyuncs.com/ai-sample/kserve-canary:1.0.0 \
    --cpu=1 \
    --memory=2Gi \
    "python app.py --model_name=canary"

Buat Service untuk layanan inferensi v1.

Buat file bernama model-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: model-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    serving.kserve.io/inferenceservice: model-v1
  type: ClusterIP

Buat Service.
```
kubectl apply -f model-svc.yaml
```

Akses layanan inferensi bernama model-v1 menggunakan NGINX Ingress untuk memverifikasi apakah model-v1 telah diterapkan dengan benar.

curl -H "Host: $(kubectl get inferenceservice model-v1 -o jsonpath='{.status.url}' | cut -d "/" -f 3)" \
     -H "Content-Type: application/json" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'

v2

Terapkan layanan inferensi v2 dari model canary.

arena serve kserve \
    --name=model-v2 \
    --image=kube-ai-registry.cn-shanghai.cr.aliyuncs.com/ai-sample/kserve-canary:1.0.0 \
    --cpu=1 \
    --memory=2Gi \
    "python app-v2.py --model_name=canary"

Buat Service untuk layanan inferensi v2.

Buat file bernama model-v2-svc.yaml.

apiVersion: v1
kind: Service
metadata:
  name: model-v2-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    serving.kserve.io/inferenceservice: model-v2
  type: ClusterIP

Buat Service.
```
kubectl apply -f model-v2-svc.yaml
```

Akses layanan inferensi bernama model-v2 menggunakan NGINX Ingress untuk memverifikasi apakah model-v2 telah diterapkan dengan benar.

curl -H "Host: $(kubectl get inferenceservice model-v2 -o jsonpath='{.status.url}' | cut -d "/" -f 3)" \
     -H "Content-Type: application/json" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'

Langkah 2: Buat Ingress

Buat file bernama model-ingress.yaml.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: model-ingress
spec:
  rules:
  - host: model.example.com # Ganti nilai ini dengan nama host Anda. 
    http:
      paths:
      # Informasi tentang Service yang dibuat untuk layanan inferensi v1. 
      - path: /
        backend:
          service: 
            name: model-svc
            port:
              number: 80
        pathType: ImplementationSpecific

Buat Ingress.
```
kubectl apply -f model-ingress.yaml
```

Langkah 3: Buat dan verifikasi kebijakan rilis canary

Skenario 1: Pembagian trafik berdasarkan permintaan klien

Buat file bernama gray-release-canary.yaml.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary. 
    nginx.ingress.kubernetes.io/canary: "true"
    # Set header permintaan ke foo. 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Set header foo ke bar. Dalam hal ini, permintaan yang memiliki header foo disetel ke bar akan dirutekan ke versi layanan baru (model-v2). 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
spec:
  rules:
  - host: model.example.com
    http:
      paths:
      # Informasi tentang Service yang dibuat untuk model-v2. 
      - path: /
        backend:
          service: 
            name: model-v2-svc
            port:
              number: 80
        pathType: ImplementationSpecific

Terapkan kebijakan rilis canary.

kubectl apply -f gray-release-canary.yaml

Periksa apakah Service versi default mengembalikan respons untuk permintaan tanpa header spesifik.

# Ganti nama host dalam kode sampel berikut dengan nama host yang ditentukan dalam Ingress. 
curl -H "Host: model.example.com" -H "Content-Type: application/json" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'

Keluaran yang diharapkan:

{"id":"4d8c110d-c291-4670-ad0a-1a30bf8e314c","model_name":"canary","model_version":null,"outputs":[{"name":"output-0","shape":[1,1],"datatype":"STR","data":["model-v1"]}]}%

Keluaran menunjukkan bahwa model-v1 mengembalikan respons. Ini menunjukkan bahwa layanan dapat mengembalikan hasil inferensi untuk permintaan yang dikirim ke model-v1 sesuai harapan secara default. Dalam hal ini, trafik diarahkan ke model-v1.

Jalankan perintah berikut untuk memverifikasi apakah permintaan klien yang foo headers disetel ke bar diarahkan ke model-v2.

curl -H "Host: model.example.com" -H "Content-Type: application/json" \
     -H "foo: bar" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'

Keluaran yang diharapkan:

{"id":"4d3efc12-c8bd-40f8-898f-7983377db7bd","model_name":"canary","model_version":null,"outputs":[{"name":"output-0","shape":[1,1],"datatype":"STR","data":["model-v2"]}]}%

Keluaran menunjukkan bahwa model-v2 mengembalikan respons. Ini menunjukkan bahwa layanan dapat mengembalikan hasil inferensi untuk permintaan dengan header spesifik yang dikirim ke model-v2 sesuai harapan. Kebijakan rilis canary telah berlaku.

Skenario 2: Pembagian trafik berdasarkan bobot Service

Buat file bernama gray-release-canary.yaml.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary. 
    nginx.ingress.kubernetes.io/canary: "true"
    # Arahkan hanya 20% permintaan ke model-v2. 
    # Total bobot default adalah 100. 
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  rules:
  - host: model.example.com
    http:
      paths:
      # Informasi tentang Service yang dibuat untuk layanan inferensi v2. 
      - path: /
        backend:
          service: 
            name: model-v2-svc
            port:
              number: 80
        pathType: ImplementationSpecific

Terapkan kebijakan rilis canary.

kubectl apply -f gray-release-canary.yaml

Periksa distribusi trafik.
```
curl -H "Host: model.example.com" -H "Content-Type: application/json" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'
```
Jalankan perintah sebelumnya beberapa kali. Hasilnya menunjukkan bahwa sekitar 20% permintaan diarahkan ke model-v2, dan sisanya diarahkan ke versi layanan sebelumnya (model-v1). Ini menunjukkan bahwa kebijakan rilis canary telah berlaku.

Langkah 4: Alihkan trafik ke versi layanan baru

Jika model-v2 berjalan seperti yang diharapkan selama periode waktu tertentu, Anda perlu membawa model-v2 offline dan menyediakan hanya versi layanan baru untuk akses.

Perbarui file model-svc.yaml untuk menentukan model-v2 sebagai aplikasi backend dari Service model-svc.

apiVersion: v1
kind: Service
metadata:
  name: model-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    serving.kserve.io/inferenceservice: model-v2 # Ganti model-v1 dengan model-v2. 
  type: ClusterIP

Jalankan perintah berikut untuk menerapkan ulang Service:
```
kubectl apply -f model-svc.yaml 
```

Uji akses ke Ingress.

curl -H "Host: model.example.com" -H "Content-Type: application/json" \
     http://$(kubectl -n kube-system get svc nginx-ingress-lb -ojsonpath='{.status.loadBalancer.ingress[0].ip}'):80/v1/models/canary:predict -X POST \
     -d '{"data": "test"}'

Keluaran yang diharapkan:

{"id":"a13f2089-73ce-41e3-989e-e58457d14fed","model_name":"canary","model_version":null,"outputs":[{"name":"output-0","shape":[1,1],"datatype":"STR","data":["model-v2"]}]}%

Jalankan perintah sebelumnya beberapa kali. Hasilnya menunjukkan bahwa sekitar 100% permintaan diarahkan ke model-v2.

Jalankan perintah berikut untuk menghapus model-v1 dan sumber daya terkait:

kubectl delete ingress gray-release-canary
arena serve delete model-v1
kubectl delete svc model-v2-svc