Informasi ini berguna untuk jenis pengguna berikut:
- Pengguna yang baru mulai menggunakan inferensi Knative.
- Operator yang memiliki pengalaman dalam menjalankan cluster GKE.
- Developer aplikasi yang perlu mengetahui lebih lanjut cara inferensi Knative terintegrasi dengan cluster Kubernetes untuk mendesain aplikasi yang lebih baik atau mengonfigurasi aplikasi inferensi Knative.
Komponen dalam penginstalan default
Instal inferensi Knative ke
cluster Anda untuk menghubungkan dan mengelola workload tanpa status. Komponen Knative dibuat di namespace knative-serving.
Inferensi Knative menggunakan Cloud Service Mesh untuk merutekan traffic. Secara default, Cloud Service Mesh menginstal komponen di namespace istio-system.
Berikut adalah daftar komponen yang diinstal oleh inferensi Knative dan Cloud Service Mesh:
Komponen yang diinstal oleh inferensi Knative di namespace
knative-serving:- Activator: Saat pod diturunkan skalanya menjadi nol atau menjadi kelebihan beban dengan permintaan yang dikirim ke revisi, Activator akan mengantrekan permintaan untuk sementara dan mengirim metrik ke Autoscaler untuk menjalankan lebih banyak pod. Setelah Autoscaler menskalakan revisi berdasarkan metrik yang dilaporkan dan pod yang tersedia, Activator akan meneruskan permintaan yang diantrekan ke revisi. Activator adalah komponen data plane; komponen data plane mengelola semua fungsi dan proses yang meneruskan traffic pengguna.
- Autoscaler: Mengagregasi dan memproses metrik dari Activator dan container sidecar proxy antrean, komponen di data plane yang menerapkan batas serentak permintaan. Autoscaler kemudian menghitung serentak yang diamati untuk revisi dan menyesuaikan ukuran deployment berdasarkan jumlah pod yang diinginkan. Saat pod tersedia dalam revisi, Autoscaler adalah komponen control plane; jika tidak, saat pod diturunkan skalanya menjadi nol, Autoscaler adalah komponen data plane.
- Controller: Membuat dan mengupdate resource turunan Autoscaler dan objek Layanan. Controller adalah komponen control plane; komponen control plane mengelola semua fungsi dan proses yang menetapkan jalur permintaan traffic pengguna.
- Metrics Collector: Mengumpulkan metrik dari komponen inferensi Knative lalu meneruskannya ke Cloud Monitoring.
- Webhook: Menetapkan nilai default, menolak objek yang tidak konsisten dan tidak valid, serta memvalidasi dan mengubah panggilan Kubernetes API terhadap resource inferensi Knative. Webhook adalah komponen control plane.
Komponen yang diinstal oleh Cloud Service Mesh yang berjalan di namespace
istio-system:- Cluster Local Gateway: Load balancer di data plane yang bertanggung jawab untuk menangani traffic internal yang berasal dari satu layanan inferensi Knative ke layanan lainnya. Cluster Local Gateway hanya dapat diakses dari dalam cluster GKE Anda dan tidak mendaftarkan domain eksternal untuk mencegah informasi pribadi atau proses internal terekspos secara tidak sengaja.
- Istio Ingress Gateway: Load balancer di data plane yang bertanggung jawab untuk menerima dan menangani traffic masuk dari luar cluster, termasuk traffic dari jaringan eksternal atau internal.
- Istiod: Mengonfigurasi Cluster Local Gateway dan Istio Ingress Gateway untuk menangani permintaan HTTP di endpoint yang benar. Istiod adalah komponen control plane. Untuk mengetahui informasi selengkapnya, lihat Istiod.
Komponen inferensi Knative otomatis diperbarui dengan update cluster control plane GKE. Untuk mengetahui informasi selengkapnya, lihat Versi GKE yang tersedia.
Penggunaan resource cluster
Penginstalan awal untuk inferensi Knative memerlukan sekitar 1,5 CPU virtual dan memori 1 GB untuk cluster Anda. Jumlah node di cluster Anda tidak memengaruhi persyaratan ruang dan memori untuk penginstalan inferensi Knative.
Activator dapat menggunakan permintaan dengan maksimum 1000 milliCPU dan RAM 600 MiB. Jika Activator yang ada tidak dapat mendukung jumlah permintaan masuk, Activator tambahan akan diaktifkan, yang memerlukan reservasi 300 milliCPU dan RAM 60 MiB.
Setiap pod yang dibuat oleh layanan inferensi Knative akan membuat sidecar proxy antrean yang menerapkan batas serentak permintaan. Proxy antrean mencadangkan 25 milliCPU dan tidak memiliki reservasi memori. Konsumsi proxy antrean bergantung pada jumlah permintaan yang diantrekan dan ukuran permintaan; tidak ada batasan pada resource CPU dan memori yang dapat dikonsumsi.
Membuat Layanan
Inferensi Knative memperluas Kubernetes dengan menentukan serangkaian Resource Kustom (CRD): Layanan, Revisi, Konfigurasi, dan Rute. CRD ini menentukan dan mengontrol perilaku aplikasi Anda di cluster:
- Layanan inferensi Knative adalah resource kustom tingkat atas yang ditentukan oleh inferensi Knative. Layanan ini adalah satu aplikasi yang mengelola seluruh siklus proses workload Anda. Layanan Anda memastikan aplikasi Anda memiliki rute, konfigurasi, dan revisi baru untuk setiap update layanan.
- Revisi adalah snapshot kode dan konfigurasi yang tidak dapat diubah dan diambil pada waktu tertentu.
- Konfigurasi mempertahankan setelan saat ini untuk revisi terbaru Anda dan mencatat histori semua revisi sebelumnya. Mengubah konfigurasi akan membuat revisi baru.
- Rute menentukan endpoint HTTP dan mengaitkan endpoint dengan satu atau beberapa revisi yang diteruskan permintaannya.
Saat pengguna membuat Layanan inferensi Knative, hal berikut akan terjadi:
Objek Layanan inferensi Knative menentukan:
- Konfigurasi untuk cara menayangkan revisi Anda.
- Revisi yang tidak dapat diubah untuk versi layanan Anda ini.
- Rute untuk mengelola alokasi traffic yang ditentukan ke revisi Anda.
Objek rute membuat VirtualService. Objek VirtualService mengonfigurasi Ingress Gateway dan Cluster Local Gateway untuk merutekan traffic gateway ke revisi yang benar.
Objek revisi membuat komponen control plane berikut: objek Layanan Kubernetes dan objek Deployment.
Konfigurasi jaringan menghubungkan Activator, Autoscaler, dan load balancer untuk aplikasi Anda.
Penanganan permintaan
Diagram berikut menunjukkan ringkasan tingkat tinggi dari kemungkinan jalur permintaan untuk traffic pengguna melalui komponen data plane inferensi Knative pada contoh cluster Google Kubernetes Engine:
Diagram berikutnya memperluas diagram di atas untuk memberikan tampilan mendalam ke jalur permintaan traffic pengguna, yang juga dijelaskan secara mendetail di bawah ini:
Untuk jalur permintaan inferensi Knative:
Traffic tiba melalui:
- Ingress Gateway untuk traffic dari luar cluster
- Cluster Local Gateway untuk traffic dalam cluster
Komponen VirtualService, yang menentukan aturan perutean traffic, mengonfigurasi gateway sehingga traffic pengguna dirutekan ke revisi yang benar.
Layanan Kubernetes, komponen control plane, menentukan langkah berikutnya dalam jalur permintaan yang bergantung pada ketersediaan pod untuk menangani traffic:
Jika tidak ada pod dalam revisi:
- Activator mengantrekan permintaan yang diterima untuk sementara dan mengirim metrik ke Autoscaler untuk menskalakan lebih banyak pod.
- Autoscaler menskalakan ke status pod yang diinginkan dalam Deployment.
- Deployment membuat lebih banyak pod untuk menerima permintaan tambahan.
- Activator mencoba kembali permintaan ke sidecar proxy antrean.
Jika layanan ditingkatkan skalanya (pod tersedia), Layanan Kubernetes akan mengirim permintaan ke sidecar proxy antrean.
Sidecar proxy antrean menerapkan parameter antrean permintaan, permintaan thread tunggal atau multi-thread, yang dapat ditangani container pada satu waktu.
Jika sidecar proxy antrean memiliki lebih banyak permintaan daripada yang dapat ditanganinya, Autoscaler akan membuat lebih banyak pod untuk menangani permintaan tambahan.
Sidecar proxy antrean mengirim traffic ke container pengguna.