Resolver problemas de límites de recursos en Cloud Service Mesh

En esta sección se explican los problemas habituales de Cloud Service Mesh y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.

Los problemas con los límites de recursos de Cloud Service Mesh pueden deberse a cualquiera de los siguientes motivos:

• Objetos LimitRange creados en el espacio de nombres istio-system o en cualquier espacio de nombres con la inyección automática de sidecar habilitada.
• Límites definidos por el usuario que son demasiado bajos.
• Los nodos se quedan sin memoria u otros recursos.

Posibles síntomas de problemas con los recursos:

• Cloud Service Mesh no recibe repetidamente la configuración del plano de control, lo que se indica con el error Envoy proxy NOT ready. Es normal que este error aparezca algunas veces al inicio, pero, si no es así, es preocupante.
• Problemas de red con algunos pods o nodos que dejan de estar accesibles.
• istioctl proxy-status muestra los estados de STALE en el resultado.
• OOMKilled mensajes en los registros de un nodo.
• Uso de memoria por parte de los contenedores: kubectl top pod POD_NAME --containers.
• Uso de memoria por los pods de un nodo: kubectl top node my-node.
• Envoy se ha quedado sin memoria: kubectl get pods muestra el estado OOMKilled en la salida.

Los sidecars tardan mucho en recibir la configuración

La propagación lenta de la configuración puede deberse a que no se han asignado suficientes recursos a istiod o a que el tamaño del clúster es excesivamente grande.

Este problema puede deberse a varios motivos:

1. En el caso de Cloud Service Mesh en el clúster, si tus herramientas de monitorización (Prometheus, Stackdriver, etc.) muestran un uso elevado de un recurso por parte de istiod, aumenta la asignación de ese recurso. Por ejemplo, aumenta el límite de CPU o de memoria de la implementación de istiod. Esta es una solución temporal y te recomendamos que investigues métodos para reducir el consumo de recursos.

2. Si te encuentras con este problema en un clúster o una implementación de gran tamaño, reduce la cantidad de estado de configuración que se envía a cada proxy configurando recursos de sidecar.

3. En el caso de Cloud Service Mesh en clústeres, si el problema persiste, prueba a escalar horizontalmente istiod.

4. Si no se resuelve el problema con ningún otro paso, informa de un error detallando tu implementación y los problemas observados. Sigue estos pasos para incluir un perfil de CPU o memoria en el informe de errores, si es posible, junto con una descripción detallada del tamaño del clúster, el número de pods y el número de servicios.