Informasi ini berguna untuk jenis pengguna berikut:
- Pengguna yang mulai menggunakan penayangan Knative.
- Operator yang berpengalaman dalam menjalankan cluster GKE.
- Developer aplikasi yang perlu mengetahui lebih lanjut cara penayangan Knative terintegrasi dengan cluster Kubernetes untuk mendesain aplikasi yang lebih baik atau mengonfigurasi aplikasi penayangan Knative mereka.
Komponen dalam penginstalan default
Instal inferensi Knative ke
cluster Anda untuk menghubungkan dan mengelola workload stateless Anda. Komponen Knative dibuat di namespace knative-serving.
Penyaluran Knative menggunakan Anthos Service Mesh untuk merutekan traffic. Secara default,
Anthos Service Mesh menginstal komponen dalam namespace istio-system.
Berikut adalah daftar komponen yang diinstal oleh Knative inferensi dan Anthos Service Mesh:
Komponen yang diinstal oleh penayangan Knative di namespace
knative-serving:- Aktivator: Saat pod diskalakan ke nol atau kelebihan beban dengan permintaan yang dikirim ke revisi, Aktivator 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, Aktivator akan meneruskan permintaan yang diantrekan ke revisi tersebut. Aktivator adalah komponen bidang data; komponen bidang data mengelola semua fungsi dan proses yang meneruskan traffic pengguna.
- Autoscaler: Menggabungkan dan memproses metrik dari Aktivator dan container file bantuan proxy antrean, yang merupakan komponen dalam bidang data yang menerapkan batas serentak permintaan. Autoscaler kemudian menghitung konkurensi yang diamati untuk revisi dan menyesuaikan ukuran deployment berdasarkan jumlah pod yang diinginkan. Jika pod tersedia dalam revisi, Autoscaler akan menjadi komponen bidang kontrol; jika tidak, saat pod diskalakan ke nol, Autoscaler adalah komponen bidang data.
- Pengontrol: Membuat dan mengupdate 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 memutasikan panggilan Kubernetes API terhadap resource penayangan Knative. Webhook adalah komponen bidang kontrol.
Komponen yang diinstal oleh Anthos Service Mesh yang berjalan di namespace
istio-system:- Gateway Lokal Cluster: Load balancer di bidang data yang bertanggung jawab untuk menangani traffic internal yang masuk 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 eksposur informasi pribadi atau proses internal yang tidak disengaja.
- Gateway Istio Ingress: 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 Gateway Lokal Cluster dan Gateway Ingress Istio untuk menangani permintaan HTTP di endpoint yang benar. Istiod adalah komponen bidang kontrol. Untuk mengetahui informasi selengkapnya, lihat Istiod.
Komponen inferensi Knative diupdate secara otomatis dengan update cluster bidang kontrol GKE. Untuk informasi selengkapnya, lihat Versi GKE yang tersedia.
Penggunaan resource cluster
Instalasi awal untuk inferensi Knative kira-kira membutuhkan 1,5 CPU virtual dan 1 GB memori untuk cluster Anda. Jumlah node dalam cluster Anda tidak memengaruhi persyaratan ruang dan memori untuk penginstalan penayangan Knative.
Aktivator dapat menggunakan permintaan pada maksimum 1.000 miliCPU dan 600 MiB RAM. Jika Aktivator yang ada tidak dapat mendukung jumlah permintaan masuk, Aktivator tambahan akan dijalankan, sehingga memerlukan reservasi sebesar 300 miliCPU dan 60 MiB RAM.
Setiap pod yang dibuat oleh layanan penayangan Knative membuat sidecar proxy antrean yang menerapkan batas serentak permintaan. Proxy antrean menyimpan 25 miliCPU dan tidak memiliki reservasi memori. Pemakaian proxy antrean bergantung pada jumlah permintaan yang diantrekan dan ukuran permintaan; tidak ada batasan CPU dan resource memori yang dapat digunakan.
Membuat Service
Penayangan Knative memperluas Kubernetes dengan menentukan kumpulan Custom Resource Definitions (CRD): Layanan, Revisi, Konfigurasi, dan Rute. CRD ini menentukan dan mengontrol perilaku aplikasi Anda di cluster:
- Layanan penayangan Knative adalah resource kustom tingkat atas yang ditentukan oleh penayangan Knative. Ini adalah aplikasi tunggal 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 pada waktu tertentu yang tidak dapat diubah.
- Configuration mempertahankan setelan saat ini untuk revisi terbaru Anda dan mencatat histori semua revisi sebelumnya. Mengubah konfigurasi akan membuat revisi baru.
- Route menentukan endpoint HTTP dan mengaitkan endpoint dengan satu atau beberapa revisi yang menjadi tujuan penerusan permintaan.
Saat pengguna membuat Layanan penayangan Knative, hal berikut akan terjadi:
Objek Layanan Knative menentukan:
- Konfigurasi untuk menayangkan revisi Anda.
- Revisi yang tidak dapat diubah untuk versi layanan Anda ini.
- Rute untuk mengelola alokasi traffic yang ditentukan untuk revisi Anda.
Objek rute akan membuat VirtualService. Objek VirtualService mengonfigurasi Ingress Gateway dan Cluster Local Gateway untuk mengarahkan traffic gateway ke revisi yang benar.
Objek revisi membuat komponen bidang kontrol berikut: objek Kubernetes Service dan objek Deployment.
Konfigurasi jaringan menghubungkan Activator, Autoscaler, dan load balancer untuk aplikasi Anda.
Penanganan permintaan
Diagram berikut menunjukkan ringkasan umum 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 gambaran mendalam tentang jalur permintaan traffic pengguna, yang juga dijelaskan secara mendetail di bawah:
Untuk jalur permintaan penayangan Knative:
Lalu lintas tiba melalui:
- Gateway Ingress untuk traffic dari luar cluster
- Cluster Local Gateway untuk traffic dalam cluster
Komponen VirtualService, yang menentukan aturan perutean traffic, mengonfigurasi gateway agar traffic pengguna dirutekan ke revisi yang benar.
Layanan Kubernetes, yang merupakan komponen bidang kontrol, menentukan langkah selanjutnya dalam jalur permintaan yang bergantung pada ketersediaan pod untuk menangani traffic:
Jika tidak ada pod dalam revisi:
- Aktivator mengantrekan permintaan yang diterima untuk sementara dan mengirim metrik ke Autoscaler untuk menskalakan lebih banyak pod.
- Autoscaler melakukan penskalaan ke status pod yang diinginkan di Deployment.
- Deployment membuat lebih banyak pod untuk menerima permintaan tambahan.
- Aktivator mencoba ulang permintaan ke file bantuan proxy antrean.
Jika layanan disebarkan skalanya (pod tersedia), Layanan Kubernetes akan mengirim permintaan ke file bantuan proxy antrean.
Sidecar proxy antrean menerapkan parameter antrean permintaan, permintaan tunggal atau multi-thread, yang dapat ditangani penampung pada satu waktu.
Jika file bantuan proxy antrean memiliki lebih banyak permintaan daripada yang dapat ditangani, Autoscaler akan membuat lebih banyak pod untuk menangani permintaan tambahan.
Sidecar proxy antrean mengirimkan traffic ke penampung pengguna.