Resuelve los problemas de administración del tráfico en Anthos Service Mesh

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-proxy hasta que la aplicación reciba un código 200. El extremo de estado istio-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 mediante kubectl get gateway --all-namespaces después de crear de forma correcta una puerta de enlace de Anthos 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:

  1. Verifica si hay varios recursos personalizados de puerta de enlace en el clúster:

    kubectl api-resources | grep gateway
    

    Resultado 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

  2. 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 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 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.