Container Service for Kubernetes：Praktik Terbaik untuk Penyebaran Layanan Inferensi AI di Knative

Penerapan model yang dipercepat

Untuk memastikan layanan inferensi AI di Knative Serving dapat diskalakan dengan cepat sesuai permintaan, hindari pengemasan model AI dalam gambar kontainer. Pengemasan ini meningkatkan ukuran gambar kontainer secara signifikan, memperlambat penyebaran, serta membuat kontrol versi lebih kompleks karena versi model AI terikat pada versi gambar kontainer.

Sebagai solusi, unggah semua data terkait model AI ke sistem penyimpanan eksternal seperti Object Storage Service (OSS) atau File Storage NAS (NAS). Buat klaim volume persisten (PVC) untuk memasang sistem penyimpanan ke pod Knative. Anda juga dapat menggunakan Fluid, mesin orkestrasi dan akselerasi dataset terdistribusi, untuk mempercepat penarikan dan pemuatan model AI, sehingga memungkinkan pemuatan model bahasa besar dalam beberapa detik. Untuk informasi lebih lanjut, lihat Gunakan JindoFS untuk Mempercepat Akses ke OSS dan Gunakan EFC untuk Mempercepat Akses ke Sistem File NAS.

Prasyarat

• Knative telah diterapkan di kluster Anda. Untuk informasi lebih lanjut, lihat Terapkan dan Kelola Knative.

• Komponen ack-fluid telah diinstal. Untuk informasi lebih lanjut, lihat Terapkan Suite AI Cloud-Native.

• Bucket OSS telah dibuat. Untuk informasi lebih lanjut, lihat Buat Bucket.

Langkah 1: Tentukan Dataset

Jika model AI disimpan di OSS, buat CustomResource Dataset (CR) untuk mendeklarasikan dataset model di OSS dan gunakan JindoRuntime untuk menjalankan tugas caching.

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: your_ak_id   # Ganti dengan ID AccessKey yang digunakan untuk mengakses OSS.
  fs.oss.accessKeySecret: your_ak_skrt   # Ganti dengan Rahasia AccessKey yang digunakan untuk mengakses OSS.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: oss-data
spec:
  mounts:
  - mountPoint: "oss://{Bucket}/{path-to-model}" # Ganti dengan bucket OSS dan jalur OSS tempat model disimpan.
    name: xxx
    path: "{path-to-model}" # Ganti dengan jalur model yang akan dimuat.
    options:
      fs.oss.endpoint: "oss-cn-beijing.aliyuncs.com"  # Ganti dengan titik akhir bucket OSS.
    encryptOptions:
      - name: fs.oss.accessKeyId
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeyId
      - name: fs.oss.accessKeySecret
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeySecret
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: oss-data
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: emptyDir
        path: /mnt/ssd0/cache
        quota: 100Gi
        high: "0.95"
        low: "0.7"
  fuse:
    properties:
      fs.jindofsx.data.cache.enable: "true"
    args:
      - -okernel_cache
      - -oro
      - -oattr_timeout=7200
      - -oentry_timeout=7200
      - -ometrics_port=9089
    cleanPolicy: OnDemand

Langkah 2: Pasang PVC untuk mempercepat akses ke OSS

Setelah mendeklarasikan Dataset CR dan JindoRuntime CR, sistem secara otomatis membuat PVC dengan nama yang sama dengan Dataset dan memasangnya ke Layanan Knative untuk mempercepat akses ke OSS.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: sd-backend
spec:
  template:
    spec:
      containers:
        - image: <YOUR-IMAGE>   # Ganti <YOUR-IMAGE> dengan nama gambar.
          name: image-name
          ports:
            - containerPort: xxx
              protocol: TCP
          volumeMounts:
            - mountPath: /data/models  # Jalur model yang akan dimuat. Ganti dengan nilai moutPath.
              name: data-volume
      volumes:
        - name: data-volume
          persistentVolumeClaim:
            claimName: oss-data   # Pasang PVC dengan nama yang sama dengan Dataset.

Langkah 3: Terapkan model dalam hitungan detik menggunakan cache gambar

Selain ukuran model AI, pertimbangkan dampak ukuran gambar kontainer pada Layanan Knative. Gambar kontainer yang digunakan untuk menjalankan model AI biasanya dikemas dengan dependensi seperti CUDA dan pytorch-gpu, meningkatkan ukurannya. Saat menerapkan layanan inferensi AI Knative di pod pada instance kontainer elastis, gunakan cache gambar untuk mempercepat penarikan gambar. Cache gambar dibuat sebelumnya sehingga sistem dapat menarik gambar dalam hitungan detik. Untuk informasi lebih lanjut, lihat Gunakan ImageCache untuk Mempercepat Pembuatan Instance Kontainer Elastis.

apiVersion: eci.alibabacloud.com/v1
kind: ImageCache
metadata:
  name: imagecache-ai-model
  annotations:
    k8s.aliyun.com/eci-image-cache: "true" # Aktifkan penggunaan ulang cache gambar.
spec:
  images:
  - <YOUR-IMAGE>
  imageCacheSize:
    25 # Ukuran setiap cache gambar. Unit: GiB.
  retentionDays:
    7 # Periode retensi cache gambar.

Penutupan pod yang lancar

Untuk memastikan permintaan yang sedang berlangsung tidak terganggu, pod harus ditutup dengan cara tertentu setelah menerima sinyal SIGTERM.

• Jika aplikasi menggunakan probing HTTP, setelah pod menerima sinyal SIGTERM, pod memasuki status Not Ready agar permintaan baru tidak diteruskan ke pod tersebut.

• Selama proses penutupan pod, queue-proxy Knative mungkin masih meneruskan permintaan ke pod. Kami sarankan mengatur parameter timeoutSeconds menjadi 1,2 kali periode timeout maksimum untuk memastikan semua permintaan diproses sebelum pod ditutup. Misalnya, jika periode timeout maksimum adalah 10 detik, atur parameter timeoutSeconds menjadi 12 detik.

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: helloworld-go
    namespace: default
  spec:
    template:
      spec:
        timeoutSeconds: 12

Konfigurasikan parameter konkurensi

Mengonfigurasi parameter konkurensi dapat meningkatkan kinerja dan kecepatan respons Layanan Knative secara signifikan. Pengaturan konkurensi yang tepat memungkinkan aplikasi menangani sejumlah besar permintaan konkuren lebih efisien, meningkatkan kualitas layanan dan pengalaman pengguna.

• Batas konkurensi keras: Batas konkurensi keras adalah batas atas yang diberlakukan. Saat tingkat konkurensi mencapai batas keras, permintaan berlebih dicache hingga ada sumber daya yang cukup.

• Batas konkurensi lunak: Batas konkurensi lunak bukan batasan ketat. Saat jumlah permintaan melonjak, tingkat konkurensi mungkin melebihi batas lunak.

• Target pemanfaatan: Dibandingkan dengan target, anotasi autoscaling.knative.dev/target-utilization-percentage merupakan cara yang lebih langsung untuk menentukan tingkat konkurensi. Atur anotasi ini ke nilai mendekati 100% agar permintaan konkuren diproses secara efisien.

Untuk informasi lebih lanjut, lihat Konfigurasikan Batas Konkurensi Lunak.

Penskalaan otomatis

Sebelum mengonfigurasi penskalaan otomatis, tetapkan tujuan seperti mengurangi latensi, meminimalkan biaya, dan menangani lonjakan lalu lintas. Perkirakan waktu peluncuran pod dalam skenario yang diinginkan, karena metrik ini dapat digunakan sebagai dasar penskalaan otomatis.

Untuk informasi lebih lanjut tentang parameter, lihat Aktifkan Penskalaan Otomatis untuk Menahan Fluktuasi Lalu Lintas.

Mode penskalaan

Penskalaan otomatis bekerja dalam dua mode: mode stabil dan mode panik. Mode stabil cocok untuk operasi reguler, sementara mode panik cocok untuk menciptakan pod dengan cepat untuk menangani lonjakan lalu lintas.

Jendela stabil

Untuk memastikan pod dapat diskalakan sesuai harapan, jendela stabil harus lebih lama dari waktu rata-rata peluncuran pod. Kami sarankan mengatur jendela stabil menjadi dua kali waktu rata-rata.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/window: "40s"

Jendela panik

Jendela panik didefinisikan sebagai persentase dari jendela stabil dan biasanya menangani lonjakan lalu lintas yang tidak terduga.

• Misalnya, jika jendela stabil adalah 30 detik dan jendela panik adalah 10%, sistem memutuskan apakah akan memulai mode panik berdasarkan statistik yang dikumpulkan dalam 3 detik. Jika pod memerlukan 30 detik untuk diluncurkan, sistem mungkin terus menerapkan pod saat pod yang baru dibuat masih diluncurkan, mengakibatkan pod berlebihan.

• Jangan ubah jendela panik sebelum mengubah parameter lain dan memastikan aktivitas penskalaan dilakukan sesuai harapan, terutama saat jendela panik sama dengan atau lebih pendek dari waktu peluncuran pod. Jika jendela stabil dua kali waktu peluncuran pod rata-rata, atur jendela panik menjadi 50% sebagai batas antara mode stabil dan mode panik.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-window-percentage: "20.0"

Ambang mode panik mendefinisikan rasio lalu lintas arah masuk terhadap kapasitas layanan. Ubah ambang berdasarkan nilai puncak lalu lintas dan latensi yang dapat ditoleransi. Nilai awal adalah 200% atau lebih tinggi sampai mode stabil dimulai. Anda dapat mengubah ambang setelah aplikasi berjalan selama periode tertentu.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-threshold-percentage: "150.0"

Tingkat penskalaan

Anda dapat menyesuaikan tingkat penskalaan naik dan penskalaan turun untuk mengontrol penskalaan pod dengan lebih baik. Tingkat penskalaan default memenuhi persyaratan dalam sebagian besar skenario. Sebelum mengubah tingkat penskalaan, amati status saat ini, uji tingkat penskalaan baru di lingkungan staging, dan evaluasi dampaknya.

Tingkat penskalaan naik

Jangan ubah tingkat penskalaan naik kecuali perlu menyelesaikan masalah tertentu. Misalnya, ubah tingkat penskalaan naik jika waktu peluncuran pod lama karena pod yang baru dibuat perlu menunggu sumber daya. Jika aktivitas penskalaan sering dipicu, Anda mungkin juga perlu mengubah parameter lain, seperti jendela stabil atau jendela panik.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-up-rate: "500.0"

Tingkat penskalaan turun

Atur tingkat penskalaan turun ke waktu peluncuran pod rata-rata atau lebih lama. Tingkat penskalaan turun default memenuhi persyaratan dalam sebagian besar skenario. Namun, jika ingin mengurangi biaya, Anda dapat meningkatkan tingkat penskalaan turun untuk dengan cepat menghapus pod saat volume lalu lintas turun.

Tingkat penskalaan turun adalah rasio. Misalnya, N/2 berarti pod diskalakan menjadi setengah dari jumlah saat ini saat siklus penskalaan berakhir. Untuk Layanan yang hanya menjalankan sejumlah kecil pod, kurangi tingkat penskalaan turun untuk mempertahankan sejumlah pod tertentu, meningkatkan stabilitas sistem dan menghindari penskalaan yang sering.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-down-rate: "4.0"

Penundaan penskalaan turun

Atur penundaan penskalaan turun untuk mencegah autoscaler sering membuat pod saat permintaan baru diterima. Ini membantu menyelesaikan masalah pod merespons permintaan dengan penundaan.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: "2m" // Aktivitas penskalaan turun dilakukan dengan penundaan dua menit.

Batas penskalaan

Batas penskalaan terkait dengan skala bisnis dan ketersediaan sumber daya.

Batas bawah

autoscaling.knative.dev/min-scale mengontrol jumlah minimum replika untuk setiap revisi. Knative akan menjaga jumlah replika sama dengan atau lebih besar dari batas bawah. Untuk Layanan yang jarang diakses tetapi harus tersedia konstan, atur batas bawah menjadi 1. Untuk Layanan yang mungkin mengalami lonjakan lalu lintas, atur batas bawah menjadi nilai lebih besar dari 1. Jika ingin replika diskalakan menjadi nol saat tidak ada permintaan, atur batas bawah menjadi 0.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"

Batas atas

Nilai autoscaling.knative.dev/max-scale tidak boleh melebihi jumlah sumber daya yang tersedia. Batas atas membatasi biaya sumber daya maksimum.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "3"

Skala awal

Atur skala awal menjadi 1,2 kali jumlah pod saat ini sehingga lalu lintas dapat didistribusikan ke versi baru.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/initial-scale: "3"

Berbagi GPU

Didukung oleh fitur berbagi GPU dari Container Service for Kubernetes (ACK), Layanan Knative dapat memanfaatkan sepenuhnya kemampuan isolasi memori GPU cGPU untuk meningkatkan pemanfaatan sumber daya GPU.

Untuk berbagi GPU di Knative, atur limits ke aliyun.com/gpu-mem untuk Layanan Knative. Contoh:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 1
      containers:
      - image: registry-vpc.cn-hangzhou.aliyuncs.com/demo-test/test:helloworld-go
        name: user-container
        ports:
        - containerPort: 6666
          name: http1
          protocol: TCP
        resources:
          limits:
            aliyun.com/gpu-mem: "3"

Probes

Anda dapat mengonfigurasi liveness probe dan readiness probe untuk memantau status kesehatan dan ketersediaan Layanan Knative. Dibandingkan dengan kebijakan probing Kubernetes, Knative memantau Layanan lebih sering untuk meminimalkan waktu mulai dingin pod.

• Liveness probe: Digunakan untuk memantau status kesehatan kontainer. Jika kontainer berada dalam status Gagal atau layanan di dalam kontainer gagal diluncurkan, liveness probe memulai ulang kontainer.

• Readiness probe: Digunakan untuk mengelola penskalaan otomatis aplikasi secara efisien, memastikan hanya pod dalam status Siap yang dapat menerima lalu lintas, meningkatkan stabilitas dan kecepatan respons layanan.

  • Probe TCP tidak membuka port mendengarkan sampai semua komponen dimuat dan kontainer siap.

  • Probe HTTP tidak menandai Layanan sebagai siap sampai titik akhir Layanan siap menangani permintaan.

  • Atur periodSeconds (interval probing) ke nilai kecil. Dalam kebanyakan kasus, tentukan interval probing lebih pendek dari nilai default 10 detik.

Untuk informasi lebih lanjut tentang probing port dan praktik terbaik, lihat Konfigurasikan Probing Port di Knative.

Skala ke nol

Knative dapat menskalakan pod Layanan menjadi nol saat Layanan tidak aktif.

Jika Anda perlu mengelola beberapa model, kami sarankan membuat Layanan Knative untuk setiap model untuk menyederhanakan logika bisnis di setiap Layanan.

• Fitur skala ke nol Knative dapat mencegah model yang tidak aktif menimbulkan biaya sumber daya.

• Saat klien mengakses model untuk pertama kalinya, Knative mulai menskalakan dari nol.

Untuk informasi lebih lanjut tentang skala ke nol dan praktik terbaik, lihat Konfigurasikan Instance Cadangan.

Rilis canary

Knative dapat memastikan kontinuitas bisnis selama peluncuran versi baru. Saat memperbarui kode atau memodifikasi Layanan, Knative terus menjalankan versi lama sampai versi baru siap.

Anda dapat menentukan persentase lalu lintas yang didistribusikan ke versi baru. Persentase lalu lintas adalah parameter kunci yang menentukan waktu Knative beralih lalu lintas dari versi lama ke versi baru. Anda dapat mengatur persentase lalu lintas dalam rentang 10% hingga 100%. Saat tidak lagi memerlukan versi lama, atur persentase menjadi 100%. Versi lama dihentikan segera setelah versi baru siap.

Batasi kecepatan penskalaan turun versi lama saat melakukan operasi batch dengan jumlah pod terbatas. Misalnya, jika Layanan menjalankan 500 pod dan hanya 300 pod tambahan yang tersedia, mengatur persentase lalu lintas ke nilai besar dapat menyebabkan beberapa fitur Layanan tidak tersedia.

Untuk informasi lebih lanjut tentang rilis canary dan praktik terbaik, lihat Lakukan Rilis Canary Berdasarkan Pemisahan Lalu Lintas.

Kolokasi instance ECS dan instance kontainer elastis

Anda dapat mengonfigurasi ResourcePolicies untuk menggunakan instance Elastic Compute Service (ECS) selama jam-jam sepi dan instance kontainer elastis selama jam-jam sibuk.

• Selama proses penskalaan naik, pod Knative diprioritaskan untuk dijadwalkan ke instance ECS. Saat jumlah pod melebihi batas atas yang telah ditentukan atau instance ECS habis stok, pod baru dijadwalkan ke instance kontainer elastis.

• Selama proses penskalaan turun, pod pada instance kontainer elastis diprioritaskan untuk dihapus.

Untuk informasi lebih lanjut tentang kolokasi dan praktik terbaik, lihat Kolokasi Instance ECS dan Instance Kontainer Elastis di Knative.