Secara otomatis mengatur skala layanan Knative berdasarkan permintaan traffic - Alibaba Cloud Service Mesh

Saat traffic ke Layanan Knative Anda berfluktuasi, jumlah pod tetap dapat menyebabkan pemborosan sumber daya saat traffic rendah atau penurunan performa saat terjadi lonjakan. Knative Pod Autoscaler (KPA) pada ASM mengatasi masalah ini dengan memantau konkurensi permintaan secara real-time melalui sidecar Queue Proxy di setiap pod dan secara otomatis menyesuaikan jumlah pod—meningkatkan skala saat terjadi lonjakan traffic dan menurunkan skala (termasuk hingga nol) selama periode tidak aktif.

Prasyarat

Layanan Knative yang telah dideploy melalui Knative pada ASM. Untuk detailnya, lihat Gunakan Knative pada ASM untuk deploy aplikasi serverless.

Catatan

Topik ini menggunakan nama domain default example.com sebagai contoh. Untuk menggunakan nama domain kustom, lihat Atur nama domain kustom di Knative pada ASM.

Cara kerja KPA

Knative Serving menyuntikkan kontainer Queue Proxy ke dalam setiap pod. Queue Proxy melacak permintaan yang sedang diproses dan melaporkan metrik konkurensi ke KPA. Berdasarkan metrik tersebut, KPA menghitung jumlah pod yang diinginkan dan mengatur skala Deployment yang mendasarinya.

Konkurensi vs. QPS

Metric	Definisi
Concurrency	Jumlah permintaan yang ditangani oleh satu pod secara simultan
QPS	Jumlah permintaan yang diselesaikan oleh satu pod per detik (throughput maksimum)

Konkurensi yang lebih tinggi tidak selalu meningkatkan QPS. Di bawah beban berat, peningkatan konkurensi justru dapat menurunkan QPS karena persaingan CPU dan memori meningkatkan latensi respons.

Algoritma autoscaling

KPA mengatur skala pod berdasarkan rata-rata jumlah permintaan konkuren per pod. Secara default, setiap pod menargetkan konkurensi sebesar 100 permintaan. KPA beroperasi dalam dua mode:

Mode stabil

KPA merata-ratakan konkurensi di semua pod selama jendela stabil (default: 60 detik) dan menyesuaikan jumlah pod agar mencapai target konkurensi.

Mode panik

KPA merata-ratakan konkurensi selama jendela panik yang lebih pendek (default: 6 detik). Jendela panik dihitung sebagai:

Panic window = Stable window x panic-window-percentage

Nilai default panic-window-percentage adalah 10 (10% dari jendela stabil). Nilai valid: 1 hingga 100. Saat konkurensi yang diamati melebihi persentase ambang batas panik (default: 200%), KPA secara cepat meningkatkan skala untuk menyerap lonjakan tersebut.

                                                    |
                                Panic Target--->  +--| 20
                                                  |  |
                                                  | <------Panic Window (6s)
                                                  |  |
     Stable Target--->  +-------------------------|--| 10
CONCURRENCY             |                         |  |
                        |                      <-----------Stable Window (60s)
                        |                         |  |
--------------------------+-------------------------+--+ 0
120                       60                           0
                       TIME (seconds)

Konfigurasi KPA secara global

Konfigurasikan KPA melalui ConfigMap config-autoscaler di namespace knative-serving. Jalankan perintah berikut untuk melihat konfigurasi saat ini:

kubectl -n knative-serving get cm config-autoscaler -o yaml

Struktur ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  _example:
    container-concurrency-target-default: "100"   # Target konkurensi lunak per pod
    container-concurrency-target-percentage: "0.7" # Faktor utilisasi untuk pemicu penskalaan
    enable-scale-to-zero: "true"                   # Izinkan penskalaan hingga nol pod
    max-scale-up-rate: "1000"                      # Pengali maksimum penskalaan naik per siklus evaluasi
    max-scale-down-rate: "2"                       # Pengali maksimum penskalaan turun per siklus evaluasi
    panic-window-percentage: "10"                  # Jendela panik sebagai % dari jendela stabil
    panic-threshold-percentage: "200"              # Persentase konkurensi yang memicu mode panik
    scale-to-zero-grace-period: "30s"              # Waktu maksimum pod terakhir berjalan sebelum diskalakan ke nol
    scale-to-zero-pod-retention-period: "0s"       # Waktu minimum pod terakhir tetap aktif setelah keputusan penskalaan ke nol
    stable-window: "60s"                           # Jendela waktu untuk perata-rataan mode stabil
    target-burst-capacity: "200"                   # Kapasitas tambahan yang dicadangkan untuk lonjakan traffic
    requests-per-second-target-default: "200"      # Target RPS default (saat menggunakan metrik RPS)

Nilai-nilai di bawah _example merupakan nilai default. Untuk mengubah parameter, salin dari _example ke bidang data.

Catatan

Perubahan pada ConfigMap config-autoscaler berlaku untuk semua Layanan Knative dalam mesh. Untuk mengonfigurasi autoscaling untuk satu layanan saja, gunakan anotasi per-Revision. Lihat Atur target konkurensi dan Atur batas skala.

Parameter scale-to-zero

Parameter	Anotasi per Revisi	Default	Deskripsi
`enable-scale-to-zero`	N/A (hanya global)	`true`	Izinkan penskalaan ke nol pod saat tidak ada traffic
`scale-to-zero-grace-period`	N/A (hanya global)	`30s`	Waktu maksimum Revision tidak aktif tetap berjalan sebelum KPA menskalakan pod ke nol. Minimum: 30 detik
`scale-to-zero-pod-retention-period`	N/A (hanya global)	`0s`	Waktu minimum pod terakhir tetap aktif setelah KPA memutuskan untuk menskalakan ke nol
`stable-window`	`autoscaling.knative.dev/window`	`60s`	Jendela waktu untuk merata-ratakan konkurensi dalam mode stabil

Atur target konkurensi

KPA mendukung dua jenis batas konkurensi:

Batas lunak (direkomendasikan): Target yang digunakan KPA untuk menghitung jumlah pod yang diinginkan. Selama lonjakan tiba-tiba, konkurensi aktual dapat sementara melebihi nilai ini.
Batas keras: Batas atas yang diberlakukan. Permintaan yang melebihi batas ini akan dibuffer hingga kapasitas tersedia.

Peringatan

Gunakan batas keras hanya jika aplikasi Anda memerlukan kontrol konkurensi yang ketat. Nilai batas keras yang rendah dapat meningkatkan latensi dan menyebabkan cold start.

Parameter	Anotasi per-Revision	Default	Deskripsi
`container-concurrency-target-default`	`autoscaling.knative.dev/target`	`100`	Target konkurensi lunak per pod
`containerConcurrency`	N/A (diatur dalam spesifikasi Revision)	`0` (tidak terbatas)	Batas konkurensi keras per pod. `0` = tidak terbatas, `1` = satu permintaan dalam satu waktu, `2-N` = batas spesifik
`container-concurrency-target-percentage`	N/A (hanya global)	`0.7`	Faktor utilisasi. Penskalaan dipicu pada: target konkurensi x persentase ini. Contoh: `100 x 0.7 = 70` — KPA menambah pod saat rata-rata konkurensi mencapai 70

Atur batas skala

Gunakan anotasi minScale dan maxScale untuk mengontrol jumlah minimum dan maksimum pod untuk suatu Revision. Hal ini membantu mengurangi cold start dan mengendalikan biaya.

Anotasi	Perilaku default	Deskripsi
`autoscaling.knative.dev/minScale`	Semua pod dihapus saat tidak aktif	Jumlah minimum pod yang tetap berjalan
`autoscaling.knative.dev/maxScale`	Tidak ada batas atas	Jumlah maksimum pod yang diizinkan

Tambahkan anotasi ini dalam templat Revision:

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

Catatan

Jika minScale tidak diatur, semua pod dihapus saat tidak ada traffic (dengan asumsi scale-to-zero diaktifkan).
Jika maxScale tidak diatur, jumlah pod tidak terbatas.
Jika enable-scale-to-zero diatur ke false dalam ConfigMap, KPA tetap menjalankan minimal satu pod terlepas dari nilai minScale.

Parameter laju penskalaan

Parameter	Anotasi per-Revision	Default	Deskripsi
`max-scale-up-rate`	N/A (hanya global)	`1000`	Rasio maksimum peningkatan jumlah pod dalam satu siklus evaluasi. Misalnya, jika 1 pod sedang berjalan, KPA dapat menskalakan hingga maksimal 1000 pod dalam satu siklus
`max-scale-down-rate`	N/A (hanya global)	`2`	Rasio maksimum pengurangan jumlah pod dalam satu siklus evaluasi. Misalnya, jika 100 pod sedang berjalan, KPA dapat menskalakan turun hingga maksimal 50 pod dalam satu siklus

Penskalaan berdasarkan target konkurensi

Contoh ini mendeploy aplikasi autoscale-go dengan target konkurensi 10, lalu menggunakan uji beban untuk memverifikasi bahwa KPA menskalakan pod sesuai permintaan.

Catatan

Untuk detail tentang cara mendeploy Layanan Knative, lihat Gunakan Knative pada ASM untuk deploy aplikasi serverless.

Buat file bernama autoscale-go.yaml dengan target konkurensi 10:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"   # Skalakan saat rata-rata konkurensi melebihi 10 x 0.7 = 7
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

Deploy aplikasi:
```
    kubectl apply -f autoscale-go.yaml
```
Dapatkan alamat IP gerbang. Masuk ke Konsol ASM, klik nama instans ASM target, lalu pilih ASM Gateways > Ingress Gateway. Di halaman Ingress Gateway, temukan alamat IP pada bagian Service address.
Jalankan uji beban dengan 50 permintaan konkuren selama 30 detik. Ganti <gateway-ip> dengan alamat IP dari langkah sebelumnya. Untuk informasi cara mendapatkan alamat gateway, lihat Langkah 3: Kueri alamat gateway dalam Gunakan Knative pada ASM untuk deploy aplikasi serverless. Untuk informasi tentang tool uji beban, lihat hey.
```
    hey -z 30s -c 50 \
      -host "autoscale-go.default.example.com" \
      "http://<gateway-ip>?sleep=100&prime=10000&bloat=5"
```
Verifikasi hasilnya. KPA menskalakan aplikasi menjadi sekitar 7 pod. Dengan target konkurensi 10 dan faktor utilisasi default 70%, KPA mulai menambah pod saat rata-rata konkurensi per pod melebihi 7 (10 × 0,7). Penskalaan proaktif ini mencegah target konkurensi terlampaui saat volume permintaan meningkat.

Penskalaan dalam batas yang ditentukan

Contoh ini mendeploy aplikasi autoscale-go yang sama dengan batas skala untuk membatasi jumlah pod antara 1 dan 3.

Catatan

Untuk detail tentang cara mendeploy Layanan Knative, lihat Gunakan Knative pada ASM untuk deploy aplikasi serverless.

Buat file bernama autoscale-go.yaml dengan target konkurensi 10, minScale sebesar 1, dan maxScale sebesar 3:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"      # Target konkurensi per pod
            autoscaling.knative.dev/minScale: "1"      # Selalu pertahankan minimal 1 pod berjalan
            autoscaling.knative.dev/maxScale: "3"      # Jangan pernah melebihi 3 pod
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

Deploy aplikasi:
```
    kubectl apply -f autoscale-go.yaml
```
Dapatkan alamat IP gateway. Masuk ke Konsol ASM. Klik nama instans ASM target dan pilih ASM Gateways > Ingress Gateway. Pada halaman Ingress Gateway, temukan alamat IP di bagian Service address.
Jalankan uji beban dengan 50 permintaan konkuren selama 30 detik. Ganti <gateway-ip> dengan alamat IP dari langkah sebelumnya. Untuk informasi cara mendapatkan alamat gateway, lihat Langkah 3: Kueri alamat gateway dalam Gunakan Knative pada ASM untuk deploy aplikasi serverless. Untuk informasi tentang tool uji beban, lihat hey.
```
    hey -z 30s -c 50 \
      -host "autoscale-go.default.example.com" \
      "http://<gateway-ip>?sleep=100&prime=10000&bloat=5"
```
Verifikasi hasilnya. KPA menskalakan aplikasi hingga maksimum 3 pod selama uji beban. Saat traffic berhenti, 1 pod tetap berjalan (sesuai yang ditentukan oleh minScale). Batas skala mencegah over-provisioning sekaligus menghilangkan cold start.

Langkah berikutnya

Gunakan gateway ASM untuk mengakses Layanan Knative melalui HTTPS: Amankan titik akhir Layanan Knative Anda dengan transmisi terenkripsi.
Lakukan rilis canary berdasarkan pemisahan traffic untuk Layanan Knative menggunakan Knative pada ASM: Rilis versi baru secara bertahap dengan pemisahan traffic.
Gunakan HPA di Knative: Lakukan penskalaan berdasarkan utilisasi CPU, bukan konkurensi permintaan.