Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Resuelve problemas de límite de recursos en Cloud Service Mesh
En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Los problemas de límite de recursos de Cloud Service Mesh pueden deberse a cualquiera de los siguientes puntos:
Objetos LimitRange creados en el espacio de nombres istio-system o cualquier espacio de nombres con la inyección automática de sidecar habilitada.
Límites definidos por el usuario que son demasiado bajos
Nodos que se quedaron sin memoria o sin otros recursos
Posibles síntomas de problemas de recursos:
Cloud Service Mesh no recibe la configuración del plano de control de forma reiterada, lo que indica el error Envoy proxy NOT ready. Ver este error algunas veces al inicio es normal, pero, si esto continúa repitiéndose, es un problema.
Hay problemas de Herramientas de redes con algunos Pods o nodos que se vuelven inaccesibles.
istioctl proxy-status muestra estados STALE en el resultado.
Hay mensajes OOMKilled en los registros de un nodo.
Uso de memoria de los contenedores: kubectl top pod POD_NAME --containers
Uso de memoria de los Pods dentro de un nodo: kubectl top node my-node
Envoy no tiene memoria: kubectl get pods muestra el estado OOMKilled en el resultado.
Los archivos adicionales tardan mucho en recibir la configuración
La propagación lenta de la configuración puede ocurrir debido a que no se asignan los recursos suficientes a istiod o a que el tamaño del clúster es demasiado grande.
Existen varias soluciones posibles para este problema:
En el caso de Cloud Service Mesh en el clúster, si tus herramientas de supervisión (Prometheus,
Stackdriver, etc.) muestran un alto uso de un recurso por parte de istiod, aumenta
la asignación de ese recurso. Por ejemplo, aumenta el límite de CPU o memoria
de la implementación de istiod. Esta es una solución temporal, y te recomendamos que investigues los métodos para reducir el consumo de recursos.
Si encuentras este problema en un clúster o implementación de gran tamaño, configura Recursos de sidecar para reducir la cantidad de estado de configuración que se envía a cada proxy.
En el caso de Cloud Service Mesh en el clúster, si el problema persiste, intenta escalar istiod horizontalmente.
Si todos los demás para solucionar problemas no lo resuelven, informa un error que detalle tu implementación y los problemas observados. Si es posible, sigue estos pasos para incluir un perfil de CPU y memoria en el informe de errores, junto con una descripción detallada del tamaño del clúster, la cantidad de Pods y la cantidad de servicios.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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.24/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."]]
