Soluciona problemas de implementaciones de Envoy

En esta guía, se proporciona información para ayudarte a resolver problemas de configuración de Traffic Director. Para obtener información sobre cómo usar la API de Client Status Discovery Service (CSDS) a fin de ayudarte a investigar problemas con Traffic Director, consulta Comprende el estado de cliente de Traffic Director.

Determina la versión de Envoy instalada en una VM

Usa estas instrucciones para verificar qué versión de Envoy se ejecuta en una instancia de máquina virtual (VM).

Determina la versión con la implementación automática de Envoy

Para verificar o comprobar la versión de Envoy con la implementación automática, puedes hacer lo siguiente:

  • Verifica los atributos de invitado de la VM en la ruta gce-service-proxy/proxy-version:

    gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME \
  --zone ZONE --query-path=gce-service-proxy/proxy-version

NAMESPACE          KEY            VALUE
gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

  • Verifica los registros de instancias de Cloud Logging en la página de detalles de Logging de la instancia de VM en la consola de Google Cloud con una consulta como la siguiente:

    resource.type="gce_instance"
resource.labels.instance_id="3633122484352464042"
jsonPayload.message:"Envoy version"

    Recibes una respuesta como la que se muestra a continuación:

    {
"insertId": "9zy0btf94961a",
"jsonPayload": {
  "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
  "localTimestamp": "2021-01-12T11:39:14.3991Z"
},
"resource": {
  "type": "gce_instance",
  "labels": {
    "zone": "asia-southeast1-b",
    "instance_id": "3633122484352464042",
    "project_id": "cloud-vm-mesh-monitoring"
  }
},
"timestamp": "2021-01-12T11:39:14.399200504Z",
"severity": "INFO",
"logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
"receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
}

  • Usa SSH para conectarte a una VM y verificar la versión binaria:

    YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

  • Usa SSH para conectarte a una VM y la interfaz de administrador como raíz:

    root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
{
"version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
"state": "LIVE",
"hot_restart_version": "disabled",
...
}

Determina la versión con la implementación manual de Envoy

Para verificar o comprobar la versión de Envoy con la implementación manual, puedes hacer lo siguiente:

  • Usa SSH para conectarte a una VM y verificar la versión binaria:

    YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

  • Usa SSH para conectarte a una VM y la interfaz de administrador como raíz:

    root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
{
"version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
"state": "LIVE",
"hot_restart_version": "disabled",
...
}

Ubicaciones de registros de Envoy

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

En Google Kubernetes Engine (GKE), los proxies de Envoy se ejecutan con los Pods de la aplicación. Verás cualquier error en los registros del Pod de la aplicación filtrados por el contenedor envoy.

  • Si el clúster tiene habilitado el registro de cargas de trabajo, puedes ver los errores en Cloud Logging. A continuación, se muestra un posible filtro:

    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="envoy"

  • Si el registro de cargas de trabajo no está habilitado en el clúster, puedes ver los errores mediante un comando como el siguiente:

    kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --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="envoy"

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 el siguiente registro:

    /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 usas SSH a fin de conectarte a la instancia y obtener este archivo.

Si usas la implementación automática de Envoy, puedes usar SSH para conectarte a la instancia y obtener el archivo de registro. Es probable que la ruta de acceso sea la misma que la que se mencionó antes.

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.

  • Confirma que el permiso de acceso a la API de la VM esté configurado para permitir el acceso completo a las API de Google Cloud. Para ello, especifica lo siguiente cuando crees la VM:

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • 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 un 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 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, usa grep para 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 iptables interceptando la dirección IP virtual (VIP) 10.0.0.1/32 y reenviándola 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 la consola de Google Cloud, 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 la CLI de Google Cloud 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 un registro de acceso de Envoy como se describe en Configura los atributos de arranque de Envoy para Traffic Director, asegúrate de que el usuario del sistema que ejecuta el proxy de Envoy tenga permisos 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_PORT:
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 de forma silenciosa 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 podría fallar. En la configuración de referencia, las reglas de netfilter no interceptan el tráfico del usuario del proxy.

Los 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 último mensaje de error (Traffic Director configuration was not found) 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 tengan el esquema de balanceo de cargas INTERNAL_SELF_MANAGED y hagan referencia al mismo nombre de red de VPC.

Para resolver este error, haz lo siguiente:

  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. Anota el nombre de 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 la red de VPC 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 en busca de lo siguiente:

    1. Asegúrate de que el valor de la variable TRAFFICDIRECTOR_NETWORK_NAME coincida con el nombre de la red de VPC 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.

  4. Si implementas en GKE y usas el inyector automático, asegúrate de que el número de proyecto y el nombre de la red de VPC estén configurados de forma correcta, según las instrucciones en Configuración de Traffic Director para Pods de GKE con inyección automática de Envoy.

Soluciona problemas en las implementaciones automáticas para Compute Engine

En esta sección, se proporcionan instrucciones a fin de solucionar problemas de implementaciones automáticas de Envoy para Compute Engine.

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.

Canales de comunicación para solucionar problemas

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 del sistema escriben salidas en los puertos en serie. Este resultado es útil para solucionar fallas del sistema, inicios con errores, problemas de inicio y problemas de apagado.

Los agentes de arranque de Compute Engine registran todas las acciones realizadas en el puerto en serie 1. Esto incluye eventos del sistema, que comienzan con la instalación básica del paquete a través de la obtención de 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. Debido a que este registro es a nivel de instancia, es posible que encuentres registros de proxy de servicio en la misma página que otros registros de instancias.

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

Para corregir este problema, sigue estos pasos:

  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-failure.
    • FINISHED indica que los procesos de instalación y configuración finalizaron sin ningún error. Usa las siguientes instrucciones 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 ninguna entrada para la dirección IP virtual (VIP), significa que 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"
  ...
]

    La address_prefix es la dirección IP virtual (VIP) de un 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.

    1. Ejecuta el siguiente comando para verificar el estado del agente en VM:

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

    2. Examina 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, significa que el agente se bloqueó y debes volver a crear la VM mediante el siguiente comando:

      gcloud compute instance-groups managed recreate-instance

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

Para corregir este problema, sigue estos pasos:

  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-failure.
    • FINISHED indica que los procesos de instalación y configuración finalizaron sin ningún error. Usa las siguientes instrucciones 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 las siguientes:

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

Soluciona problemas de implementaciones automáticas de pods de GKE

En esta sección, se proporcionan instrucciones a fin de solucionar problemas de implementaciones automáticas de Envoy para pods de GKE.

Los pods no se inician después de habilitar la inserción automática de Envoy

En algunas circunstancias, es posible que los Pods de la aplicación no se inicien de forma correcta. Esto puede ocurrir cuando usas un clúster de GKE privado con reglas de firewall restrictivas.

Si deseas usar Traffic Director con un clúster de GKE privado, debes crear una regla de firewall adicional para el webhook de inyector de sidecar. Si deseas crear una regla de firewall que permita que el plano de control de GKE llegue a los Pods en el puerto TCP 9443, consulta Agrega reglas de firewall para casos de uso específicos.

Puedes observar este problema cuando creas un pod independiente o cuando una implementación intenta crear pods.

Cuando creas un pod independiente (por ejemplo, mediante kubectl apply o kubectl run), la línea de comandos de kubectl puede mostrar un mensaje de error como el siguiente:

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Cuando creas pods a partir de una implementación, puedes encontrar los siguientes síntomas:

  • kubectl get pods no muestra ningún pod asociado con la implementación.

  • kubectl get events --all-namespaces muestra un mensaje de error como el siguiente:

    Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Cuando sigues la guía de configuración, es posible que te encuentres con este problema durante el paso Implementa un cliente de muestra y verifica la inserción. Después de ejecutar kubectl create -f demo/client_sample.yaml, ejecuta kubectl get deploy busybox para ver 0/1 Pods LISTOS. También puedes encontrar el error si describes el replicaset asociado a la implementación mediante la emisión del comando kubectl describe rs -l run=client.

Se rechazó la conexión después de que verificaste la configuración

Cuando configuras Traffic Director con una inyección automática de Envoy, es posible que recibas un error de conexión rechazada cuando intentes verificar la configuración. La causa podría ser una de las siguientes opciones:

  • El valor de discoveryAddress en el archivo specs/01-configmap.yaml no es correcto. El valor debe ser trafficdirector.googleapis.com:443.
  • El valor de la red de VPC en el archivo specs/01-configmap.yaml no es correcto.
  • El valor para el proyecto de Traffic Director en el archivo specs/01-configmap.yaml no es correcto.
  • El valor de discoveryAddress es incorrecto en el Pod.
  • El inyector de sidecar de Istio se ejecuta en lugar del inyector de sidecar de Traffic Director.

Puedes ver una muestra del archivo specs/01-configmap.yaml en Configura el inyector de archivo adicional. Si el archivo specs/01-configmap.yaml no contiene valores correctos, Envoy no puede obtener la configuración de corrección de Traffic Director. Para solucionar este problema, examina el archivo specs/01-configmap.yaml y asegúrate de que los valores sean correctos. Luego, vuelve a crear el inyector automático.

Asegúrate de verificar el valor de discoveryAddress en el archivo specs/01-configmap.yaml y en el Pod. En el pod, el inyector de sidecar establece el valor. Para verificar el valor de discoveryAddress en el Pod, ejecuta este comando:

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

Deberías ver un resultado similar a este:

"discoveryAddress":"trafficdirector.googleapis.com:443"

Se rechazó la conexión con la inserción manual de Envoy y los Pods de GKE

Si recibes un mensaje de conexión rechazada, consulta los registros de Busybox para obtener información sobre si la API de Traffic Director está habilitada o si los permisos son incorrectos en los registros de Envoy.

Tiempo de espera de conexión con inyección manual de Envoy y Pods de GKE

Si recibes un mensaje de tiempo de espera de conexión, es probable que el problema sea una configuración incorrecta del mapa de URL, las reglas de reenvío o el servicio de backend en tu implementación. Verifica esos recursos para confirmar si están configurados de forma correcta.

Problemas cuando las conexiones usan protocolos que priorizan el servidor

Algunas aplicaciones, como MySQL, usan protocolos en los que el servidor envía el primer paquete. Esto significa que, luego de la conexión inicial, el servidor envía los primeros bytes. Estos protocolos y aplicaciones no son compatibles con Traffic Director.

Soluciona los problemas del estado de la malla de servicios

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

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

Para obtener una mejor confiabilidad, cuando el 99% de los extremos no están en buen estado, Traffic Director configura el plano de datos a fin de ignorar el estado de los extremos. En cambio, el plano de datos balancea el tráfico entre todos los extremos porque es posible que el puerto de entrega aún funcione.

Los backends en mal estado generan una distribución subóptima del tráfico

Traffic Director usa la información del recurso HealthCheck adjunto a un servicio de backend para evaluar el estado de los backends. Traffic Director usa este estado para enrutar el tráfico al backend en buen estado más cercano. Si algunos de tus backends están en mal estado, es posible que el tráfico se siga procesando, pero con una distribución subóptima. Por ejemplo, el tráfico podría fluir a una región en la que los backends en buen estado todavía están presentes, pero esto está mucho más lejos del cliente, lo que genera latencia. Para identificar y supervisar el estado de los backends, prueba los siguientes pasos:

Los backends rechazan el tráfico de forma inesperada

Si configuraste la seguridad del servicio de Traffic Director, usas el recurso EndpointPolicy para aplicar políticas de seguridad a los backends. Una configuración incorrecta de EndpointPolicy puede hacer que el backend rechace el tráfico. Usa los siguientes registros para solucionar este problema:

¿Qué sigue?