Informasi ini berguna untuk jenis pengguna berikut:
- Pengguna yang memulai penyaluran Knative.
- Operator yang berpengalaman dalam menjalankan cluster GKE.
- Pengembang aplikasi yang perlu tahu lebih banyak tentang cara Penyajian Knative terintegrasi dengan cluster Kubernetes untuk mendesain aplikasi yang lebih baik atau mengonfigurasi penyaluran Knativenya aplikasi.
Komponen dalam penginstalan default
Instal penyaluran Knative ke dalam
cluster Anda untuk menghubungkan dan mengelola workload stateless Anda. Knative
komponen dibuat di namespace knative-serving.
Penayangan Knative menggunakan Cloud Service Mesh untuk merutekan traffic. Secara {i>default<i},
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 penayangan Knative di namespace
knative-serving:- Activator: Saat pod diskalakan ke nol atau kelebihan beban karena permintaan dikirim ke revisi, Aktivator mengantrekan permintaan itu untuk sementara dan mengirimkan metrik ke Penskala otomatis untuk menjalankan lebih banyak pod. Setelah Autoscaler menskalakan revisi berdasarkan terkait metrik yang dilaporkan dan pod yang tersedia, penerusan Aktivator dimasukkan ke dalam antrean permintaan revisi. Aktivator adalah komponen bidang data; bidang data komponen mengelola semua fungsi dan memproses penerusan lalu lintas pengguna.
- Autoscaler: Menggabungkan metrik dan memproses dari Aktivator dan container file samping proxy antrean, komponen dalam bidang data yang menerapkan batas konkurensi permintaan. Autoscaler kemudian menghitung jumlah konkurensi untuk revisi dan menyesuaikan ukuran deployment berdasarkan pada jumlah pod yang diinginkan. Ketika pod tersedia di revisi, Autoscaler adalah komponen bidang kontrol; jika tidak, saat pod diskalakan ke nol, {i>Autoscaler<i} adalah komponen bidang data.
- Pengontrol: Membuat dan memperbarui resource turunan dari Autoscaler dan Service object. Pengontrol merupakan bidang kontrol komponen; komponen bidang kontrol mengelola semua fungsi dan proses menetapkan jalur permintaan lalu lintas pengguna.
- Metrics Collector: Mengumpulkan metrik dari komponen penayangan Knative lalu meneruskannya ke Cloud Monitoring.
- Webhook: Menetapkan nilai default, menolak nilai yang tidak konsisten dan tidak valid objek, dan memvalidasi dan mutasi Panggilan Kubernetes API terhadap resource penyaluran Knative. Webhook adalah komponen bidang kontrol.
Komponen yang diinstal oleh Cloud 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 penyajian Knative ke layanan lainnya. Cluster Local Gateway hanya dapat diakses dari dalam GKE Anda dan tidak mendaftarkan domain eksternal untuk mencegah paparan informasi pribadi atau proses internal.
- Gateway Istio Ingress: Load balancer di bidang data yang bertanggung jawab untuk menerima dan menangani lalu lintas masuk dari luar cluster tersebut, termasuk traffic dari atau jaringan internal.
- Istiod: Mengonfigurasi Gateway Lokal Cluster dan Istio Gateway Ingress untuk menangani permintaan HTTP di endpoint yang benar. Istio adalah komponen bidang kontrol. Untuk mengetahui informasi selengkapnya, lihat Istiod.
Komponen penyaluran Knative diperbarui secara otomatis dengan Update cluster bidang kontrol GKE. Untuk informasi selengkapnya, lihat Versi GKE yang tersedia.
Penggunaan resource cluster
Instalasi awal untuk penyaluran Knative kira-kira membutuhkan 1,5 CPU virtual dan memori 1 GB untuk cluster Anda. Jumlah node di tidak memengaruhi kebutuhan ruang dan memori untuk Penginstalan penyaluran Knative.
Aktivator dapat menggunakan permintaan dengan ukuran maksimum 1.000 milliCPU dan RAM 600 MiB. Ketika Aktivator yang ada tidak dapat mendukung jumlah permintaan masuk, Aktivator tambahan diputar, yang memerlukan pemesanan 300 milliCPU dan RAM 60 MiB.
Setiap pod yang dibuat oleh layanan inferensi Knative membuat file bantuan proxy antrean yang menerapkan batas konkurensi permintaan. Proxy antrean mencadangkan 25 milliCPU dan tidak memiliki reservasi memori. Proxy antrean tergantung pada berapa banyak permintaan yang dimasukkan ke dalam antrean dan ukuran permintaan; tidak ada batasan pada sumber daya CPU dan memori yang dapat dikonsumsinya.
Membuat Layanan
Penyajian Knative memperluas Kubernetes dengan menentukan kumpulan Custom Definisi Resource (CRD) Service, Revisi, Konfigurasi, dan Rute. CRD ini menentukan dan mengontrol cara aplikasi Anda berperilaku di cluster:
- Layanan penayangan Knative adalah resource kustom tingkat atas yang ditentukan oleh penyaluran Knative. Cloud adalah aplikasi tunggal yang mengelola seluruh siklus hidup beban kerja Anda. Layanan Anda memastikan aplikasi memiliki rute, konfigurasi, dan revisi baru untuk setiap update layanan tersebut.
- Revisi adalah snapshot kode yang tidak dapat diubah dan bersifat point-in-time serta konfigurasi Anda.
- Konfigurasi mempertahankan setelan saat ini untuk revisi terbaru Anda dan mencatat riwayat semua revisi sebelumnya. Memodifikasi 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 terjadi:
Objek Layanan penyaluran Knative menentukan:
- Konfigurasi untuk cara menyajikan revisi.
- Revisi yang tidak dapat diubah untuk versi layanan Anda ini.
- Rute untuk mengelola alokasi traffic yang ditentukan untuk revisi Anda.
Objek rute membuat VirtualService. Objek VirtualService mengonfigurasi Gateway Ingress dan Gateway Lokal Cluster untuk mengarahkan 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 umum tentang kemungkinan jalur permintaan untuk lalu lintas pengguna melalui komponen bidang data penyaluran 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 detail di bawah ini:
Untuk jalur permintaan penayangan Knative:
Lalu lintas masuk melalui:
- Gateway Ingress untuk traffic dari luar cluster
- Gateway Lokal Cluster untuk traffic dalam cluster
Komponen VirtualService, yang menentukan aturan pemilihan rute lalu lintas, mengkonfigurasi {i>gateway<i} sehingga lalu lintas pengguna diarahkan ke jalur yang benar revisi.
Layanan Kubernetes, komponen bidang kontrol, menentukan langkah berikutnya dalam jalur permintaan yang bergantung pada ketersediaan pod untuk menangani lalu lintas:
Jika tidak ada pod dalam revisi:
- Aktivator mengantrekan permintaan yang diterima untuk sementara dan mendorong ke Penskalaan Otomatis untuk menskalakan lebih banyak pod.
- Autoscaler melakukan penskalaan ke status pod yang diinginkan dalam Deployment.
- Deployment membuat lebih banyak pod untuk menerima permintaan tambahan.
- Aktivator mencoba kembali permintaan ke file bantuan proxy antrean.
Jika layanan di-skalakan (pod tersedia), Layanan Kubernetes mengirimkan permintaan ke file bantuan proxy antrean.
File bantuan proxy antrean menerapkan parameter antrean permintaan, permintaan multi-thread, yang dapat ditangani container pada satu waktu.
Jika file bantuan proxy antrean memiliki lebih banyak permintaan daripada yang dapat ditangani, membuat lebih banyak pod untuk menangani permintaan tambahan.
File bantuan proxy antrean mengirimkan traffic ke penampung pengguna.