Problemas de conectividad de túnel

Microsoft Azure Kubernetes Service (AKS) usa un componente específico para la comunicación tunelada y 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.

Diagrama del subyacente de AKS administrado por Azure, la red virtual de Azure administrada por el cliente y la subred, y el túnel desde la API hasta el pod de túnel.

Nota:

De forma predeterminada, y en función de la región, el componente de túnel era tunnel-front. Al actualizar a la característica de contrato de nivel de servicio (SLA) de tiempo de actividad, tunnel-front se reemplazó por el componente de aks-link túnel que usó OpenVPN. AKS está migrando a Konnectivity. Se trata de un componente ascendente de Kubernetes que reemplaza a tunnel-front y aks-link. Para obtener más información sobre la migración a Konnectivity como componente de túnel, 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/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: tiempo de espera de e/S

Error del servidor: error al marcar back-end: dial tcp <aks-node-ip>:10250: tiempo de espera de e/S

El servidor de API de Kubernetes usa el puerto 10250 para conectarse al 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 los pods que se ejecutan en los nodos en los que está programado el componente de túnel. Para obtener más información, consulte Puertos y protocolos de Kubernetes: nodos de trabajo.

Dado que no se pueden establecer los componentes del túnel o la conectividad entre el servidor y el cliente, la funcionalidad como la siguiente no funcionará según lo esperado:

  • 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) bloquea 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 los 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. Para cada regla, puede especificar el origen y el destino, el puerto y el protocolo. Para obtener más información, consulte Cómo los grupos de seguridad de red filtran el tráfico 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 los registros y la ejecución de código) funcionarán solo para los pods programados en los nodos donde están programados los pods de túnel. Los demás pods no funcionarán porque sus nodos no podrán llegar al túnel y el túnel está programado en otros nodos. Para comprobar este estado, puede probar la conectividad mediante comandos netcat (nc) o telnet. Puede ejecutar el comando az vmss run-command invoke para realizar la prueba de conectividad y comprobar si se ejecuta 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 grupo de seguridad de red 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. La siguiente imagen Azure Portal muestra una regla de seguridad de ejemplo:

Captura de pantalla del panel Agregar regla de seguridad de entrada en el Azure Portal. El cuadro Intervalos de puertos de destino se establece en 10250 para la nueva regla de seguridad.

Si quiere ser más restrictivo, solo puede permitir el acceso al puerto 10250 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 inferior (los números más bajos tienen mayor prioridad). Para obtener más información sobre la prioridad, vea 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 sin complicaciones (UFW) bloquea el puerto 10250

Nota:

Esta causa se aplica a cualquier componente de túnel que tenga en el clúster de AKS.

El firewall sin complicaciones (UFW) es un programa de línea de comandos para administrar un firewall netfilter . Los nodos de AKS usan Ubuntu. Por lo tanto, UFW está instalado 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 de 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 los registros y la ejecución de código) no funcionarán para los pods programados en los nodos que tienen habilitado UFW. Para solucionar 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 a 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 firewall sin complicaciones

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 complicaciones para permitir el acceso al puerto 10250

Para forzar que UFW permita 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 bloquea 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 si 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 bajo los encabezados de columna siguientes:

  • num (número de regla)
  • target
  • prot (protocolo)
  • opt
  • source
  • destination

¿La INPUT cadena contiene una regla en la que el destino es DROP, el protocolo es tcpy el destino es tcp dpt:10250? Si lo hace, iptables está bloqueando el acceso al puerto de destino 10250.

Solución 3: elimina la regla 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 solucionar el 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 a nodos) para evitar que el clúster entre en un escenario no admitido.

Causa 4: El puerto de salida 1194 o 9000 no está abierto

Nota:

Esta causa solo se aplica a los tunnel-front pods y aks-link .

¿Hay restricciones 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: Puerto abierto 1194 o 9000

Asegúrese de que la aplicación virtual permite el acceso al puerto 1194 o al puerto 9000. Para obtener más información sobre las reglas y dependencias necesarias, consulte Reglas de red necesarias globales de Azure.

Causa 5: Agotamiento del puerto 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 privados de AKS. El agotamiento del puerto de traducción de direcciones de red de origen (SNAT) solo se puede producir para la comunicación pública. En el caso de los clústeres de AKS privados, el servidor de API se encuentra dentro de la red virtual o subred de AKS.

Si se produce un agotamiento del puerto SNAT ( puertos SNAT con errores), 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 de salida 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 inactividad de cuatro minutos para recuperar los puertos SNAT de los flujos inactivos.

Puede ver los puertos SNAT desde las métricas del equilibrador de carga de AKS o los diagnósticos 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 de salida.

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:

  1. En el Azure Portal, busque y seleccione Servicios de Kubernetes.

  2. En la lista de servicios de Kubernetes, seleccione el nombre del clúster.

  3. En el panel de menús del clúster, busque el encabezado Configuración y, a continuación, seleccione Propiedades.

  4. Seleccione el nombre que aparece en Grupo de recursos de infraestructura.

  5. Seleccione el equilibrador de carga de kubernetes .

  6. En el panel de menús del equilibrador de carga, busque el encabezado Supervisión y, a continuación, seleccione Métricas.

  7. Para el tipo de métrica, seleccione Recuento de conexiones SNAT.

  8. Seleccione Aplicar división.

  9. Establezca Dividir poren Estado de conexión.

Diagnósticos del servicio

Para usar diagnósticos de servicio para ver los puertos SNAT, siga estos pasos:

  1. En el Azure Portal, busque y seleccione Servicios de Kubernetes.

  2. En la lista de servicios de Kubernetes, seleccione el nombre del clúster.

  3. En el panel de menús del clúster, seleccione Diagnosticar y resolver problemas.

  4. Seleccione Problemas de conectividad.

  5. En Conexión sNAT y asignación de puertos, seleccione Ver detalles.

  6. 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 está reutilizando las conexiones existentes. Se recomienda no crear una conexión saliente por solicitud. Esta configuración puede provocar agotamiento de la conexión. Compruebe si el código de la aplicación sigue los procedimientos recomendados y usa 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 de salida, 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 obtener 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. Dicha información de contacto puede cambiar sin notificación previa. 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.