Resolver problemas de gestión del tráfico 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.

Errores de conexión del servidor de la API en los registros de istiod

Istiod no puede ponerse en contacto 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

Puede usar la cadena de expresión regular /error.*cannot list resource/ para encontrar este error en los registros.

Este error suele ser temporal y, si has accedido a los registros del proxy mediante kubectl, es posible que el problema ya se haya resuelto. Este error suele deberse 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 tiene una configuración de alta disponibilidad para realizar una actualización o un cambio de escalado automático.

El contenedor istio-init falla

Este problema puede producirse 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 incompleta de istio-cni
  • Permisos insuficientes del pod de carga de trabajo (falta el permiso CAP_NET_ADMIN)

Si usas el complemento CNI de Istio, comprueba que has seguido las instrucciones por completo. Verifica que el contenedor istio-cni-node esté listo y consulta los registros. Si el problema persiste, establece una conexión Shell segura (SSH) con el nodo host y busca comandos nsenter en los registros del nodo para ver si hay algún error.

Si no usas el complemento CNI de Istio, comprueba que el pod de la carga de trabajo tenga permiso CAP_NET_ADMIN, que el inyector de sidecar define automáticamente.

Conexión rechazada después de que se inicie el pod

Cuando un pod se inicia y recibe connection refused al intentar conectarse a un endpoint, el problema puede ser que el contenedor de la aplicación se haya iniciado antes que el 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 está escuchando en el puerto.

En ese caso, puedes hacer lo siguiente:

  • Modifica el código de inicio de tu aplicación para que envíe solicitudes continuas al endpoint de estado istio-proxy hasta que la aplicación reciba el código 200. El punto de conexión de estado de istio-proxy es el siguiente:

    http://localhost:15020/healthz/ready

  • Añade un mecanismo de solicitud de reintento a la carga de trabajo de tu aplicación.

Al enumerar las pasarelas, no se devuelve nada

Síntoma: Cuando enumeras las pasarelas con kubectl get gateway --all-namespaces después de crear correctamente una pasarela de Cloud Service Mesh, el comando devuelve No resources found.

Este problema puede producirse en GKE 1.20 y versiones posteriores porque el controlador de GKE Gateway instala automáticamente el recurso Gateway.networking.x-k8s.io/v1alpha1 de GKE en los clústeres. Para solucionar el problema, sigue estos pasos:

  1. Comprueba si hay varios recursos personalizados de gateway en el clúster:

    kubectl api-resources | grep gateway

    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

  2. Si en la lista se muestran entradas que no son de tipo Gateway con el valor apiVersion networking.istio.io/v1beta1, usa el nombre de recurso completo o los nombres cortos distinguibles en el comando kubectl. Por ejemplo, ejecuta kubectl get gw o kubectl get gateways.networking.istio.io en lugar de kubectl get gateway para asegurarte de que se muestran las pasarelas de Istio.

Para obtener más información sobre este problema, consulta Kubernetes Gateways e Istio Gateways.