Informasi ini berguna untuk jenis pengguna berikut:
- Pengguna mulai menggunakan inferensi Knative.
- Operator dengan pengalaman dalam menjalankan cluster GKE.
- Developer aplikasi yang perlu mengetahui lebih lanjut cara penayangan Knative berintegrasi dengan cluster Kubernetes untuk mendesain aplikasi yang lebih baik atau mengonfigurasi aplikasi penayangan Knative mereka.
Komponen dalam penginstalan default
Instal penayangan Knative ke dalam
cluster Anda untuk menghubungkan dan mengelola beban kerja stateless. Komponen knative
dibuat di namespace knative-serving.
Penayangan 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 penayangan Knative dan Cloud Service Mesh:
Komponen yang diinstal oleh penayangan Knative di namespace
knative-serving:- Activator: Saat pod disederhanakan menjadi nol atau kelebihan beban dengan permintaan yang dikirim ke revisi, Activator akan mengantrekan permintaan untuk sementara dan mengirimkan metrik ke Autoscaler untuk membuat lebih banyak pod. Setelah Autoscaler menskalakan revisi berdasarkan metrik yang dilaporkan dan pod yang tersedia, Activator akan meneruskan permintaan yang diantrekan ke revisi. Pengaktif adalah komponen bidang data; komponen bidang data mengelola semua fungsi dan memproses penerusan traffic pengguna.
- Autoscaler: Menggabungkan dan memproses metrik dari Activator dan penampung sidecar proxy antrean, komponen di bidang data yang menerapkan batas serentak permintaan. Autoscaler kemudian menghitung serentak yang diamati untuk revisi dan menyesuaikan ukuran deployment berdasarkan jumlah pod yang diinginkan. Jika pod tersedia dalam revisi, Autoscaler adalah komponen bidang kontrol; jika tidak, saat pod diturunkan skalanya menjadi nol, Autoscaler adalah komponen bidang data.
- Pengontrol: Membuat dan memperbarui resource turunan Autoscaler dan objek Layanan. Pengontrol adalah komponen bidang kontrol; komponen bidang kontrol mengelola semua fungsi dan proses yang menetapkan jalur permintaan traffic pengguna.
- Metrics Collector: Mengumpulkan metrik dari komponen penayangan Knative, lalu meneruskannya ke Cloud Monitoring.
- Webhook: Menetapkan nilai default, menolak objek yang tidak konsisten dan tidak valid, serta memvalidasi dan memodifikasi panggilan Kubernetes API terhadap resource penayangan Knative. Webhook adalah komponen bidang kontrol.
Komponen yang diinstal oleh Cloud Service Mesh yang berjalan di namespace
istio-system:- Cluster Local Gateway: Load balancer di bidang data yang bertanggung jawab untuk menangani traffic internal yang berasal dari satu layanan penayangan Knative ke layanan lainnya. Gateway Lokal Cluster hanya dapat diakses dari dalam cluster GKE Anda dan tidak mendaftarkan domain eksternal untuk mencegah ekspos informasi pribadi atau proses internal secara tidak sengaja.
- Istio Ingress Gateway: Load balancer di bidang data 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 bidang kontrol. Untuk mengetahui informasi selengkapnya, lihat Istiod.
Komponen penayangan Knative diupdate secara otomatis dengan update cluster bidang kontrol GKE. Untuk mengetahui informasi selengkapnya, lihat Versi GKE yang tersedia.
Penggunaan resource cluster
Penginstalan awal untuk penayangan Knative memerlukan sekitar 1,5 CPU virtual dan memori 1 GB untuk cluster Anda. Jumlah node dalam cluster Anda tidak memengaruhi persyaratan ruang dan memori untuk penginstalan penayangan Knative.
Activator dapat menggunakan permintaan maksimum 1.000 milliCPU dan 600 MiB RAM. Jika Activator yang ada tidak dapat mendukung jumlah permintaan yang masuk, Activator tambahan akan diaktifkan, yang memerlukan reservasi 300 milliCPU dan 60 MiB RAM.
Setiap pod yang dibuat oleh layanan penayangan Knative akan membuat sidecar proxy antrean yang menerapkan batas konkurensi 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 digunakannya.
Membuat Layanan
Penayangan Knative memperluas Kubernetes dengan menentukan kumpulan Definisi 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 teratas yang ditentukan oleh inferensi Knative. Ini adalah satu aplikasi yang mengelola seluruh siklus proses beban kerja 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 pada titik waktu tertentu.
- Konfigurasi mempertahankan setelan saat ini untuk revisi terbaru dan mencatat histori semua revisi sebelumnya. Mengubah konfigurasi akan membuat revisi baru.
- Rute menentukan endpoint HTTP dan mengaitkan endpoint dengan satu atau beberapa revisi tempat permintaan diteruskan.
Saat pengguna membuat Layanan penayangan Knative, hal berikut akan terjadi:
Objek Layanan penayangan 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 bidang kontrol 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 tentang kemungkinan jalur permintaan untuk traffic pengguna melalui komponen bidang data penayangan Knative pada contoh cluster Google Kubernetes Engine:
Diagram berikutnya diperluas dari diagram di atas untuk memberikan tampilan mendalam tentang jalur permintaan traffic pengguna, yang juga dijelaskan secara mendetail di bawah:
Untuk jalur permintaan penayangan Knative:
Traffic masuk melalui:
- Gateway Traffic Masuk 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 bidang kontrol, 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 mendorong 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.
- Pengaktif mencoba ulang permintaan ke sidecar proxy antrean.
Jika layanan diskalakan (pod tersedia), Layanan Kubernetes akan mengirimkan permintaan ke sidecar proxy antrean.
Sidecar proxy antrean menerapkan parameter antrean permintaan, permintaan tunggal atau multi-thread, yang dapat ditangani penampung dalam 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 penampung pengguna.