Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Resolving Istiod scaling issues in Cloud Service Mesh\n=====================================================\n\nThis section explains common Cloud Service Mesh problems and how to resolve them.\nIf you need additional assistance, see [Getting support](/service-mesh/v1.19/docs/getting-support).\n\nScaling factors\n---------------\n\n[Istiod](https://istio.io/v1.19/blog/2020/istiod/)\nsends configuration to each sidecar using a long-lived gRPC stream. It has\nseveral characteristics that affect scaling:\n\n- The size of the configuration to generate:\n - Total number of services/pods \\& Istio resources\n - For large scale, adjust settings for the [Sidecar](https://istio.io/v1.19/docs/reference/config/networking/sidecar/) to reduce the configuration size.\n- The rate of change in the environment:\n - When a new service is created or the Istio configuration is changed, full updates are sent to proxies.\n - Adding new endpoints is inexpensive for performance, because only incremental updates are sent.\n- The number of proxies for which configuration is generated:\n - Affected by the number of gateways and pods with a sidecar.\n\nScaling considerations\n----------------------\n\nIstiod scales well vertically (large requests) and horizontally (more\nreplicas). Ensure that your CPU limits are not too restrictive; if Istiod\nreaches the CPU limit, throttling may occur which will negatively affect\nconfiguration distribution. If you encounter performance issues, consider\nupgrading to the latest version of Cloud Service Mesh, as each version has\nperformance optimizations.\n\nUnbalanced load\n---------------\n\nLarge changes in cluster size might cause a temporarily unbalanced load, due to\nthe long-lived connections. This is mitigated by a 30 minute maximum connection\nage, which might result in error messages in Envoy, such as `gRPC config stream\nclosed: 13`, which allows the load to naturally re-balance.\n\nMitigate this issue by having multiple replicas of Istiod (the default is 2\nreplicas), and pre-scaling if you expect extreme cluster scale-ups."]]
