Resuelve problemas de administración de tráfico en Cloud Service Mesh
En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos de ellos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Errores de conexión del servidor de la API en los registros 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 instalación de istio-cni incompleta
- Permisos insuficientes de pods de cargas de trabajo (falta el permiso
CAP_NET_ADMIN
)
Si usas el complemento de CNI de Istio, verifica 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 host
buscar en los registros del nodo los comandos de nsenter
y ver si hay algún error
presente.
Si no usas el complemento de CNI de Istio, verifica que el Pod de carga de trabajo tenga
El permiso CAP_NET_ADMIN
, que el inyector de sidecar establece 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-proxy
hasta que la aplicación reciba un código 200. El extremo de estadoistio-proxy
es el siguiente:http://localhost:15020/healthz/ready
Agrega un mecanismo de solicitud de reintento a la carga de trabajo de tu aplicación.
La lista de puertas de enlace muestra resultados vacíos
Síntoma: Cuando enumeras las puertas de enlace con kubectl get gateway --all-namespaces
después de crear correctamente una puerta de enlace de Cloud Service Mesh, el comando muestra No resources found
.
Este problema puede ocurrir en GKE 1.20 y versiones posteriores, ya que el controlador de puerta de enlace de GKE instala de forma automática el recurso Gateway.networking.x-k8s.io/v1alpha1
de GKE en clústeres. Para solucionar el problema, haz lo siguiente:
Verifica si hay varios recursos personalizados de puerta de enlace en el clúster:
kubectl api-resources | grep gateway
Salida de ejemplo:
gateways gw networking.istio.io/v1beta1 true Gateway gatewayclasses gc networking.x-k8s.io/v1alpha1 false GatewayClass gateways gtw networking.x-k8s.io/v1alpha1 true Gateway
Si la lista muestra entradas distintas de las puertas de enlace con
apiVersion
networking.istio.io/v1beta1
, usa el nombre completo del recurso o los nombres cortos distintos en el comandokubectl
. Por ejemplo, ejecutakubectl get gw
okubectl get gateways.networking.istio.io
en lugar dekubectl get gateway
para asegurarte de que se muestren las puertas de enlace de Istio.
Para obtener más información sobre este problema, consulta Puertas de enlace de Kubernetes y Puertas de enlace de Istio.