Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Menyelesaikan masalah batas resource di Cloud Service Mesh
Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara menyelesaikannya. Jika Anda memerlukan bantuan tambahan, lihat
Mendapatkan dukungan.
Masalah batas resource Cloud Service Mesh dapat disebabkan oleh salah satu hal berikut:
Objek LimitRange yang dibuat di namespace istio-system atau namespace apa pun
dengan injeksi sidecar otomatis diaktifkan.
Batas yang ditentukan pengguna yang ditetapkan terlalu rendah.
Node kehabisan memori atau resource lainnya.
Kemungkinan gejala masalah resource:
Cloud Service Mesh berulang kali tidak menerima konfigurasi dari bidang kontrol
yang ditunjukkan oleh error, Envoy proxy NOT ready. Melihat error ini beberapa kali
saat startup adalah hal yang wajar, tetapi jika tidak, itu adalah masalah.
Masalah jaringan dengan beberapa pod atau node yang tidak dapat dijangkau.
istioctl proxy-status menampilkan status STALE dalam output.
Pesan OOMKilled dalam log node.
Penggunaan memori oleh penampung: kubectl top pod POD_NAME --containers.
Penggunaan memori oleh pod di dalam node: kubectl top node my-node.
Envoy kehabisan memori: kubectl get pods menampilkan status OOMKilled di output.
Sidecar memerlukan waktu lama untuk menerima konfigurasi
Penyebaran konfigurasi yang lambat dapat terjadi karena resource yang dialokasikan ke istiod tidak memadai atau ukuran cluster yang terlalu besar.
Ada beberapa kemungkinan solusi untuk masalah ini:
Untuk Cloud Service Mesh dalam cluster, jika alat pemantauan Anda (prometheus,
stackdriver, dll.) menunjukkan penggunaan resource yang tinggi oleh istiod, tingkatkan
alokasi resource tersebut, misalnya tingkatkan batas CPU atau memori deployment istiod. Ini adalah solusi sementara dan sebaiknya
Anda menyelidiki metode untuk mengurangi konsumsi resource.
Jika Anda mengalami masalah ini di cluster atau deployment besar, kurangi jumlah status konfigurasi yang dikirim ke setiap proxy dengan mengonfigurasi resource Sidecar.
Untuk Cloud Service Mesh dalam cluster, jika masalah berlanjut, coba skalakan istiod secara horizontal.
Jika semua langkah pemecahan masalah lainnya gagal menyelesaikan masalah, laporkan bug yang menjelaskan deployment Anda dan masalah yang diamati. Ikuti
langkah-langkah ini
untuk menyertakan profil CPU/Memori dalam laporan bug jika memungkinkan, beserta
deskripsi mendetail tentang ukuran cluster, jumlah pod, dan jumlah layanan.
[[["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-08-18 UTC."],[],[],null,["# Resolving resource limit issues in Cloud Service Mesh\n=====================================================\n\nThis section explains common Cloud Service Mesh problems and how to resolve\nthem. If you need additional assistance, see\n[Getting support](/service-mesh/v1.25/docs/getting-support).\n\nCloud Service Mesh resource limit problems can be caused by any of the\nfollowing:\n\n- `LimitRange` objects created in the `istio-system` namespace or any namespace with automatic sidecar injection enabled.\n- User-defined limits that are set too low.\n- Nodes run out of memory or other resources.\n\nPotential symptoms of resource problems:\n\n- Cloud Service Mesh repeatedly not receiving configuration from the control plane indicated by the error, `Envoy proxy NOT ready`. Seeing this error a few times at startup is normal, but otherwise it is a concern.\n- Networking problems with some pods or nodes that become unreachable.\n- `istioctl proxy-status` showing `STALE` statuses in the output.\n- `OOMKilled` messages in the logs of a node.\n- Memory usage by containers: `kubectl top pod POD_NAME --containers`.\n- Memory usage by pods inside a node: `kubectl top node my-node`.\n- Envoy out of memory: `kubectl get pods` shows status `OOMKilled` in the output.\n\nSidecars take a long time to receive configuration\n--------------------------------------------------\n\nSlow configuration propagation can occur due to insufficient resources allocated\nto `istiod` or an excessively large cluster size.\n\nThere are several possible solutions to this problem:\n\n1. For in-cluster Cloud Service Mesh, if your monitoring tools (prometheus,\n stackdriver, etc.) show high utilization of a resource by `istiod`, increase\n the allocation of that resource, for example increase the CPU or memory limit\n of the `istiod` deployment. This is a temporary solution and we recommended\n that you investigate methods for reducing resource consumption.\n\n2. If you encounter this issue in a large cluster or deployment, reduce the\n amount of configuration state pushed to each proxy by configuring\n [Sidecar resources](https://istio.io/v1.24/docs/reference/config/networking/sidecar/).\n\n3. For in-cluster Cloud Service Mesh, if the problem persists, try\n horizontally scaling `istiod`.\n\n4. If all other troubleshooting steps fail to resolve the problem, report a bug\n detailing your deployment and the observed problems. Follow\n [these steps](https://github.com/istio/istio/wiki/Analyzing-Istio-Performance)\n to include a CPU/Memory profile in the bug report if possible, along with a\n detailed description of cluster size, number of pods, and number of services."]]
