Ringkasan arsitektur Cloud Run for Anthos (penayangan Knative)

Halaman ini menyediakan ringkasan arsitektur Cloud Run for Anthos (penayangan Knative) dan membahas perubahan yang terjadi saat Anda mengaktifkan Cloud Run for Anthos di cluster Google Kubernetes Engine.

Informasi ini berguna untuk jenis pengguna berikut:

  • Pengguna yang mulai menggunakan Cloud Run for Anthos.
  • Operator yang berpengalaman dalam menjalankan cluster GKE.
  • Developer aplikasi yang perlu mengetahui lebih lanjut cara Cloud Run for Anthos berintegrasi dengan cluster Kubernetes untuk mendesain aplikasi yang lebih baik atau mengonfigurasi aplikasi Cloud Run for Anthos mereka.

Komponen dalam penginstalan default

Cloud Run for Anthos menginstal Knative Serve ke dalam cluster Anda untuk menghubungkan dan mengelola workload stateless Anda. Komponen Knative dibuat di namespace knative-serving.

Cloud Run for Anthos menggunakan Anthos Service Mesh untuk mengarahkan traffic. Secara default, Anthos Service Mesh menginstal komponen dalam namespace istio-system.

Berikut adalah daftar komponen yang diinstal oleh Cloud Run for Anthos dan Anthos Service Mesh:

  • Komponen yang diinstal oleh Cloud Run for Anthos di namespace knative-serving:

    • Aktivator: Saat pod diskalakan ke nol atau 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 antrean ke revisi. Aktivator adalah komponen bidang data; komponen bidang data mengelola semua fungsi dan proses yang meneruskan traffic pengguna.
    • Autoscaler: Menggabungkan dan memproses metrik dari Activator dan penampung file bantuan proxy antrean, yaitu komponen dalam bidang data yang menerapkan batas serentak permintaan. Autoscaler kemudian menghitung konkurensi yang diamati untuk revisi tersebut 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 Cloud Run for Anthos, 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 Cloud Run for Anthos. 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 Cloud Run for Anthos ke Cloud Run for Anthos 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 Cloud Run for Anthos diupdate secara otomatis dengan update cluster bidang kontrol GKE. Untuk mengetahui informasi selengkapnya, lihat Versi GKE yang tersedia.

Penggunaan resource cluster

Penginstalan awal Cloud Run for Anthos kurang lebih memerlukan 1,5 CPU virtual dan 1 GB memori untuk cluster Anda. Jumlah node dalam cluster Anda tidak memengaruhi persyaratan ruang dan memori untuk penginstalan Cloud Run for Anthos.

Aktivator dapat menggunakan permintaan dengan maksimum 1.000 miliCPU dan 600 MiB RAM. Jika Activator yang ada tidak dapat mendukung jumlah permintaan masuk, Aktivator tambahan akan dijalankan, yang memerlukan reservasi sebesar 300 miliCPU dan 60 MiB RAM.

Setiap pod yang dibuat oleh layanan Cloud Run for Anthos membuat file bantuan proxy antrean yang menerapkan batas permintaan serentak. Proxy antrean mencadangkan 25 miliCPU dan tidak memiliki pencadangan memori. Pemakaian proxy antrean bergantung pada jumlah permintaan yang masuk ke antrean dan ukuran permintaan. Tidak ada batasan CPU dan resource memori yang dapat dipakai.

Membuat Service

Diagram yang menunjukkan arsitektur layanan Cloud Run for Anthos
Arsitektur Layanan Cloud Run for Anthos (klik untuk memperbesar)

Cloud Run for Anthos memperluas Kubernetes dengan menentukan sekumpulan Custom Resource Definitions (CRD): Layanan, Revisi, Konfigurasi, dan Rute. CRD ini menentukan dan mengontrol perilaku aplikasi Anda di cluster:

  • Cloud Run for Anthos Service adalah resource kustom level teratas yang ditentukan oleh Cloud Run for Anthos. Ini adalah aplikasi tunggal 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 pada titik waktu yang tidak dapat diubah.
  • Configuration mempertahankan setelan saat ini untuk revisi terbaru dan mencatat histori semua revisi sebelumnya. Mengubah konfigurasi akan membuat revisi baru.
  • Route menentukan endpoint HTTP dan mengaitkan endpoint tersebut dengan satu atau beberapa revisi yang menjadi tujuan penerusan permintaan.

Saat pengguna membuat Cloud Run for Anthos Service, hal berikut akan terjadi:

  1. Objek Cloud Run for Anthos Service menentukan:

    1. Konfigurasi cara menayangkan revisi Anda.
    2. Revisi yang tidak dapat diubah untuk versi layanan Anda ini.
    3. Rute untuk mengelola alokasi traffic yang ditentukan untuk revisi Anda.
  2. Objek rute membuat VirtualService. Objek VirtualService mengonfigurasi Gateway Ingress dan Cluster Local Gateway untuk mengarahkan traffic gateway ke revisi yang benar.

  3. Objek revisi membuat komponen bidang kontrol berikut: objek Kubernetes Service dan objek Deployment.

  4. 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 Cloud Run for Anthos pada contoh cluster Google Kubernetes Engine:

Diagram yang menampilkan arsitektur cluster Cloud Run for Anthos
Arsitektur cluster Cloud Run for Anthos (klik untuk memperbesar)

Diagram berikutnya diperluas dari diagram di atas untuk memberikan gambaran mendalam ke jalur permintaan traffic pengguna, yang juga dijelaskan secara mendetail di bawah:

Diagram yang menunjukkan jalur permintaan Cloud Run for Anthos
Jalur permintaan Cloud Run for Anthos (klik untuk memperbesar)

Untuk jalur permintaan Cloud Run for Anthos:

  1. Lalu lintas tiba melalui:

    • Gateway Ingress untuk traffic dari luar cluster
    • Cluster Local Gateway untuk traffic dalam cluster
  2. Komponen VirtualService, yang menentukan aturan perutean traffic, mengonfigurasi gateway agar traffic pengguna dirutekan ke revisi yang benar.

  3. Layanan Kubernetes, komponen bidang kontrol, menentukan langkah selanjutnya dalam jalur permintaan yang bergantung pada ketersediaan pod untuk menangani traffic:

    • Jika tidak ada pod dalam revisi:

      1. Aktivator mengantrekan permintaan yang diterima untuk sementara dan mengirim metrik ke Autoscaler untuk menskalakan lebih banyak pod.
      2. Autoscaler melakukan penskalaan ke status pod yang diinginkan di Deployment.
      3. Deployment membuat lebih banyak pod untuk menerima permintaan tambahan.
      4. Aktivator mencoba ulang permintaan ke file bantuan proxy antrean.
    • Jika skala layanan diperluas (pod tersedia), Layanan Kubernetes akan mengirimkan permintaan ke bantuan proxy antrean.

  4. Sidecar proxy antrean menerapkan parameter antrean permintaan, permintaan tunggal atau multi-thread, yang dapat ditangani penampung pada satu waktu.

  5. Jika file bantuan proxy antrean memiliki lebih banyak permintaan daripada yang dapat ditangani, Autoscaler akan membuat lebih banyak pod untuk menangani permintaan tambahan.

  6. Sidecar proxy antrean mengirim traffic ke penampung pengguna.