Solución de problemas de implementaciones de Traffic Director

En esta guía, se proporciona información para ayudarte a resolver problemas de configuración de Traffic Director.

Ubicaciones de registros de Envoy

Para solucionar ciertos problemas, debes examinar los registros del proxy de Envoy.

En Google Kubernetes Engine, los proxies de Envoy se ejecutan con los Pods de la aplicación, por lo que ves los errores en los registros del Pod de la aplicación si filtras por el contenedor istio-proxy. Si el clúster tiene habilitado el registro de cargas de trabajo, puedes verlos en Cloud Logging.

A continuación, se muestra un filtro posible:

resource.type="k8s_container"
resource.labels.project_id="PROJECT-NAME"
resource.labels.location="CLUSTER-ZONE"
resource.labels.cluster_name="CLUSTER-NAME"
resource.labels.namespace_name="WORKLOAD-NAMESPACE"
labels.k8s-pod/app="WORKLOAD-NAME"
resource.labels.container_name="istio-proxy"

Si el registro de cargas de trabajo no está habilitado en el clúster, puedes ver los errores mediante un comando como el que se muestra a continuación:

kubectl logs $(kubectl get po -l app=WORKLOAD-NAME -o=jsonpath='{.items[0].metadata.name}') -c istio-proxy --tail 50 #NOTE: This assumes the default namespace.

También puedes ver los registros de todos los Envoy que se ejecutan en todos los clústeres y cualquier carga de trabajo con el siguiente filtro:

resource.type="k8s_container"
resource.labels.container_name="istio-proxy"

Con Compute Engine y la implementación manual, define el LOG_DIR antes de ejecutar la secuencia de comandos run.sh en la guía de configuración.

Por ejemplo: LOG_DIR='/var/log/envoy/'

De forma predeterminada, los errores se muestran en /var/log/envoy/envoy.err.log.

Si el usuario no realizó ninguna configuración adicional para exportar esto a Logging, los errores solo serán visibles si estableces una conexión SSH a la instancia y obtienes este archivo.

Si usas la implementación automática de Envoy, puedes establecer una conexión SSH a la instancia para obtener el archivo de registro. Es probable que la ruta de acceso del archivo sea la misma que figura arriba.

Los proxies no se conectan a Traffic Director

Si los proxies no se conectan a Traffic Director, haz lo siguiente:

  • Conéctate a trafficdirector.googleapis.com para buscar errores en los registros del proxy de Envoy.
  • Si configuraste netfilter (a través de iptables) a fin de redireccionar todo el tráfico al proxy de Envoy, asegúrate de que el usuario (UID) que usas para ejecutar el proxy esté excluido del redireccionamiento. De lo contrario, esto hace que el tráfico se envíe en bucle al proxy de forma continua.
  • Asegúrate de habilitar la API de Traffic Director para el proyecto. En API y servicios del proyecto, busca errores de la API de Traffic Director.
    Ir a la página Biblioteca de API
  • Confirma que el permiso de acceso a la API de la VM esté configurado para permitir el acceso completo a las API de GCP. Para ello, especifica --scopes=https://www.googleapis.com/auth/cloud-platform en el momento de la creación de la VM.
  • Confirma que la cuenta de servicio tenga los permisos correctos. Si deseas obtener más información, consulta Habilita la cuenta de servicio para acceder a la API de Traffic Director.
  • Confirma que puedes acceder a trafficdirector.googleapis.com:443 desde la VM. Si hay problemas con este acceso, es posible que el firewall impida el acceso al trafficdirector.googleapis.com a través del puerto TCP 443 o que haya problemas de resolución de DNS para el nombre de host de trafficdirector.googleapis.com.
  • Si usas Envoy para el proxy de sidecar, confirma que la versión de Envoy sea la versión 1.9.1 o posterior.

No se puede acceder al servicio configurado con Traffic Director

Si no se puede acceder a un servicio configurado con Traffic Director, confirma que el proxy de sidecar esté en ejecución y pueda conectarse a Traffic Director.

Si usas Envoy como el proxy de sidecar, puedes ejecutar los siguientes comandos para confirmarlo.

  1. Desde la línea de comandos, confirma que el proceso de Envoy esté en ejecución.

    ps aux | grep envoy
    
  2. Inspecciona la configuración del entorno de ejecución de Envoy para confirmar que Traffic Director configuró los recursos dinámicos. Para ver la configuración, ejecuta este comando:

    curl http://localhost:15000/config_dump
    
  3. Asegúrate de que la interceptación de tráfico para el proxy de sidecar esté configurada de forma correcta.

Para la configuración de redireccionamiento con iptables, ejecuta el comando iptables y, luego, grep el resultado a fin de asegurarte de que las reglas estén allí:

sudo iptables -t nat -S | grep ISTIO

El siguiente es un ejemplo del resultado de la interceptación que realiza iptables en la VIP 10.0.0.1/32 y que reenvía a un proxy de Envoy que se ejecuta en el puerto 15001 como UID 1006:

-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN

Si la instancia de VM se crea a través de GCP Console, algunos módulos relacionados con IPv6 no estarán instalados ni disponibles antes de un reinicio. Esto hace que iptables falle debido a dependencias faltantes. En este caso, reinicia la VM y vuelve a ejecutar el proceso de configuración, lo que debería resolver el problema. No se espera que una VM de Compute Engine que creaste mediante los comandos de gcloud tenga este problema.

El servicio deja de ser accesible cuando se configura el registro de acceso de Envoy

Si usaste TRAFFICDIRECTOR_ACCESS_LOG_PATH a fin de configurar el registro de acceso de Envoy como se describe en Configura atributos adicionales para proxies de sidecar, asegúrate de que el usuario del sistema que ejecuta el proxy de Envoy tenga permiso para escribir en la ubicación de registro de acceso especificada.

Si no se proporcionan los permisos necesarios, los objetos de escucha no se programarán en el proxy. Esto se puede detectar si se busca el siguiente mensaje de error en el registro del proxy de Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_LISTENER:
unable to open file '/var/log/envoy.log': Permission denied

Si deseas resolver el problema, cambia los permisos del archivo seleccionado para que el usuario de Envoy pueda escribir en el registro de acceso.

Las aplicaciones no pueden conectarse a servicios que no se configuraron en Traffic Director

Asegúrate de haber configurado la interceptación de tráfico solo para las direcciones IP de los servicios configurados en Traffic Director. Si se intercepta todo el tráfico, el proxy de sidecar descarta en silencio las conexiones a los servicios que no se configuraron en Traffic Director.

El tráfico se repite de forma continua dentro de un nodo o un nodo falla

Si netfilter (iptables) se configura para interceptar todo el tráfico, asegúrate de que el usuario (UID) que se usa a fin de ejecutar el proxy de sidecar esté excluido de la interceptación del tráfico. De lo contrario, el tráfico que envía el proxy de sidecar se repite de forma indefinida en el proxy. Como resultado, el proceso del proxy de sidecar puede fallar. En la configuración de referencia, las reglas de netfilter no interceptan el tráfico del usuario del proxy.

Comportamiento de Traffic Director cuando la mayoría de los extremos están en mal estado

Cuando el 99% de los extremos no están en buen estado, Traffic Director mejora la confiabilidad mediante la configuración del plano de datos para ignorar el estado de los extremos y balancear el tráfico entre todos los extremos, ya que es posible que el puerto de entrega aún funcione.

Mensajes de error en los registros de Envoy indican un problema de configuración

Si tienes problemas con la configuración de Traffic Director, es posible que veas cualquiera de estos mensajes de error en los registros de Envoy:

  • warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Traffic Director configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
  • warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Traffic Director configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
  • warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Requested entity was not found.
  • warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Requested entity was not found.
  • Traffic Director configuration was not found.

Por lo general, este mensaje de error indica que Envoy solicita la configuración de Traffic Director, pero no se puede encontrar ninguna configuración que coincida. Cuando Envoy se conecta a Traffic Director, presenta un nombre de red de VPC (por ejemplo, my-network). Luego, Traffic Director busca reglas de reenvío que (1) tengan el esquema de balanceo de cargas INTERNAL_SELF_MANAGED y (2) hagan referencia al mismo nombre de red (por ejemplo, my-network).

  1. Asegúrate de que haya una regla de reenvío en tu red que tenga el esquema de balanceo de cargas INTERNAL_SELF_MANAGED. Ten en cuenta la red de VPC de la regla de reenvío.

  2. Si usas Traffic Director con implementaciones automatizadas de Envoy en Compute Engine, asegúrate de que el valor proporcionado para la marca --service-proxy:network coincida con el nombre de red de la regla de reenvío.

  3. Si usas Traffic Director con implementaciones manuales de Envoy en Compute Engine, revisa el archivo de arranque de Envoy:

    1. Verifica el valor de la variable TRAFFICDIRECTOR_NETWORK_NAME y asegúrate de que su valor coincida con el nombre de red de la regla de reenvío.
    2. Asegúrate de que el número de proyecto esté configurado en la variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER en el archivo de arranque de Envoy.
  4. Si implementas en GKE y usas el inyector automático, asegúrate de que el número de proyecto y el nombre de red estén configurados de manera correcta, según las instrucciones en Configuración de Traffic Director para Pods de Google Kubernetes Engine con inyección automática de Envoy.

Soluciona problemas de implementaciones automatizadas de Envoy

En esta sección, se proporcionan instrucciones para solucionar problemas de implementaciones automatizadas de Envoy.

Canales de comunicación para solucionar problemas

Los procesos de arranque de VM y de Envoy, y las operaciones de administración del ciclo de vida adicionales pueden fallar por diversos motivos, incluidos los problemas de conectividad temporales, los repositorios dañados, los errores en las secuencias de comandos de arranque y en los agentes de VM, y las acciones inesperadas del usuario.

Google Cloud proporciona canales de comunicación que puedes usar para comprender el proceso de arranque y el estado actual de los componentes que residen en las VM.

Registro de salida de puertos en serie virtuales

Por lo general, el sistema operativo de una VM, el BIOS y otras entidades a nivel de sistema escriben salidas en los puertos en serie. La salida es útil para solucionar fallas del sistema, arranques con fallas, problemas de inicio y problemas de cierre.

Los agentes de arranque de Compute Engine registran todas las acciones realizadas en el puerto en serie 1, junto con los eventos del sistema, a partir de la instalación básica del paquete. Para ello, obtiene los datos del servidor de metadatos de una instancia, la configuración de iptables y el estado de instalación de Envoy.

El agente en VM registra el estado del proceso de Envoy, los servicios de Traffic Director recién descubiertos y cualquier otra información que pueda ser útil cuando investigas problemas con las VM.

Registro de Cloud Monitoring

Los datos expuestos en la salida del puerto en serie también se registran en Monitoring, que usa la biblioteca Golang y exporta los registros a un registro independiente para reducir el ruido. Ten en cuenta que este es un registro a nivel de instancia, por lo que los registros del proxy de servicio pueden encontrarse en la misma página que los otros registros de la instancia.

Atributos de invitado de la VM

Los atributos de invitado son un tipo específico de metadatos personalizados en los que las aplicaciones pueden escribir mientras se ejecutan en la instancia. Cualquier aplicación o usuario en las instancias puede leer y escribir datos en estos valores de metadatos de atributos de invitado.

Las secuencias de comandos de arranque de Envoy y los agentes en VM de Compute Engine exponen los atributos con información sobre el proceso de arranque y el estado actual de Envoy. Todos los atributos de invitado están expuestos en el espacio de nombres gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ --zone ZONE

Si encuentras algún problema, te recomendamos que verifiques el valor de los atributos de invitado bootstrap-status y bootstrap-last-failure. Cualquier valor bootstrap-status que no sea FINISHED indica que el entorno de Envoy aún no se configuró. El valor de bookstrap-last-failure podría indicar cuál es el problema.

No se puede acceder al servicio de Traffic Director desde una VM creada mediante una plantilla de instancias habilitada para el proxy de servicio

Sigue estos pasos para solucionar el problema.

  1. Es posible que la instalación de los componentes del proxy de servicio en la VM no se haya completado o que falle.

    Usa el siguiente comando para determinar si todos los componentes están instalados de forma correcta.

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    

    El atributo de invitado bootstrap-status se configuró como una de las siguientes opciones:

    • [none] indica que todavía no comenzó la instalación. Es posible que la VM aún se esté iniciando. Vuelve a verificar el estado en unos minutos.
    • IN PROGRESS indica que la instalación y la configuración de los componentes del proxy de servicio aún no se completaron. Repite la verificación de estado para obtener actualizaciones sobre el proceso.
    • FAILED indica que la instalación o la configuración de un componente falló. Verifica el mensaje de error mediante una consulta al atributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica que el proceso de instalación y configuración finalizó sin errores. Usa las instrucciones que se encuentran a continuación para verificar que la interceptación del tráfico y el proxy de Envoy estén configurados de forma correcta.
  2. La interceptación de tráfico en la VM no se configuró de forma correcta para los servicios basados en Traffic Director.

    Accede a la VM y verifica la configuración de iptables:

    gcloud compute ssh INSTANCE_NAME --zone=ZONE
    sudo iptables -L -t nat
    

    Examina la cadena SERVICE_PROXY_SERVICE_CIDRS para entradas SERVICE_PROXY_REDIRECT como las siguientes:

    Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
    target           prot opt source              destination  ...
    SERVICE_PROXY_REDIRECT  all  --  anywhere             10.7.240.0/20
    

    Para cada servicio, debe haber una dirección IP o un CIDR coincidente en la columna destination. Si no hay una entrada para la VIP, hay un problema en la propagación de la configuración del proxy de Envoy desde Traffic Director, o el agente en VM falló.

  3. Los proxies de Envoy aún no recibieron su configuración de Traffic Director.

    Accede a la VM y verifica la configuración del proxy de Envoy:

    gcloud compute ssh INSTANCE_NAME --zone=ZONE
    sudo curl localhost:15000/config_dump
    

    Examina la configuración del objeto de escucha que se recibió desde Traffic Director. Por ejemplo:

    "dynamic_active_listeners": [
      ...
      "filter_chains": [{
        "filter_chain_match": {
          "prefix_ranges": [{
            "address_prefix": "10.7.240.20",
            "prefix_len": 32
          }],
          "destination_port": 80
        },
      ...
        "route_config_name": "URL_MAP/[PROJECT_NUMBER].td-routing-rule-1"
      ...
    ]
    

    address_prefix es la VIP del servicio de Traffic Director. Apunta al mapa de URL llamado td-routing-rule-1. Verifica si el servicio al que deseas conectarte ya está incluido en la configuración del objeto de escucha.

  4. El agente en VM no está en ejecución.

    El agente en VM configura de forma automática la interceptación del tráfico cuando se crean servicios de Traffic Director nuevos. Si el agente no está en ejecución, todo el tráfico hacia los servicios nuevos se dirige directamente a las VIP, se evita el proxy de Envoy y se agota el tiempo de espera.

    Para verificar el estado del agente en VM, ejecuta el siguiente comando:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    
  5. Puedes examinar los atributos del agente en VM. El valor del atributo agent-heartbeat tiene la hora en la que el agente realizó una acción o verificación por última vez. Si el valor tiene más de cinco minutos, el agente se detiene y debes volver a crear la VM mediante el comando gcloud compute instance-groups managed recreate-instance.

  6. El atributo agent-last-failure expone el último error que ocurrió en el agente. Puede ser un problema transitorio y resolverse la próxima vez que el agente realice una verificación, por ejemplo, si el error es Cannot reach the Traffic Director API server, o puede ser un error permanente. Espera unos minutos y vuelve a verificar el error.

La interceptación de tráfico entrante se configura en el puerto de carga de trabajo, pero no puedes conectarte al puerto desde fuera de la VM

Sigue estos pasos para solucionar el problema.

  1. Es posible que la instalación de los componentes del proxy de servicio en la VM no se haya completado o que falle.

    Usa el siguiente comando para determinar si todos los componentes están instalados de forma correcta.

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    

    El atributo de invitado bootstrap-status se configuró como una de las siguientes opciones:

    • [none] indica que todavía no comenzó la instalación. Es posible que la VM aún se esté iniciando. Vuelve a verificar el estado en unos minutos.
    • IN PROGRESS indica que la instalación y la configuración de los componentes del proxy de servicio aún no se completaron. Repite la verificación de estado para obtener actualizaciones sobre el proceso.
    • FAILED indica que la instalación o la configuración de un componente falló. Verifica el mensaje de error mediante una consulta al atributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica que el proceso de instalación y configuración finalizó sin errores. Usa las instrucciones que se encuentran a continuación para verificar que la interceptación del tráfico y el proxy de Envoy estén configurados de forma correcta.
  2. La interceptación del tráfico en la VM no se configuró de forma correcta para el tráfico entrante.

    Accede a la VM y verifica la configuración de iptables:

    gcloud compute ssh INSTANCE_NAME --zone=ZONE
    sudo iptables -L -t nat
    

    Examina la cadena SERVICE_PROXY_INBOUND para entradas SERVICE_PROXY_IN_REDIRECT como la siguiente:

    Chain SERVICE_PROXY_INBOUND (1 references)
    target     prot opt source               destination
    ...
    SERVICE_PROXY_IN_REDIRECT  tcp  --  anywhere  anywhere  tcp dpt:mysql
    

    Para cada puerto que se define en service-proxy:serving-ports, debe haber un puerto coincidente en la columna destination. Si no hay una entrada para el puerto, todo el tráfico entrante va directamente a este puerto y se omite el proxy de Envoy.

    Verifica que no haya otras reglas que abandonen el tráfico a este puerto o a todos los puertos, excepto un puerto específico.

  3. Los proxies de Envoy aún no recibieron su configuración para el puerto entrante de Traffic Director.

    Accede a la VM y verifica la configuración del proxy de Envoy:

    gcloud compute ssh INSTANCE_NAME --zone=ZONE
    sudo curl localhost:15000/config_dump
    

    Busca la configuración del objeto de escucha entrante proveniente de Traffic Director:

    "dynamic_active_listeners": [
      ...
      "filter_chains": [{
        "filter_chain_match": {
          "prefix_ranges": [{
            "address_prefix": "10.0.0.1",
            "prefix_len": 32
          }],
          "destination_port": 80
        },
      ...
        "route_config_name": "inbound|default_inbound_config-80"
      ...
    ]
    

    El route_config_name, que comienza con inbound, indica un servicio especial que se creó para fines de interceptación de tráfico entrante. Verifica si el puerto al que deseas conectarte ya está incluido en la configuración del objeto de escucha en destination_port.

¿Qué sigue?