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

En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. 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 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, comprueba que hayas seguido las instrucciones por completo. Verifica que el contenedor istio-cni-node esté listo y revisa 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, 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 con kubectl get gateway --all-namespaces después de crear correctamente una puerta de enlace de Cloud Service Mesh, el comando devuelve 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

    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

  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.

El proxy de Envoy se bloquea durante la inicialización

Si los registros de depuración indican que el proxy de Envoy se bloquea durante la inicialización, puedes usar el siguiente comando para identificar qué está bloqueando el proceso:

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

Soluciona problemas de errores de respuesta HTTP 5xx

Es posible que encuentres errores de respuesta HTTP 5xx cuando accedas a las aplicaciones a través de la puerta de enlace de entrada de Istio. Sigue estos pasos para diagnosticar y resolver el problema.

  1. Identifica el plano de control
  2. Verifica posibles configuraciones incorrectas
  3. Verifica el descubrimiento de Pods
  4. Analiza los registros de acceso

Identifica el plano de control

Determina la versión y la configuración del plano de control, ya que las diferentes versiones pueden influir en los procesos de diagnóstico. Para verificar el estado del plano de control administrado, ejecuta el siguiente comando:

gcloud container fleet mesh describe --project PROJECT_ID

El estado ACTIVE indica que el plano de control administrado se ejecuta con normalidad.

Verifica posibles errores de configuración

Los errores de configuración comunes pueden provocar fallas en el enrutamiento:

  • No coincide el espacio de nombres: El VirtualService debe estar en el mismo espacio de nombres que el servicio de GKE de backend.
  • Incoherencia en la referencia de la puerta de enlace: El VirtualService debe hacer referencia de forma explícita al Gateway correcto. Por ejemplo, si VirtualService hace referencia a istio-system/istio-ingressgateway, pero la puerta de enlace está en el espacio de nombres default, el tráfico no se enrutará correctamente.

Verifica el descubrimiento del pod

Asegúrate de que la malla detecte correctamente el pod de la aplicación:

istioctl proxy-config endpoints POD_NAME

Analiza los registros de acceso

Habilita los registros de acceso para determinar si los errores provienen de la aplicación de backend o del proxy. Los campos clave incluyen RESPONSE_FLAGS, UPSTREAM_LOCAL_ADDRESS y RESPONSE_CODE.

Si los registros indican errores de upstream, realiza una prueba curl directa en el servicio de GKE desde un pod en el mismo espacio de nombres. Si la solicitud curl devuelve el mismo error 5xx, el problema se origina en la propia aplicación de backend.

Soluciona problemas relacionados con los certificados SSL

Los errores de certificado SSL en la puerta de enlace de entrada de Istio pueden deberse a certificados vencidos, incompatibilidades de protocolos o configuraciones de secretos incorrectas.

Cómo identificar errores de SSL

Revisa los registros del Pod de la puerta de enlace de entrada de Istio:

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

Verifica certificados y claves

Asegúrate de que el certificado y la clave privada sean válidos y coincidan con los hashes MD5:

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

Confirma que el certificado no haya vencido y que el nombre común (CN) o el nombre alternativo del sujeto (SAN) coincidan con el dominio.

Verifica la configuración del protocolo y el secreto de TLS

Verifica la versión de TLS y los conjuntos de algoritmos de cifrado en la CRD Gateway. Asegúrate de que el secreto de Kubernetes que contiene el certificado y la clave esté en el mismo espacio de nombres que la puerta de enlace de entrada y de que credentialName coincida con el nombre del secreto.

Soluciona problemas de tiempos de espera intermitentes para extremos externos

Es posible que se produzcan tiempos de espera intermitentes cuando se realizan solicitudes a extremos externos (como el NLB de terceros) que se resuelven en varias direcciones IP.

Causa posible: Resolución de ServiceEntry

Si spec.resolution se establece en DNS, Istio usa el "DNS estricto", que balancea la carga en todas las direcciones IP resueltas. Algunos NLB no admiten esta opción.

Solución

Para resolver este problema, configura la resolución en ServiceEntry como DNS_ROUND_ROBIN.

Solución de problemas relacionados con la distribución desigual del tráfico

Si el tráfico no se distribuye de manera uniforme entre los pods de la aplicación, verifica lo siguiente:

  • Estado del Pod: Asegúrate de que todos los Pods de la aplicación estuvieran en buen estado durante el desequilibrio.
  • Algoritmo de balanceo de cargas: Revisa la configuración de DestinationRule para el parámetro de configuración loadBalancer (p.ej., consistentHash o ROUND_ROBIN).
  • Balanceo de cargas de localidad: Verifica si localityLbSetting está habilitado. Ten en cuenta que esto no es compatible con el plano de control de TRAFFIC_DIRECTOR.

Soluciona problemas de propagación de servicios y cuotas

Si no se reflejan los servicios nuevos o las configuraciones de redes en la malla, es posible que se hayan alcanzado las cuotas de recursos en el proyecto de la flota.

Síntomas

  • Las configuraciones de redes (como VirtualService o DestinationRule) no se envían a los proxies de sidecar.
  • Los servicios nuevos aparecen "invisibles" para la malla a pesar de estar definidos correctamente.

Pasos para identificar y resolver el problema

  1. Verifica las cuotas de recursos: Comprueba si el proyecto de la flota alcanzó su cuota para los recursos BackendService. Para ello, verifica la cuota de servicios de backend del director de tráfico interno global en el proyecto de la flota. Por lo general, Cloud Service Mesh crea un objeto BackendService por cada puerto de servicio de Kubernetes.
  2. Revisa las limitaciones de escala: Asegúrate de que tu configuración se mantenga dentro de las limitaciones de escala admitidas para Cloud Service Mesh.
  3. Aumenta las cuotas: Si se alcanzaron las cuotas, solicita un aumento para el recurso afectado en el proyecto de la flota y restablece la propagación normal del servicio.

Soluciona problemas de evaluación de VirtualService

Si un VirtualService no se comporta como se espera, recuerda que las rutas se evalúan en el orden en que aparecen en la lista. Cuando tienes varios servicios virtuales para el mismo host, sus rutas se combinan. Se priorizan las rutas de los servicios virtuales "más antiguos", por lo que se colocan antes de las rutas de los "más nuevos" en la lista combinada. Esto refuerza la regla de "primera coincidencia".