Menyelesaikan masalah penskalaan Istiod di Cloud Service Mesh

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.

Faktor penskalaan

Istiod mengirim konfigurasi ke setiap sidecar menggunakan streaming gRPC yang berumur panjang. Karakteristik ini memiliki beberapa karakteristik yang memengaruhi penskalaan:

  • Ukuran konfigurasi yang akan dibuat:
    • Jumlah total layanan/pod & resource Istio
    • Untuk skala besar, sesuaikan setelan untuk Sidecar untuk mengurangi ukuran konfigurasi.
  • Laju perubahan di lingkungan:
    • Saat layanan baru dibuat atau konfigurasi Istio diubah, update penuh akan dikirim ke proxy.
    • Menambahkan endpoint baru tidak akan membebani performa, karena hanya update inkremental yang dikirim.
  • Jumlah proxy yang konfigurasinya dibuat:
    • Dipengaruhi oleh jumlah gateway dan pod dengan sidecar.

Pertimbangan penskalaan

Istiod diskalakan dengan baik secara vertikal (permintaan besar) dan horizontal (lebih banyak replika). Pastikan batas CPU Anda tidak terlalu ketat; jika Istiod mencapai batas CPU, throttling dapat terjadi yang akan memengaruhi distribusi konfigurasi secara negatif. Jika Anda mengalami masalah performa, pertimbangkan untuk mengupgrade ke Cloud Service Mesh versi terbaru, karena setiap versi memiliki pengoptimalan performa.

Beban tidak seimbang

Perubahan besar pada ukuran cluster dapat menyebabkan beban yang tidak seimbang untuk sementara, karena koneksi yang berumur panjang. Hal ini dimitigasi oleh masa berlaku koneksi maksimum 30 menit, yang dapat menyebabkan pesan error di Envoy, seperti gRPC config stream closed: 13, yang memungkinkan beban diseimbangkan kembali secara alami.

Mitigasi masalah ini dengan memiliki beberapa replika Istiod (defaultnya adalah 2 replika), dan melakukan pra-penskalaan jika Anda mengharapkan peningkatan skala cluster yang ekstrem.