Tiempo de espera de TCP cuando kubectl u otras herramientas de terceros se conectan al servidor de API
En este artículo se describe cómo solucionar los tiempos de espera de TCP que se producen cuando kubectl u otras herramientas de terceros se usan para conectarse al servidor de API en Microsoft Azure Kubernetes Service (AKS). Para garantizar sus objetivos de nivel de servicio (SLO) y acuerdos de nivel de servicio (SLA), AKS usa planos de control de alta disponibilidad (HA) que se escalan vertical y horizontalmente, en función del número de núcleos.
Síntomas
Experimenta tiempos de espera de conexión repetidos.
Causa 1: Los pods responsables de la comunicación del plano de nodo a control no se ejecutan
Si solo se agota el tiempo de espera de los comandos de API de forma coherente, es posible que los siguientes pods no estén en estado de ejecución:
konnectivity-agenttunnelfrontaks-link
Nota:
En las versiones más recientes de AKS y tunnelfront aks-link se reemplazan por konnectivity-agent, por lo que solo verá konnectivity-agent.
Estos pods son responsables de la comunicación entre un nodo y el plano de control.
Solución: reducir el uso o el estrés de los hosts de nodo
Asegúrese de que los nodos que hospedan estos pods no se usan demasiado o están bajo estrés. Considere la posibilidad de mover los nodos a su propio grupo de nodos del sistema.
Para comprobar en qué nodo se hospeda el konnectivity-agent pod y el uso del nodo, ejecute los siguientes comandos:
# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
# Check the usage of the node hosting the pod
$ kubectl top node
Causa 2: El acceso está bloqueado en algunos puertos necesarios, FQDN y direcciones IP
Si los puertos necesarios, los nombres de dominio completos (FQDN) y las direcciones IP no están abiertas, es posible que se produzca un error en varias llamadas de comando. La comunicación segura y tunelizado en AKS entre el servidor de API y el kubelet (a través del konnectivity-agent pod) requiere que algunos de esos elementos funcionen correctamente.
Solución: abra los puertos, los FQDN y las direcciones IP necesarios.
Para más información sobre qué puertos, FQDN y direcciones IP deben abrirse, consulte Reglas de FQDN y red saliente para clústeres de Azure Kubernetes Service (AKS).
Causa 3: La extensión TLS de negociación de protocolo de capa de aplicación está bloqueada
Para establecer una conexión entre el plano de control y los nodos, el konnectivity-agent pod requiere la extensión Seguridad de la capa de transporte (TLS) para la negociación del protocolo de capa de aplicación (ALPN). Es posible que haya bloqueado previamente esta extensión.
Solución: Habilitar la extensión ALPN
Habilite la extensión ALPN en el konnectivity-agent pod para evitar tiempos de espera de TCP.
Causa 4: Los intervalos ip autorizados del servidor de API no cubren la dirección IP actual
Si usa intervalos de direcciones IP autorizados en el servidor de API, las llamadas API se bloquearán si la dirección IP no se incluye en los intervalos autorizados.
Solución: Modifique los intervalos de direcciones IP autorizadas para que abarque la dirección IP.
Cambie los intervalos de direcciones IP autorizadas para que la dirección IP esté cubierta. Para más información, consulte Actualización de los intervalos IP autorizados del servidor de API de un clúster.
Causa 5: Una aplicación o cliente pierde llamadas al servidor de API
Las llamadas GET frecuentes pueden acumular y sobrecargar el servidor de API.
Solución: use relojes en lugar de llamadas GET, pero asegúrese de que la aplicación no filtre esas llamadas.
Asegúrese de usar relojes en lugar de llamadas GET frecuentes al servidor de API. También debe asegurarse de que las aplicaciones de terceros no filtren ninguna conexión de inspección ni llamadas GET. Por ejemplo, en la arquitectura de microservicios de Istio, un error en la aplicación mezcladora crea una nueva conexión de inspección del servidor de API cada vez que se lee un secreto internamente. Dado que este comportamiento se produce a intervalos regulares, las conexiones de inspección se acumulan rápidamente. Estas conexiones hacen que el servidor de API se sobrecargue independientemente del patrón de escalado.
Causa 6: Demasiadas versiones en las implementaciones de Helm
Si usa demasiadas versiones en las implementaciones de Helm (el administrador de paquetes de Kubernetes), los nodos empiezan a consumir demasiada memoria. También da como resultado una gran cantidad de objetos (datos de ConfigMap configuración), lo que podría provocar picos de uso innecesarios en el servidor de API.
Solución: limitar el número máximo de revisiones para cada versión
Dado que el número máximo de revisiones de cada versión es infinito de forma predeterminada, debe ejecutar un comando para establecer este número máximo en un valor razonable. Para Helm 2, el comando es helm init. Para Helm 3, el comando es la actualización de Helm. Establezca el --history-max <value> parámetro al ejecutar el comando.
| Versión | Comando |
|---|---|
| Helm 2 | helm init --history-max <maximum-number-of-revisions-per-release> ... |
| Helm 3 | helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ... |
Causa 7: Se está bloqueando el tráfico interno entre nodos
Es posible que haya bloqueos internos del tráfico entre los nodos del clúster de AKS.
Solución: Solucione el error "dial tcp <Node_IP>:10250: tiempo de espera de E/S"
Causa 8: El clúster es privado
El clúster es un clúster privado, pero el cliente desde el que intenta acceder al servidor de API está en una red pública o diferente que no se puede conectar a la subred que usa AKS.
Solución: use un cliente que pueda acceder a la subred de AKS.
Dado que el clúster es privado y su plano de control está en la subred de AKS, no se puede conectar al servidor de API a menos que esté en una red que pueda conectarse a la subred de AKS. Es un comportamiento esperado.
En este caso, intente acceder al servidor de API desde un cliente de una red que pueda comunicarse con la subred de AKS. Además, compruebe que los grupos de seguridad de red (NSG) u otros dispositivos entre redes no bloquean los paquetes.
Aviso de declinación de responsabilidades sobre la información de terceros
Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.