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 deiptables
) 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 altrafficdirector.googleapis.com
a través del puerto TCP443
o que haya problemas de resolución de DNS para el nombre de hosttrafficdirector.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:
Desde la línea de comandos, confirma que el proceso de Envoy esté en ejecución:
ps aux | grep envoy
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
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 comandoiptables
y, luego, usagrep
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 puerto15001
como UID1006
:-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:
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.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.Si usas Traffic Director con implementaciones manuales de Envoy en Compute Engine, revisa el archivo de arranque de Envoy en busca de lo siguiente:
- 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. - Asegúrate de que el número de proyecto esté configurado en la variable
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
.
- Asegúrate de que el valor de la variable
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:
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 atributogce-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.
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 entradasSERVICE_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ó.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 llamadotd-routing-rule-1
. Verifica si el servicio al que deseas conectarte ya está incluido en la configuración del objeto de escucha.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.
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
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
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 esCannot 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:
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 atributogce-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.
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 entradasSERVICE_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 columnadestination
. 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.
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 coninbound
, 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 endestination_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 archivospecs/01-configmap.yaml
no es correcto. El valor debe sertrafficdirector.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:
- Verifica el estado del servicio de backend en la consola de Google Cloud.
Ir a los servicios de Traffic Director - Asegúrate de que el registro esté habilitado para el recurso
HealthCheck
. - Si las verificaciones de estado comenzaron a fallar recientemente, inspecciona los registros de auditoría de Cloud para determinar si la configuración de
HealthCheck
cambió recientemente.
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:
- Verifica los conflictos de políticas de extremos que informa Traffic Director.
- Inspecciona los registros de auditoría de Cloud para verificar si la configuración del usuario (en particular,
EndpointPolicy
,ServerTlsPolicy
oAuthorizationPolicy
) cambió recientemente.
¿Qué sigue?
- Para obtener información sobre cómo funciona Traffic Director, consulta la descripción general de Traffic Director.
- Para resolver problemas de configuración cuando implementas servicios de gRPC sin proxy, consulta Soluciona problemas de implementaciones que usan gRPC sin proxy.
- Si deseas obtener asistencia adicional para usar Traffic Director, consulta Obtén asistencia.