En esta sección, se explican los problemas comunes de Anthos Service Mesh y cómo solucionarlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Errores de conexión del servidor de la API en los registros de Istiod
Istiod no puede comunicarse con apiserver si ves errores similares a los siguientes:
error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused
Puedes usar la string de expresión regular /error.*cannot list resource/ para encontrar este error en los registros.
Por lo general, este error es transitorio y si accediste a los registros del proxy mediante kubectl, es posible que el problema ya esté resuelto. Por lo general, este error se debe a eventos que hacen que el servidor de la API no esté disponible temporalmente, como cuando se reinicia un servidor de la API que no se encuentra en una configuración de alta disponibilidad para un cambio de actualización o de ajuste de escala automático.
El contenedor istio-init falla
Este problema puede ocurrir cuando las reglas de iptables del pod no se aplican al espacio de nombres de la red del pod. Esto puede deberse a lo siguiente:
- Una política de seguridad de pods (PSP) excesivamente restrictiva
- Una instalación de istio-cni incompleta
- Permisos insuficientes de pods de cargas de trabajo (falta el permiso
CAP_NET_ADMIN)
Si usas una política de seguridad de pods que restrinja el permiso CAP_NET_ADMIN, usa el complemento de CNI de Istio en su lugar.
Si usas el complemento de CNI de Istio, comprueba que hayas seguido las instrucciones por completo.
Verifica que el contenedor istio-cni-node esté listo y verifica los registros. Si el problema persiste, establece una shell segura (SSH) en el nodo del host, busca en los registros de nodos los comandos nsenter y verifica si hay errores.
Si no usas el complemento de CNI de Istio o una política de seguridad de pods, verifica que el pod de carga de trabajo tenga el permiso CAP_NET_ADMIN, que el inyector de archivos adicionales configura automáticamente.
Se rechazó la conexión después de que se inició el Pod
Cuando se inicia un Pod y connection refused intenta conectarse a un extremo, el problema puede ser que el contenedor de la aplicación se inició antes del contenedor isto-proxy. En este caso, el contenedor de la aplicación envía la solicitud a istio-proxy, pero la conexión se rechaza porque istio-proxy aún no escucha en el puerto.
En ese caso, puede hacer lo siguiente:
Modifica el código de inicio de tu aplicación para realizar solicitudes continuas al extremo de estado
istio-proxyhasta que la aplicación reciba un código 200. El extremo de estadoistio-proxyes el siguiente:http://localhost:15020/healthz/readyAgrega un mecanismo de solicitud de reintento a la carga de trabajo de tu aplicación.