Batas Penskalaan untuk Cloud Service Mesh di GKE

Dokumen ini menjelaskan batas penskalaan bidang kontrol untuk arsitektur Cloud Service Mesh terkelola di GKE sehingga Anda dapat membuat keputusan yang tepat terkait deployment Anda.

Ringkasan

Skalabilitas Cloud Service Mesh di GKE bergantung pada operasi yang efisien dari dua komponen utamanya, bidang data dan bidang kontrol. Dokumen ini berfokus pada batas penskalaan bidang kontrol. Lihat Praktik Terbaik Skalabilitas untuk mengetahui praktik terbaik skalabilitas bidang data.

Beberapa batas penskalaan yang didokumentasikan diterapkan oleh batasan kuota. Jika melebihi batas tersebut, Anda harus mengajukan permintaan penambahan kuota. Batas lainnya tidak diterapkan secara ketat, tetapi dapat menyebabkan perilaku dan performa yang tidak terdefinisi jika terlampaui.

Untuk memahami cara menerjemahkan resource Istio ke resource Google Cloud , lihat panduan Memahami resource API terlebih dahulu.

Batas penskalaan layanan

Penskalaan layanan dibatasi di sepanjang dua dimensi

Perhatikan bahwa setelah Cloud Service Mesh diaktifkan untuk keanggotaan tertentu (yaitu cluster GKE), semua layanan Kubernetes di cluster akan diterjemahkan ke layanan Cloud Service Mesh, termasuk layanan yang menargetkan workload tanpa sidecar Cloud Service Mesh. Cloud Service Mesh membuat Zonal Network Endpoint Group untuk semua layanan di cluster GKE. Jika cluster bersifat regional, grup endpoint jaringan dibuat untuk semua zona node pool di region.

Layanan Cloud Service Mesh versus layanan Kubernetes

Layanan Cloud Service Mesh tidak sama dengan layanan Kubernetes karena layanan Cloud Service Mesh adalah satu layanan per port.

Misalnya, layanan Kubernetes ini diterjemahkan secara internal menjadi dua layanan Cloud Service Mesh, satu untuk setiap port.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

Subkumpulan aturan tujuan

Saat mengonfigurasi Istio Destination Rule API dengan subset, setiap subset dapat menghasilkan pembuatan beberapa layanan Cloud Service Mesh baru.

Misalnya, pertimbangkan DestinationRule berikut yang menargetkan layanan Kubernetes yang ditentukan sebelumnya:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

Layanan sintetis baru akan dibuat untuk setiap subset yang ditentukan. Jika layanan Kubernetes asli membuat dua layanan Cloud Service Mesh, DestinationRule akan membuat 4 layanan Cloud Service Mesh tambahan, 2 untuk setiap subset, sehingga total ada 6 layanan Cloud Service Mesh.

Deployment multi-project

Saat mesh tunggal di-deploy di seluruh workload dalam project Google Cloud yang berbeda, semua resource layanan Cloud Service Mesh dibuat di project host fleet. Artinya, semuanya tunduk pada batasan skalabilitas Cloud Service Mesh di project host fleet.

Service headless Kubernetes

Layanan headless Kubernetes memiliki batas yang lebih rendah dibandingkan dengan layanan reguler. Cloud Service Mesh hanya mendukung 50 layanan Cloud Service Mesh headless per cluster. Lihat dokumentasi jaringan Kubernetes untuk mengetahui contohnya.

Resource Sidecar Istio

Untuk Istio Sidecar API, batas berikut berlaku:

  • Sidecar tanpa workloadSelector: 150 per cluster

  • File bantuan dengan workloadSelector: 20 per cluster

Batas penskalaan endpoint

Batas penskalaan endpoint biasanya per berikut:

  • Layanan Cloud Service Mesh

  • Cluster GKE

Layanan Kubernetes reguler

Kuota endpoint per NEG memengaruhi jumlah maksimum endpoint yang dapat menjadi bagian dari satu layanan Kubernetes.

Service headless Kubernetes

Untuk layanan headless Kubernetes, Cloud Service Mesh mendukung tidak lebih dari 36 endpoint per layanan headless. Lihat dokumentasi jaringan Kubernetes untuk melihat contohnya.

Batas cluster GKE

Cloud Service Mesh mendukung hingga 5.000 endpoint (IP Pod) per cluster.

Batas penskalaan gateway

Saat menggunakan Gateway Istio, terutama untuk menghentikan koneksi HTTPS menggunakan kredensial TLS di secret Kubernetes, Cloud Service Mesh mendukung maksimal jumlah pod berikut:

  • 1.500 pod gateway saat menggunakan cluster GKE Regional

  • Pod gateway 500 saat menggunakan cluster GKE Zonal atau Autopilot