Cree un entorno de red de ejemplo para la administración de redes superpuestas de Azure IoT (versión preliminar)
Importante
Operaciones de IoT de Azure, habilitado por Azure Arc, está actualmente en VERSIÓN PRELIMINAR. No se debería usar este software en versión preliminar en entornos de producción.
Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Para usar el servicio de administración de redes superpuestas de Azure IoT (versión preliminar), debe configurar un entorno de red aislado. Por ejemplo, la arquitectura ISA-95/ de Purdue Network. En esta página se proporcionan algunos ejemplos para configurar un entorno de prueba en función de cómo desea lograr el aislamiento.
- Segmentación física: las redes están separadas físicamente. En este caso, la administración de redes superpuestas debe implementarse en un host de NIC dual (tarjeta de interfaz de red) para conectarse a la red accesible desde Internet y a la red aislada.
- Segmentación lógica: la red se segmenta lógicamente con configuraciones como VLAN, subred o firewall. La administración de red superpuesta tiene un único punto de conexión y está configurado para que sea visible para su propia capa de red y la capa aislada.
Ambos enfoques requieren configurar un DNS personalizado en la capa de red aislada para dirigir el tráfico de red a la instancia de Administración de redes superpuestas.
Importante
Los entornos de red descritos en la documentación de administración de redes en capas son ejemplos para probar la administración de redes en capas. No es una recomendación de cómo se compila la topología de red y clúster para producción.
Configuración de una red aislada con segmentación física
La siguiente configuración de ejemplo es una red aislada sencilla con dispositivos físicos mínimos.
- El punto de acceso inalámbrico se usa para configurar una red local y no proporciona acceso a Internet.
- El clúster de nivel 4 es un clúster de nodo único hospedado en una máquina física de tarjeta de interfaz de red dual (NIC) que se conecta a Internet y a la red local.
- El clúster de nivel 3 es un clúster de nodo único hospedado en una máquina física. Este clúster de dispositivos solo se conecta a la red local.
La administración de red en capas se implementa en el clúster de NIC dual. El clúster de la red local se conecta a La administración de redes superpuestas como proxy para acceder a los servicios de Azure y Arc. Además, necesitaría un DNS personalizado en la red local para proporcionar resolución de nombres de dominio y apuntar el tráfico a la administración de redes superpuestas. Para obtener más información, consulte Configuración de DNS personalizado.
Configuración de una red aislada con segmentación lógica
El diagrama siguiente se ilustra un entorno de red aislado en el que cada nivel se segmenta lógicamente con subredes. En este entorno de prueba, hay varios clústeres uno en cada nivel. Los clústeres pueden ser AKS Edge Essentials o K3S. El clúster de Kubernetes de la red de nivel 4 tiene acceso directo a Internet. Los clústeres de Kubernetes de nivel 3 y inferiores no tienen acceso a Internet.
Los varios niveles de redes de esta configuración de prueba se realizan mediante subredes dentro de una red:
- Subred de nivel 4 (10.104.0.0/16): esta subred tiene acceso a Internet. Todas las solicitudes se envían a los destinos de Internet. Esta subred tiene una sola máquina Windows 11 con la dirección IP 10.104.0.10.
- Subred de nivel 3 (10.103.0.0/16): esta subred no tiene acceso a Internet y está configurada para que solo tenga acceso a la dirección IP 10.104.0.10 en el nivel 4. Esta subred contiene una máquina Windows 11 con la dirección IP 10.103.0.33 y una máquina Linux que hospeda un servidor DNS. El servidor DNS se configura siguiendo los pasos descritos en Configuración de DNS personalizado. Todos los dominios de la configuración DNS deben asignarse a la dirección 10.104.0.10.
- Subred de nivel 2 (10.102.0.0/16): al igual que el nivel 3, esta subred no tiene acceso a Internet. Está configurado para que solo tenga acceso a la dirección IP 10.103.0.33 en el nivel 3. Esta subred contiene una máquina Windows 11 con la dirección IP 10.102.0.28 y una máquina Linux que hospeda un servidor DNS. Hay una máquina Windows 11 (nodo) en esta red con la dirección IP 10.102.0.28. Todos los dominios de la configuración DNS deben asignarse a la dirección 10.103.0.33.
Consulte los ejemplos siguientes para configurar este tipo de entorno de red.
Ejemplo de segmentación lógica con hardware mínimo
En este ejemplo, ambas máquinas están conectadas a un punto de acceso (AP) que se conecta a Internet. La máquina host de nivel 4 puede acceder a Internet. El host de nivel 3 está bloqueado y no puede acceder a Internet con la configuración del AP. Por ejemplo, firewall o control de cliente. Dado que ambas máquinas están en la misma red, la instancia de administración de red superpuesta hospedada en el clúster de nivel 4 está visible de forma predeterminada para el clúster y la máquina de nivel 3. Es necesario configurar un DNS personalizado adicional en la red local para proporcionar resolución de nombres de dominio y apuntar el tráfico a la administración de red superpuesta. Para obtener más información, consulte Configuración de DNS personalizado.
Ejemplo de segmentación lógica en Azure
En este ejemplo, se crea un entorno de prueba con una red virtual y una máquina virtual Linux en Azure.
Importante
El entorno virtual es solo para exploración y evaluación. Para más información, consulte Entornos validados para la versión preliminar de Operaciones de IoT de Azure.
- Cree una red virtual en su suscripción de Azure. Cree subredes para al menos dos capas (nivel 4 y nivel 3).
- Es opcional crear una subred adicional para la jumpbox o la máquina del desarrollador para acceder de forma remota a la máquina o al clúster entre capas. Esta configuración es cómoda si planea crear más de dos capas de red. De lo contrario, puede conectar la máquina jumpbox a la red de nivel 4.
- Cree grupos de seguridad de red para cada nivel y adjúntelos a la subred en consecuencia.
- Puede usar el valor predeterminado para el grupo de seguridad de nivel 4.
- Debe configurar reglas de seguridad adicionales de entrada y salida para el grupo de seguridad de nivel 3 (y nivel inferior).
- Agregue reglas de seguridad de entrada y salida para denegar todo el tráfico de red.
- Con una prioridad más alta, agregue reglas de seguridad entrantes y salientes para permitir el tráfico de red hacia y desde el intervalo IP de la subred de nivel 4.
- [Opcional] Si crea una subred jumpbox, cree reglas de entrada y salida para permitir el tráfico hacia y desde esta subred.
- Cree máquinas virtuales Linux en el nivel 3 y nivel 4.
- Consulte entornos validados para conocer la especificación de la máquina virtual.
- Al crear la máquina virtual, conecte la máquina a la subred que se creó en los pasos anteriores.
- Omita la creación del grupo de seguridad para la máquina virtual.
Configuración de DNS personalizado
Se necesita un DNS personalizado para el nivel 3 y posterior. Garantiza que la resolución DNS para el tráfico de red que se origina en el clúster apunta a la instancia de administración de redes superpuestas de nivel primario. En un entorno de producción o existente, incorpore las siguientes resoluciones DNS al diseño de DNS. Si desea configurar un entorno de prueba para el servicio de administración de redes superpuestas y Operaciones de IoT de Azure, puede consultar uno de los ejemplos siguientes.
Configure CoreDNS
Aunque la configuración de DNS se puede lograr de muchas maneras diferentes, en este ejemplo se usa un mecanismo de extensión proporcionado por CoreDNS que es el servidor DNS predeterminado para clústeres K3S. Las direcciones URL de la lista de permitidos, que deben resolverse, se agregan a CoreDNS.
Importante
El enfoque CoreDNS solo se aplica al clúster K3S en el host de Ubuntu en el nivel 3.
Creación de un mapa de configuración a partir de la administración de redes superpuestas de nivel 4 (versión preliminar)
Después de que el clúster de nivel 4 y la administración de redes superpuestas estén listos, realice los pasos siguientes.
Confirme la dirección IP del servicio administración de redes superpuestas con el siguiente comando:
kubectl get services -n azure-iot-operationsLa salida debe tener un aspecto similar al siguiente. La dirección IP del servicio es
20.81.111.118.NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE lnm-level4 LoadBalancer 10.0.141.101 20.81.111.118 80:30960/TCP,443:31214/TCP 29sVea los mapas de configuración con el comando siguiente:
kubectl get cm -n azure-iot-operationsLa salida debería tener un aspecto similar al ejemplo siguiente:
NAME DATA AGE aio-lnm-level4-config 1 50s aio-lnm-level4-client-config 1 50sPersonalice el
aio-lnm-level4-client-config. Esta configuración es necesaria como parte de la configuración de nivel 3 para reenviar el tráfico desde el clúster de nivel 3 a la instancia de administración de redes superpuestas de nivel superior.# set the env var PARENT_IP_ADDR to the ip address of level 4 LNM instance. export PARENT_IP_ADDR="20.81.111.118" # run the script to generate a config map yaml kubectl get cm aio-lnm-level4-client-config -n azure-iot-operations -o yaml | yq eval '.metadata = {"name": "coredns-custom", "namespace": "kube-system"}' -| sed 's/PARENT_IP/'"$PARENT_IP_ADDR"'/' > configmap-custom-level4.yamlEste paso crea un archivo denominado
configmap-custom-level4.yaml
Configuración del nivel 3 CoreDNS de K3S
Después de configurar el clúster K3S y moverlo a la capa aislada de nivel 3, configure el CoreDNS de K3S de nivel 3 con la configuración de cliente personalizada que se generó anteriormente.
Copie en
configmap-custom-level4.yamlel host de nivel 3 o en el sistema donde acceda de forma remota al clúster.Ejecute los comandos siguientes:
# Create a config map called coredns-custom in the kube-system namespace kubectl apply -f configmap-custom-level4.yaml # Restart coredns kubectl rollout restart deployment/coredns -n kube-system # validate DNS resolution kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net # You should see the following output. kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net Server: 10.43.0.10 Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local Name: east.servicebus.windows.net Address 1: 20.81.111.118 pod "busybox" deleted # Note: confirm that the resolved ip addresss matches the ip address of the level 4 Layered Network Management instance.El paso anterior establece la configuración de DNS para resolver las direcciones URL permitidas dentro del clúster en el nivel 4. Para asegurarse de que el DNS fuera del clúster está haciendo lo mismo, debe configurar el sistema resuelto para reenviar el tráfico a CoreDNS dentro del clúster K3S. Ejecute los siguientes comandos en el host K3S: Cree el directorio siguiente:
sudo mkdir /etc/systemd/resolved.conf.dCree un nuevo archivo denominado
lnm.confcon el contenido siguiente. La dirección IP debe ser la dirección IP del clúster de nivel 3 del servicio kube-dns que se ejecuta en el espacio de nombres kube-system.[Resolve] DNS=<PUT KUBE-DNS SERVICE IP HERE> DNSStubListener=noReinicie la instancia de DNS Resolver:
sudo systemctl restart systemd-resolved
Contenido relacionado
¿Qué es la versión preliminar de Administración de redes superpuestas de Azure IoT?
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de