Problemas de conectividad de túnel
Microsoft Azure Kubernetes Service (AKS) usa un componente específico para la tunelización y la comunicación segura entre los nodos y el plano de control. El túnel consta de un servidor en el lado del plano de control y un cliente en el lado de los nodos del clúster. En este artículo se describe cómo solucionar y resolver problemas relacionados con la conectividad de túnel en AKS.
Nota:
Anteriormente, el componente de túnel de AKS era tunnel-front. Ahora se ha migrado al servicio Konnectivity, un componente ascendente de Kubernetes. Para obtener más información sobre esta migración, consulte las notas de la versión de AKS y el registro de cambios.
Requisitos previos
Síntomas
Recibirá un mensaje de error similar a los ejemplos siguientes sobre el puerto 10250:
Error del servidor: obtener "https:// aks-node-name>:10250/containerLogs/name>/<<pod-name/<container-name>>": dial tcp <aks-node-ip>:10250: tiempo de espera de E/S<
Error del servidor: error al marcar el back-end: marcar tcp <aks-node-ip>:10250: tiempo de espera de E/S
El servidor de API de Kubernetes usa el puerto 10250 para conectarse a kubelet de un nodo para recuperar los registros. Si el puerto 10250 está bloqueado, los registros de kubectl y otras características solo funcionarán para pods que se ejecutan en los nodos en los que está programado el componente de túnel. Para más información, consulte Puertos y protocolos de Kubernetes: Nodos de trabajo.
Dado que los componentes del túnel o la conectividad entre el servidor y el cliente no se pueden establecer, la funcionalidad como la siguiente no funcionará según lo previsto:
Webhooks del controlador de admisión
Capacidad de recuperación de registros (mediante el comando kubectl logs )
Ejecutar un comando en un contenedor o entrar en un contenedor (mediante el comando kubectl exec )
Reenvío de uno o varios puertos locales de un pod (mediante el comando kubectl port-forward )
Causa 1: un grupo de seguridad de red (NSG) está bloqueando el puerto 10250
Nota:
Esta causa es aplicable a cualquier componente de túnel que pueda tener en el clúster de AKS.
Puede usar un grupo de seguridad de red (NSG) de Azure para filtrar el tráfico de red hacia y desde recursos de Azure en una red virtual de Azure. Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan el tráfico de red entrante y saliente entre varios tipos de recursos de Azure. En todas las reglas, puede especificar un origen y destino, un puerto y un protocolo. Para más información, consulte Cómo filtran el tráfico de red los grupos de seguridad de red.
Si el grupo de seguridad de red bloquea el puerto 10250 en el nivel de red virtual, las funcionalidades de túnel (como registros y ejecución de código) funcionarán solo para los pods programados en los nodos donde se programan los pods de túnel. Los demás pods no funcionarán porque sus nodos no podrán acceder al túnel y el túnel está programado en otros nodos. Para comprobar este estado, puede probar la conectividad mediante los comandos netcat (nc) o telnet. Puede ejecutar el comando az vmss run-command invoke para realizar la prueba de conectividad y comprobar si se realiza correctamente, agota el tiempo de espera o provoca algún otro problema:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
--output tsv \
--query 'value[0].message'
Solución 1: Agregar una regla de NSG para permitir el acceso al puerto 10250
Si usa un grupo de seguridad de red y tiene restricciones específicas, asegúrese de agregar una regla de seguridad que permita el tráfico para el puerto 10250 en el nivel de red virtual. En la siguiente imagen de Azure Portal se muestra una regla de seguridad de ejemplo:
Si desea ser más restrictivo, puede permitir el acceso al puerto 10250 solo en el nivel de subred.
Nota:
El campo Prioridad debe ajustarse en consecuencia. Por ejemplo, si tiene una regla que deniega varios puertos (incluido el puerto 10250), la regla que se muestra en la imagen debe tener un número de prioridad menor (los números más bajos tienen mayor prioridad). Para obtener más información sobre prioridad, consulte Reglas de seguridad.
Si no ve ningún cambio de comportamiento después de aplicar esta solución, puede volver a crear los pods de componentes de túnel. La eliminación de estos pods hace que se vuelvan a crear.
Causa 2: La herramienta Firewall no replicado (UFW) está bloqueando el puerto 10250
Nota:
Esta causa se aplica a cualquier componente de túnel que tenga en el clúster de AKS.
Firewall sin comprimir (UFW) es un programa de línea de comandos para administrar un firewall de netfilter . Los nodos de AKS usan Ubuntu. Por lo tanto, UFW se instala en los nodos de AKS de forma predeterminada, pero UFW está deshabilitado.
De forma predeterminada, si UFW está habilitado, bloqueará el acceso a todos los puertos, incluido el puerto 10250. En este caso, es poco probable que pueda usar Secure Shell (SSH) para conectarse a los nodos del clúster de AKS para solucionar problemas. Esto se debe a que UFW también podría estar bloqueando el puerto 22. Para solucionar problemas, puede ejecutar el comando az vmss run-command invoke para invocar un comando ufw que compruebe si UFW está habilitado:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw status" \
--output tsv \
--query 'value[0].message'
¿Qué ocurre si los resultados indican que UFW está habilitado y no permite específicamente el puerto 10250? En este caso, las funcionalidades de túnel (como registros y ejecución de código) no funcionarán para los pods programados en los nodos que tienen UFW habilitado. Para corregir el problema, aplique una de las siguientes soluciones en UFW.
Importante
Antes de usar esta herramienta para realizar cambios, revise la directiva de soporte técnico de AKS (especialmente el mantenimiento y el acceso de nodos) para evitar que el clúster entre en un escenario no admitido.
Nota:
Si no ve ningún cambio de comportamiento después de aplicar una solución, puede volver a crear los pods de componentes de túnel. La eliminación de estos pods hará que se vuelvan a crear.
Solución 2a: Deshabilitar el firewall no replicado
Ejecute el siguiente az vmss run-command invoke comando para deshabilitar UFW:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw disable" \
--output tsv \
--query 'value[0].message'
Solución 2b: Configuración del firewall sin comprimir para permitir el acceso al puerto 10250
Para forzar a UFW a permitir el acceso al puerto 10250, ejecute el siguiente az vmss run-command invoke comando:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw allow 10250" \
--output tsv \
--query 'value[0].message'
Causa 3: la herramienta iptables está bloqueando el puerto 10250
Nota:
Esta causa se aplica a cualquier componente de túnel que tenga en el clúster de AKS.
La herramienta iptables permite a un administrador del sistema configurar las reglas de filtro de paquetes IP de un firewall de Linux. Puede configurar las reglas para bloquear la iptables comunicación en el puerto 10250.
Puede ver las reglas de los nodos para comprobar si el puerto 10250 está bloqueado o se quitan los paquetes asociados. Para ello, ejecute el siguiente iptables comando:
iptables --list --line-numbers
En la salida, los datos se agrupan en varias cadenas, incluida la INPUT cadena. Cada cadena contiene una tabla de reglas en los encabezados de columna siguientes:
num(número de regla)targetprot(protocolo)optsourcedestination
¿La INPUT cadena contiene una regla en la que el destino es DROP, el protocolo es tcpy el destino es tcp dpt:10250? Si es así, iptables está bloqueando el acceso al puerto de destino 10250.
Solución 3: Eliminar la regla de iptables que bloquea el acceso en el puerto 10250
Ejecute uno de los siguientes comandos para eliminar la iptables regla que impide el acceso al puerto 10250:
iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250
iptables --delete INPUT <input-rule-number>
Para abordar su escenario exacto o potencial, se recomienda comprobar el manual de iptables mediante la ejecución del iptables --help comando .
Importante
Antes de usar esta herramienta para realizar cambios, revise la directiva de soporte técnico de AKS (especialmente el mantenimiento y el acceso de nodos) para evitar que el clúster entre en un escenario no admitido.
Causa 4: No se abre el puerto de salida 1194 o 9000
Nota:
Esta causa solo se aplica a los tunnel-front pods y aks-link .
¿Hay alguna restricción de tráfico de salida, como desde un firewall de AKS? Si hay, se requiere el puerto 9000 para habilitar la funcionalidad correcta del tunnel-front pod. Del mismo modo, se requiere el puerto 1194 para el aks-link pod.
Konnectivity se basa en el puerto 443. De forma predeterminada, este puerto está abierto. Por lo tanto, no tiene que preocuparse por los problemas de conectividad en ese puerto.
Solución 4: Abrir el puerto 9000
Aunque tunnel-front se ha movido al servicio Konnectivity, algunos clústeres de AKS siguen usando tunnel-front, que se basa en el puerto 9000. Asegúrese de que la aplicación virtual o cualquier dispositivo de red o software permita el acceso al puerto 9000. Para más información sobre las reglas y dependencias necesarias, consulte Reglas de red necesarias para Azure Global.
Causa 5: Agotamiento de puertos de traducción de direcciones de red de origen (SNAT)
Nota:
Esta causa se aplica a cualquier componente de túnel que tenga en el clúster de AKS. Sin embargo, no se aplica a los clústeres de AKS privados. El agotamiento de puertos de traducción de direcciones de red de origen (SNAT) solo puede producirse para la comunicación pública. En el caso de los clústeres de AKS privados, el servidor de API está dentro de la red virtual o subred de AKS.
Si se produce un agotamiento de puertos SNAT (puertos SNAT con error), los nodos no se pueden conectar al servidor de API. El contenedor de túnel está en el lado del servidor de API. Por lo tanto, no se establecerá la conectividad de túnel.
Si se agotan los recursos de puerto SNAT, los flujos salientes producirán un error hasta que los flujos existentes liberen algunos puertos SNAT. Azure Load Balancer reclama los puertos SNAT cuando se cierra el flujo. Usa un tiempo de espera de inactividad de cuatro minutos para reclamar los puertos SNAT de los flujos inactivos.
Puede ver los puertos SNAT desde las métricas del equilibrador de carga de AKS o el diagnóstico del servicio, como se describe en las secciones siguientes. Para obtener más información sobre cómo ver los puertos SNAT, consulte Cómo comprobar las estadísticas de conexión salientes.
Métricas del equilibrador de carga de AKS
Para usar las métricas del equilibrador de carga de AKS para ver los puertos SNAT, siga estos pasos:
En Azure Portal, busque y seleccione Servicios de Kubernetes.
En la lista de servicios de Kubernetes, seleccione el nombre del clúster.
En el panel de menús del clúster, busque el encabezado Configuración y, a continuación, seleccione Propiedades.
Seleccione el nombre que aparece en Grupo de recursos de infraestructura.
Seleccione el equilibrador de carga de Kubernetes .
En el panel de menús del equilibrador de carga, busque el encabezado Supervisión y, a continuación, seleccione Métricas.
En el tipo de métrica, seleccione Recuento de conexiones SNAT.
Seleccione Aplicar división.
Establezca Dividir por en Estado de conexión.
Diagnósticos de servicio
Para usar diagnósticos de servicio para ver los puertos SNAT, siga estos pasos:
En Azure Portal, busque y seleccione Servicios de Kubernetes.
En la lista de servicios de Kubernetes, seleccione el nombre del clúster.
En el panel de menús del clúster, seleccione Diagnosticar y resolver problemas.
Seleccione Problemas de conectividad.
En Conexión SNAT y Asignación de puertos, seleccione Ver detalles.
Si es necesario, use el botón Intervalo de tiempo para personalizar el período de tiempo.
Solución 5a: Asegúrese de que la aplicación usa la agrupación de conexiones
Este comportamiento puede producirse porque una aplicación no reutiliza las conexiones existentes. Se recomienda no crear una conexión saliente por solicitud. Esta configuración puede provocar el agotamiento de la conexión. Compruebe si el código de la aplicación sigue los procedimientos recomendados y el uso de la agrupación de conexiones. La mayoría de las bibliotecas admiten la agrupación de conexiones. Por lo tanto, no debe tener que crear una nueva conexión saliente por solicitud.
Solución 5b: Ajuste de los puertos de salida asignados
Si todo está bien dentro de la aplicación, tendrá que ajustar los puertos de salida asignados. Para obtener más información sobre la asignación de puertos salientes, consulte Configuración de los puertos de salida asignados.
Solución 5c: Uso de una puerta de enlace de traducción de direcciones de red administrada (NAT) al crear un clúster
Puede configurar un nuevo clúster para usar una puerta de enlace de traducción de direcciones de red administrada (NAT) para las conexiones salientes. Para más información, consulte Creación de un clúster de AKS con una puerta de enlace NAT administrada.
Aviso de declinación de responsabilidades sobre la información de contacto de terceros
Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la precisión de esta información de contacto de terceros.
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.