Model aplikasi Knative, juga dikenal sebagai Layanan Knative, menyederhanakan penyebaran dan pengelolaan layanan pada Kubernetes. Anda dapat menggunakannya untuk mengelola siklus hidup beban kerja.
Pengenalan
Layanan Knative adalah objek sumber daya yang dioperasikan langsung oleh pengguna. Sebuah Layanan Knative mencakup:
Konfigurasi: Menentukan konfigurasi beban kerja, termasuk gambar kontainer, variabel lingkungan, dan batasan sumber daya. Setiap modifikasi (seperti memperbarui versi gambar atau menyesuaikan variabel lingkungan) memicu revisi baru.
Revisi: Setiap pembaruan terhadap konfigurasi membuat Snapshot. Snapshot adalah revisi, yang melestarikan keadaan konfigurasi yang sesuai. Knative menggunakan revisi untuk manajemen aplikasi multi-versi.
Rute: Mengonfigurasi aturan routing untuk mendistribusikan lalu lintas ke beberapa revisi. Ini memungkinkan Anda mengonfigurasi persentase lalu lintas yang diteruskan ke revisi berbeda untuk rilis canary.
Tag: Setelah memberikan tag unik ke revisi tertentu, Knative secara otomatis menghasilkan titik akhir independen untuk revisi tersebut, yang dapat digunakan untuk validasi canary.
Secara esensial, Layanan Knative mengabstraksi sumber daya Kubernetes (Deployment, Service, dan Ingress) dengan kemampuan tingkat lanjut seperti penskalaan otomatis, manajemen multi-versi, dan kontrol lalu lintas.
Contoh YAML
Berikut ini adalah contoh template YAML untuk Layanan Knative sederhana:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
spec:
template:
spec:
containers:
- image: registry-vpc.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
env:
- name: TARGET
value: "Knative"Fitur
Dengan mengoperasikan objek sumber daya Layanan Knative, Anda dapat menerapkan fungsi-fungsi berikut dengan cara yang lebih sederhana.
Penskalaan otomatis berbasis permintaan
Penskalaan tradisional berbasis CPU/memori sering kali gagal mencerminkan beban bisnis aktual. Untuk layanan web, penskalaan berdasarkan permintaan bersamaan (konkurensi) atau catatan per detik (RPS) berkorelasi langsung dengan kinerja.
Knative Serving menyuntikkan kontainer queue-proxy ke setiap Pod untuk mengumpulkan metrik seperti konkurensi kontainer atau RPS. Autoscaler secara berkala mengambil metrik ini dan secara otomatis menyesuaikan jumlah Pod dalam Deployment berdasarkan algoritma, mencapai penskalaan otomatis berbasis permintaan. Alur implementasi adalah sebagai berikut:
Seorang pengguna memulai permintaan, dan HTTP Router meneruskan permintaan ke Layanan Serverless (SKS) dari Knative.
SKS adalah abstraksi Knative atas sumber daya Service Kubernetes, yang dapat merutekan permintaan ke titik akhir yang berbeda di backend.
SKS membuat keputusan routing berdasarkan jumlah Instans yang sedang berjalan dalam aplikasi.
Mode Serve: Ketika instans yang berjalan ada dalam aplikasi saat ini, permintaan langsung diteruskan kepada mereka.
Mode Proxy: Ketika jumlah instans dalam aplikasi saat ini telah diskalakan menjadi 0, lalu lintas dirutekan ke aktivator. Aktivator bertindak sebagai buffer proxy permintaan.
Aktivator menerima permintaan, mencatat metrik konkurensi, dan mengirim metrik ke autoscaler.
Autoscaler menentukan apakah penskalaan diperlukan berdasarkan ambang batas yang telah ditetapkan, dan mengirim permintaan skala keluar ke API server jika diperlukan.
Berdasarkan permintaan dari autoscaler, API server memperbarui Deployment dan membuat Pod baru.
Setelah aktivator mendeteksi bahwa Pod baru siap, ia meneruskan permintaan kepada mereka.
Untuk detail operasi, lihat Aktifkan penskalaan otomatis untuk menahan fluktuasi lalu lintas.
Penskalaan otomatis ke nol
Knative memungkinkan penskalaan otomatis Pod ke nol selama periode tanpa lalu lintas, dengan penskalaan vertikal instan saat permintaan tiba. Knative mendefinisikan dua mode akses permintaan: Mode Proxy dan Mode Serve. Autoscaler bertanggung jawab untuk beralih mode:
Jika jumlah permintaan adalah nol, autoscaler beralih dari Mode Serve ke Mode Proxy.
Saat permintaan diterima, autoscaler menerima notifikasi untuk menambah jumlah Pod. Setelah Pod baru siap, autoscaler meneruskan permintaan kepada mereka, dan beralih dari Mode Proxy ke Mode Serve.
Untuk detail konfigurasi, lihat Aktifkan penskalaan otomatis untuk menahan fluktuasi lalu lintas.
Manajemen multi-versi dan rilis canary
Setiap pembaruan konfigurasi menghasilkan revisi yang unik dan tidak dapat diubah. Rute mengarahkan permintaan ke revisi tertentu dan mendistribusikan lalu lintas di antara mereka berdasarkan persentase yang dapat dikonfigurasi. Revisi memungkinkan kemampuan manajemen versi seperti rollback dan rilis canary berdasarkan lalu lintas. Misalnya, setelah membuat revisi V1, perbarui objek konfigurasi Layanan untuk membuat Revisi V2. Konfigurasikan pemisahan lalu lintas rute untuk revisi V1 dan revisi V2 (seperti V1:70% / V2:30%), lalu lintas didistribusikan berdasarkan rasio yang ditentukan.
Untuk detail operasi, lihat Lakukan rilis canary berdasarkan pemisahan lalu lintas.