Control del tráfico de red desde HDInsight en grupos de nodos y clústeres de AKS
Importante
Azure HDInsight en AKS se retiró el 31 de enero de 2025. Descubra más con este anuncio.
Debe migrar las cargas de trabajo a microsoft Fabric o un producto equivalente de Azure para evitar la terminación repentina de las cargas de trabajo.
Importante
Esta característica está actualmente en versión preliminar. Los Términos de uso complementarios para las versiones preliminares de Microsoft Azure incluyen más términos legales que se aplican a las características de Azure que se encuentran en versión beta, en versión preliminar o, de lo contrario, aún no se han publicado en disponibilidad general. Para obtener información sobre esta versión preliminar específica, consulte la información de Azure HDInsight en AKS de la versión preliminar . Para preguntas o sugerencias de funcionalidades, envíe una solicitud en AskHDInsight con los detalles y síganos para obtener más actualizaciones sobre Comunidad de Azure HDInsight.
HDInsight en AKS es una plataforma como servicio administrada (PaaS) que se ejecuta en Azure Kubernetes Service (AKS). HDInsight en AKS permite implementar cargas de trabajo populares de Open-Source Analytics como Apache Spark™, Apache Flink®️ y Trino sin la sobrecarga de administrar y supervisar contenedores.
De forma predeterminada, HDInsight en clústeres de AKS permite conexiones de red salientes de clústeres a cualquier destino, si el destino es accesible desde la interfaz de red del nodo. Esto significa que los recursos del clúster pueden acceder a cualquier dirección IP pública o privada, nombre de dominio o dirección URL en Internet o en la red virtual.
Sin embargo, en algunos escenarios, es posible que quiera controlar o restringir el tráfico de salida del clúster por motivos de seguridad y cumplimiento.
Por ejemplo, puede que desee:
Impedir que los clústeres accedan a servicios malintencionados o no deseados.
Aplicar directivas de red o reglas de firewall en el tráfico saliente.
Supervise o audite el tráfico de salida del clúster con fines de solución de problemas o cumplimiento.
Métodos y herramientas para controlar el tráfico de salida
Tiene diferentes opciones y herramientas para administrar cómo fluye el tráfico de salida desde HDInsight en clústeres de AKS. Puede configurar algunos de ellos en el nivel de grupo de clústeres y otros en el nivel de clúster.
Salida con equilibrador de carga. Al implementar un grupo de clústeres con esta ruta de acceso de salida, se aprovisiona y se asigna una dirección IP pública al recurso del equilibrador de carga. No se requiere una red virtual personalizada (VNET); sin embargo, se recomienda encarecidamente. Puede usar Azure Firewall o grupos de seguridad de red (NSG) en la red virtual personalizada para administrar el tráfico que sale de la red.
Tráfico saliente con enrutamiento definido por el usuario. Al implementar un grupo de clústeres con esta ruta de acceso de salida, el usuario puede administrar el tráfico de salida en el nivel de subred mediante Azure Firewall o NAT Gateway y tablas de rutas personalizadas. Esta opción solo está disponible cuando se usa una red virtual personalizada.
Habilite AKS privado. Al habilitar AKS privado en el grupo de clústeres, el servidor de API de AKS se asignará a una dirección IP interna y no será accesible públicamente. El tráfico de red entre el servidor de API de AKS y HDInsight en grupos de nodos de AKS (clústeres) permanecerá en la red privada.
Clúster de entrada privado. Al implementar un clúster con la opción de entrada privada habilitada, no se creará ninguna dirección IP pública y solo se podrá acceder al clúster desde clientes dentro de la misma red virtual. Debe proporcionar su propia solución NAT, como una puerta de enlace NAT o una NAT proporcionada por su firewall, para conectar con HDInsight público y saliente en las dependencias de AKS.
En las secciones siguientes, se describe cada método en detalle.
Salida con equilibrador de carga
El equilibrador de carga se usa para la salida a través de una dirección IP pública asignada por HDInsight en AKS. Al configurar el tipo de salida de equilibrador de carga en el grupo de clústeres, puede esperar la salida del equilibrador de carga creado por HDInsight en AKS.
Puede configurar la configuración de tráfico saliente con el equilibrador de carga mediante el portal de Azure.
Una vez que opte por esta configuración, HDInsight en AKS completa automáticamente la creación de una dirección IP pública aprovisionada para la salida del clúster & asigna al recurso del equilibrador de carga.
Una dirección IP pública creada por HDInsight en AKS y es un recurso administrado por AKS, lo que significa que AKS administra el ciclo de vida de esa dirección IP pública y no requiere la acción del usuario directamente en el recurso de dirección IP pública.
Cuando se crean clústeres, también se crean determinadas direcciones IP públicas de entrada.
Para permitir que las solicitudes se envíen al clúster, debe lista de permitidos del tráfico. También puede configurar ciertas reglas en el NSG para realizar un control de grano grueso.
Salida con enrutamiento definido por el usuario
Nota
El tipo de salida userDefinedRouting es un escenario de red avanzado y requiere una configuración de red adecuada antes de comenzar.
No se admite el cambio del tipo de salida después de la creación del grupo de clústeres.
Si se establece userDefinedRouting, HDInsight en AKS no configurará automáticamente las rutas de salida. El usuario debe realizar la configuración de salida.
Debe implementar HDInsight en el clúster de AKS en una red virtual existente con una subred configurada previamente y debe establecer una salida explícita.
Esta arquitectura requiere el envío explícito del tráfico de salida a un dispositivo como un firewall, una puerta de enlace o un proxy, por lo que una dirección IP pública asignada al equilibrador de carga estándar o al dispositivo puede controlar la traducción de direcciones de red (NAT).
HDInsight en AKS no configura la dirección IP pública de salida ni las reglas de salida, a diferencia de los clústeres del tipo con equilibrador de carga, como se describe en la sección anterior. La UDR es la única fuente para el tráfico de salida.
Para el tráfico entrante, debe elegir en función de los requisitos para elegir un clúster privado (para proteger el tráfico en el plano de control o servidor de API de AKS) y seleccionar la opción de entrada privada disponible en cada una de las formas del clúster para usar el tráfico basado en el equilibrador de carga público o interno.
Creación de grupos de clústeres para salida con userDefinedRouting
Al utilizar HDInsight en grupos de clústeres de AKS y elegir userDefinedRouting (UDR) como ruta de salida, no se aprovisiona un balanceador de carga estándar. Debe configurar las reglas de firewall para los recursos salientes antes de que userDefinedRouting pueda funcionar.
Importante
La ruta de acceso de salida UDR necesita una ruta para 0.0.0.0/0 y un destino de próximo salto de tu firewall o NVA en la tabla de rutas. La tabla de rutas ya tiene una ruta predeterminada 0.0.0.0/0 hacia Internet. No puede obtener conectividad saliente a Internet agregando esta ruta, ya que Azure necesita una dirección IP pública para SNAT. AKS comprueba que no cree una ruta 0.0.0.0/0 que apunte a Internet, sino a una puerta de enlace, una NVA, etc. Cuando se usa UDR, solo se crea una dirección IP pública del balanceador de carga para las solicitudes entrantes si configura un servicio de tipo loadbalancer. HDInsight en AKS nunca crea una dirección IP pública para las solicitudes salientes cuando se usa una ruta de egreso UDR.
Con los pasos siguientes, comprenderá cómo bloquear el tráfico saliente del servicio HDInsight en AKS a recursos de Azure back-end u otros recursos de red con Azure Firewall. Esta configuración ayuda a evitar la filtración de datos o el riesgo de implantación de programas malintencionados.
Azure Firewall le permite controlar el tráfico saliente en un nivel mucho más granular y filtrar el tráfico en función de la inteligencia sobre amenazas en tiempo real de Microsoft Cyber Security. Puede crear, aplicar y registrar directivas de conectividad de red y aplicaciones de forma centralizada en suscripciones y redes virtuales.
A continuación se muestra un ejemplo de configuración de reglas de firewall y pruebas de las conexiones salientes.
Este es un ejemplo de cómo configurar reglas de firewall y comprobar las conexiones salientes.
Creación de la subred de firewall necesaria
Para implementar un firewall en la red virtual integrada, necesita una subred denominada AzureFirewallSubnet o Nombre de su elección.
En Azure Portal, vaya a la red virtual integrada con la aplicación.
En el panel de navegación izquierdo, seleccione + > Subredes.
En Nombre, escriba AzureFirewallSubnet.
intervalo de direcciones de subred, acepte el valor predeterminado o especifique un intervalo al menos /26 de tamaño.
Seleccionar Guardar.
Implementación del firewall y obtención de su dirección IP
En el menú del Portal de Azure o en la página de inicio de, seleccione Crear un recurso.
Escriba firewall en el cuadro de búsqueda y presione Intro.
Seleccione firewall y, a continuación, seleccione Crear.
En la página Crear un firewall, configure el firewall como se muestra en la tabla siguiente:
Ajuste Valor Grupo de recursos Mismo grupo de recursos que la red virtual integrada. Nombre Nombre de su elección Región La misma región que la red virtual integrada. Directiva de firewall Para crear uno, seleccione Agregar nuevo. Red virtual Seleccione la red virtual integrada. Dirección IP pública Seleccione una dirección existente o cree una seleccionando Agregar nueva. 
Haga clic en Revisar y crear.
Seleccione Crear de nuevo. Este proceso tarda unos minutos en implementarse.
Una vez completada la implementación, vaya al grupo de recursos y seleccione el firewall.
En la página Resumen del firewall, copie la dirección IP privada. La dirección IP privada se usará como dirección del próximo salto en la regla de enrutamiento de la red virtual.
Enrutar todo el tráfico al firewall
Al crear una red virtual, Azure crea automáticamente una tabla de rutas predeterminada para cada una de sus subredes y agrega rutas predeterminadas del sistema a la tabla. En este paso, creará una tabla de rutas definida por el usuario que enruta todo el tráfico al firewall y, a continuación, la asociará a la subred de App Service en la red virtual integrada.
En el menú Azure Portal, seleccione Todos los servicios o busque y seleccione Todos los servicios en cualquier página.
En Networking, seleccione Tablas de rutas.
Seleccione Agregar.
Configure la tabla de rutas como en el ejemplo siguiente:
Asegúrese de seleccionar la misma región que el firewall que creó.
Seleccione Revisar y crear.
Seleccione Crear.
Una vez completada la implementación, seleccione Ir al recurso.
En el panel de navegación izquierdo, seleccione Rutas > Agregar.
Configure la nueva ruta como se muestra en la tabla siguiente:
Ajuste Valor Tipo de destino Direcciones IP Direcciones IP de destino/intervalos CIDR 0.0.0.0/0 Tipo de próximo salto Aplicación virtual Dirección del próximo salto Dirección IP privada del firewall que copió En el panel de navegación izquierdo, seleccione Subredes > Asociar.
En red virtual, seleccione la red virtual integrada.
En subred, seleccione la subred de HDInsight en AKS que desea usar.
Seleccione Aceptar.
Configuración de directivas de firewall
El tráfico saliente de la subred de HDInsight en AKS ahora se enruta a través de la red virtual integrada al firewall. Para controlar el tráfico saliente, agregue una regla de aplicación a la directiva de firewall.
Vaya a la página de información general del firewall y seleccione su directiva de firewall.
En la página directiva de firewall, en el panel de navegación izquierdo, agregue reglas de red y aplicación. Por ejemplo, seleccione Reglas de red > Agregar una colección de reglas.
En Reglas, agregue una regla de red con la subred como dirección de origen y especifique un destino FQDN. Del mismo modo, agregue las reglas de aplicación.
- Debe agregar las reglas de tráfico de salida de dadas aquí. Consulte este documento para agregar reglas de aplicación y de red que permitan el tráfico necesario para el funcionamiento del clúster. (Es necesario agregar AKS ApiServer después de crear el clusterPool porque solo se puede obtener AKS ApiServer tras la creación del clusterPool).
- También puede agregar los puntos de conexión privados para los recursos dependientes de la misma subred para que el clúster pueda acceder a ellos (por ejemplo, almacenamiento).
Seleccione Agregar.
Comprobación de si se ha creado la dirección IP pública
Con las reglas del firewall establecidas, puede seleccionar la subred durante la creación del clúster.
Una vez creado el grupo de clústeres, puede observar en el grupo MC que no se ha creado ninguna dirección IP pública.
Importante
Antes de crear el clúster en la configuración del grupo de clúster con la ruta de egreso Outbound with userDefinedRouting, debe asignar al clúster de AKS, que coincida con el grupo de clúster, el rol Network Contributor en los recursos de red que se usan para definir el enrutamiento, como la Red Virtual, la tabla de enrutamiento y el NSG (si se usa). Obtenga más información sobre cómo asignar el rol aquí
Nota
Al implementar un conjunto de clústeres con la ruta de acceso de salida UDR y un clúster de entrada privado, HDInsight en AKS creará automáticamente una zona DNS privada y asignará las entradas para resolver el FQDN para acceder al clúster.
Creación de grupos de clústeres con AKS privado
En un AKS privado, el plano de control o servidor de API tiene direcciones IP internas definidas en el documento RFC1918 - Asignación de Direcciones para Internet Privado. Con esta opción de AKS privada, puede asegurarse de que el tráfico de red entre el servidor de API y hdInsight en clústeres de cargas de trabajo de AKS permanece solo en la red privada.
Al aprovisionar un clúster de AKS privado, AKS crea de forma predeterminada un FQDN privado con una zona DNS privada y un FQDN público adicional con un registro A correspondiente en dns público de Azure. Los nodos del agente siguen usando el registro en la zona DNS privada para resolver la dirección IP privada del punto de conexión privado para la comunicación con el servidor de API.
Como HDInsight en AKS insertará automáticamente el registro en la zona DNS privada dentro del grupo administrado de HDInsight creado en AKS para el acceso privado.
Clústeres con entrada privada
Al crear un clúster con HDInsight en AKS, tiene un FQDN público y una dirección IP a la que cualquier usuario puede acceder. Con la característica de entrada privada, puede asegurarse de que solo la red privada puede enviar y recibir datos entre el cliente y HDInsight en el clúster de AKS.
Nota
Con esta característica, HDInsight en AKS creará automáticamente registros A en la zona DNS privada para el ingreso.
Esta característica impide el acceso público a Internet al clúster. El clúster obtiene un equilibrador de carga interno y una dirección IP privada. HDInsight en AKS usa la zona DNS privada que creó el grupo de clústeres para conectar la red virtual del clúster y realizar la resolución de nombres.
Cada clúster privado contiene dos FQDN: FQDN público y FQDN privado.
FQDN público: {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
El FQDN público solo se puede resolver en un CNAME con subdominio, por lo que debe usarse con el Private DNS zone setting correcto para asegurarse de que el FQDN se pueda resolver finalmente para corregir la dirección IP privada.
La zona DNS privada debe poder resolver el FQDN privado en una dirección IP (privatelink.{clusterPoolName}.{subscriptionId}).
Nota
HDInsight en AKS crea una zona DNS privada en el grupo de clústeres, la red virtual. Si las aplicaciones cliente están en la misma red virtual, no debe volver a configurar la zona DNS privada. En caso de que use una aplicación cliente en una red virtual diferente, debe usar el emparejamiento de red virtual y enlazar a la zona dns privada en la red virtual del grupo de clústeres o usar puntos de conexión privados en la red virtual y zonas dns privadas, para agregar el registro A a la dirección IP privada del punto de conexión privado.
FQDN privado: {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
El FQDN privado se asignará solo a clústeres con la entrada privada habilitada. Es un registro A en la zona DNS privada que se resuelve en la dirección IP privada del clúster.