Menyelesaikan masalah penskalaan Istiod di Cloud Service Mesh
Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara menyelesaikannya. 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 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.