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 historial de cambios.

Requisitos previos

• CLI de Azure

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 conectar con el backend: conectar tcp <aks-node-ip>:10250: tiempo de espera de entrada/salida.

Error del servidor: obtener "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": http: servidor dio respuesta HTTP al cliente HTTPS

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 de control 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 elemento de túnel que tenga en su 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, puedes 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 Sencillo (UFW) está bloqueando el puerto 10250

Nota:

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

Firewall Sin Complicaciones (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 Uncomplicated Firewall

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: Configurar el firewall sin complicaciones 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:

La causa se aplica a cualquier componente de túnel que tengas 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)
• 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 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 se aplica solo a los pods tunnel-front 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 todavía usan tunnel-front, que depende del 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 su clúster 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 fallidos), 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 del túnel.

Si se agotan los recursos de puerto SNAT, los flujos salientes fallarán hasta que los flujos existentes liberen algunos puertos SNAT. Azure Load Balancer reclama los puertos SNAT cuando se cierra el flujo. Utiliza un tiempo de espera 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 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:

1. En 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. En el tipo de métrica, seleccione Recuento de conexiones SNAT.

8. Seleccione Aplicar división.

9. 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:

1. En 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 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 debería tener que crear una nueva conexión saliente para cada 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.

Causa 6: Problemas de rendimiento de los agentes Konnectivity con el crecimiento del clúster

A medida que crece el clúster, el rendimiento de los agentes de Konnectivity puede degradarse debido a un aumento del tráfico de red, más solicitudes o restricciones de recursos.

Nota:

Esta causa solo se aplica a los Konnectivity-agent pods.

Solución 6: Autoscaler Proporcional de Clúster para el Agente Konnectivity

Para administrar los desafíos de escalabilidad en clústeres de gran tamaño, implementamos el Escalador Automático Proporcional del Clúster para nuestros agentes de Konnectivity. Este enfoque se alinea con los estándares del sector y los procedimientos recomendados. Garantiza un uso óptimo de los recursos y un rendimiento mejorado.

¿Por qué se realizó este cambio? Anteriormente, el agente Konnectivity tenía un recuento fijo de réplicas que podía crear un cuello de botella a medida que el clúster crecía. Al implementar el escalador automático proporcional del clúster, se permite que el recuento de réplicas se ajuste dinámicamente, en función de las reglas de escalado de nodos, para proporcionar un rendimiento óptimo y el uso de recursos.

Funcionamiento del escalador automático proporcional del clúster El escalador automático proporcional del clúster utiliza una configuración de escalera para determinar el número de réplicas del agente de Konnectivity en función del tamaño del clúster. La configuración de la escalera se define en el mapa de configuración konnectivity-agent-autoscaler en el espacio de nombres kube-system. Este es un ejemplo de la configuración de escalera:

nodesToReplicas": [
    [1, 2],
    [100, 3],
    [250, 4],
    [500, 5],
    [1000, 6],
    [5000, 10]
]

Esta configuración garantiza que el número de réplicas se escala adecuadamente con el número de nodos del clúster para proporcionar una asignación de recursos óptima y una confiabilidad de red mejorada.

¿Cómo usar el escalador proporcional automático del clúster? Puede invalidar los valores predeterminados modificando el configmap konnectivity-agent-autoscaler en el espacio de nombres kube-system. Este es un comando de ejemplo para actualizar configmap:

kubectl edit configmap <pod-name> -n kube-system

Este comando abre el configmap en un editor para permitirle realizar los cambios necesarios.

¿Qué debe comprobar?

Tiene que supervisar la eliminación de memoria insuficiente (OOM) en los nodos porque la configuración incorrecta del escalador automático proporcional del clúster puede provocar una asignación de memoria insuficiente para los agentes de Konnectivity. Esta configuración incorrecta se produce por los siguientes motivos clave:

Uso elevado de memoria: A medida que crece el clúster, el uso de memoria de los agentes konnectivity puede aumentar significativamente. Este aumento puede producirse especialmente durante las cargas máximas o al controlar un gran número de conexiones. Si la configuración del escalador automático proporcional del clúster no escala las réplicas correctamente, los agentes pueden quedarse sin memoria.

Límites fijos de recursos: Si las solicitudes de recursos y los límites de los agentes de Konnectivity se establecen demasiado bajos, es posible que no tengan suficiente memoria para controlar la carga de trabajo, lo que conduce a la eliminación de OOM. Las configuraciones incorrectas del escalador automático proporcional del clúster pueden empeorar este problema al no proporcionar suficientes réplicas para distribuir la carga.

Tamaño del clúster y variabilidad de la carga de trabajo: La CPU y la memoria que necesitan los agentes de Konnectivity pueden variar ampliamente según el tamaño del clúster y la carga de trabajo. Si la configuración del Cluster Proportional Autoscaler no tiene un tamaño adecuado y se ajusta de forma adaptativa para los patrones de uso del clúster, puede provocar una sobreasignación de memoria y errores OOM.

Para identificar y solucionar problemas de eliminaciones de OOM, siga estos pasos:

1. Buscar OOM Kills en nodos: use el siguiente comando para comprobar si OOM Kills está en los nodos:

kubectl get events --all-namespaces | grep -i 'oomkill'

2. Inspeccionar el uso de recursos del nodo: compruebe el uso de recursos en los nodos para asegurarse de que no se están quedando sin memoria:

kubectl top nodes

3. Revisar solicitudes y límites de recursos de pod: asegúrese de que los pods del agente konnectivity tengan las solicitudes y límites de recursos adecuados establecidos para evitar las eliminaciones de OOM:

kubectl get pod <pod-name> -n kube-system -o yaml | grep -A5 "resources:"

4. Ajustar las solicitudes y límites de recursos: si es necesario, ajustar las solicitudes y límites de los recursos de los pods del agente Konnectivity editando la implementación.

kubectl edit deployment konnectivity-agent -n kube-system

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 a la comunidad de comentarios sobre Azure.