Partager via

Créer un exemple d’environnement réseau pour la gestion réseau en couches Azure IoT préversion

  • Article

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Lorsqu’une version en disponibilité générale sera publiée, vous devrez déployer une nouvelle installation d’Opérations Azure IoT. Vous ne pourrez pas mettre à niveau une installation en préversion.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Pour utiliser le service de gestion réseau en couches Azure IoT préversion, vous devez configurer un environnement réseau isolé. Par exemple, l’architecture réseau ISA-95/Purdue. Cette page fournit quelques exemples de mise en place d'un environnement de test, en fonction de la manière dont vous souhaitez réaliser l'isolation.

  • Segmentation physique : les réseaux sont physiquement séparés. Dans ce cas, la gestion en couches du réseau doit être déployée sur un hôte à double carte d'interface réseau (NIC) pour se connecter à la fois au réseau orienté vers l'internet et au réseau isolé.
  • Segmentation logique : le réseau est segmenté logiquement avec des configurations telles que VLAN, sous-réseau ou pare-feu. La gestion du réseau en couches a un seul point d'extrémité et est configurée pour être visible par sa propre couche de réseau et par la couche isolée.

Dans les deux cas, vous devez configurer un DNS personnalisé dans la couche réseau isolée afin de diriger le trafic réseau vers l'instance de gestion du réseau en couches de la couche supérieure.

Important

Les environnements réseau décrits dans la documentation de la gestion réseau en couches sont des exemples pour tester la gestion réseau en couches. Il ne s’agit pas d’une suggestion sur la façon de concevoir votre réseau et la topologie de votre cluster pour la production.

Configurer un réseau isolé avec une segmentation physique

L’exemple de configuration suivant est un réseau isolé simple avec des appareils physiques minimum.

Diagramme d’une configuration réseau isolée d’un appareil physique.

  • Le point d’accès sans fil est utilisé pour configurer un réseau local et ne fournit pas d’accès à Internet.
  • Le cluster de niveau 4 est un cluster à nœud unique hébergé sur une machine physique double carte d’interface réseau qui se connecte à Internet et au réseau local.
  • Le cluster de niveau 3 est un cluster à nœud unique hébergé sur une machine physique. Ce cluster d’appareils se connecte uniquement au réseau local.

La gestion du réseau en couches est déployée sur le cluster double carte d’interface réseau. Le cluster du réseau local se connecte à la gestion réseau en couches en tant que proxy pour accéder aux services Azure et Arc. En outre, il faudrait un DNS personnalisé dans le réseau local pour fournir la résolution de noms de domaine et pointer le trafic vers la gestion réseau en couches. Pour plus d’informations, consultez Configurer un système DNS personnalisé.

Configurer un réseau isolé avec une segmentation logique

Le diagramme suivant illustre un environnement réseau isolé où chaque niveau est segmenté logiquement avec des sous-réseaux. Dans cet environnement de test, il existe plusieurs clusters un à chaque niveau. Les clusters peuvent être AKS Edge Essentials ou K3S. Le cluster Kubernetes du réseau de niveau 4 dispose d’un accès Internet direct. Les clusters Kubernetes au niveau 3 et inférieur n’ont pas accès à Internet.

Diagramme d’un réseau isolé à segmentation logique.

Les différents niveaux de réseaux de cette configuration de test sont effectués à l’aide de sous-réseaux au sein d’un réseau :

  • Sous-réseau de niveau 4 (10.104.0.0/16) : ce sous-réseau a accès à Internet. Toutes les demandes sont envoyées aux destinations sur Internet. Ce sous-réseau a un seul ordinateur Windows 11 avec l’adresse IP 10.104.0.10.
  • Sous-réseau de niveau 3 (10.103.0.0/16) : ce sous-réseau n’a pas accès à Internet et est configuré pour avoir uniquement accès à l’adresse IP 10.104.0.10 dans le niveau 4. Ce sous-réseau contient un ordinateur Windows 11 avec l’adresse IP 10.103.0.33 et une machine Linux qui héberge un serveur DNS. Le serveur DNS est configuré à l’aide des étapes décrites dans Configurer un système DNS personnalisé. Tous les domaines de la configuration DNS doivent être mappés à l’adresse 10.104.0.10.
  • Sous-réseau de niveau 2 (10.102.0.0/16) : comme le niveau 3, ce sous-réseau n’a pas accès à Internet. Il est configuré pour avoir uniquement accès à l’adresse IP 10.103.0.33 dans le niveau 3. Ce sous-réseau contient un ordinateur Windows 11 avec l’adresse IP 10.102.0.28 et un ordinateur Linux qui héberge un serveur DNS. Il existe un ordinateur Windows 11 (nœud) dans ce réseau avec l’adresse IP 10.102.0.28. Tous les domaines de la configuration DNS doivent être mappés à l’adresse 10.103.0.33.

Les exemples suivants illustrent la mise en place de ce type d'environnement réseau.

Exemple de segmentation logique avec un matériel minimal

Dans cet exemple, les deux machines sont connectées à un point d'accès (PA) qui se connecte à l'internet. La machine hôte de niveau 4 peut accéder à l'internet. La configuration de l'AP empêche l'hôte de niveau 3 d'accéder à l'internet. Par exemple, le pare-feu ou le contrôle des clients. Comme les deux machines se trouvent sur le même réseau, l'instance de gestion du réseau en couches hébergée sur le cluster de niveau 4 est par défaut visible par la machine et le cluster de niveau 3. Un DNS personnalisé supplémentaire doit être configuré dans le réseau local pour fournir la résolution de noms de domaine et pointer le trafic vers la gestion réseau en couches. Pour plus d’informations, consultez Configurer un système DNS personnalisé.

Diagramme d’une configuration réseau isolée logique.

Exemple de segmentation logique dans Azure

Dans cet exemple, un environnement de test est créé avec un réseau virtuel et une machine virtuelle Linux dans Azure.

Important

L'environnement virtuel est uniquement destiné à l'exploration et à l'évaluation. Pour plus d’informations, consultez environnements validés pour Opérations Azure IoT (préversion).

  1. Créez un réseau virtuel dans votre abonnement Azure. Créez des sous-réseaux pour au moins deux couches (niveau 4 et niveau 3). Capture d’écran d’un réseau virtuel dans Azure.
  2. Il est facultatif de créer un sous-réseau supplémentaire pour la jumpbox ou l’ordinateur développeur afin d’accéder à distance à la machine ou au cluster sur plusieurs couches. Cette configuration est pratique si vous prévoyez de créer plus de deux couches de réseau. Sinon, vous pouvez connecter la machine jumpbox au réseau de niveau 4.
  3. Créez des groupes de sécurité réseau pour chaque niveau et attachez-les au sous-réseau en conséquence.
  4. Vous pouvez utiliser la valeur par défaut pour le groupe de sécurité de niveau 4.
  5. Vous devez configurer des règles de trafic entrant et sortant supplémentaires pour le groupe de sécurité de niveau 3 (et de niveau inférieur).
    • Ajoutez des règles de sécurité entrantes et sortantes pour refuser tout trafic réseau.
    • Avec une priorité plus élevée, ajoutez des règles de sécurité entrantes et sortantes pour autoriser le trafic réseau en provenance et à destination de la plage IP du sous-réseau de niveau 4.
    • [Facultatif] Si vous créez un sous-réseau de jumpbox, créez des règles de trafic entrant et sortant pour autoriser le trafic vers et depuis ce sous-réseau. Capture d’écran du groupe de sécurité de niveau 3.
  6. Créer des machines virtuelles Linux au niveau 3 et au niveau 4.
    • Reportez-vous aux environnements validés pour la spécification de la machine virtuelle.
    • Lors de la création de la machine virtuelle, connectez la machine au sous-réseau créé lors des étapes précédentes.
    • Ignorer la création d'un groupe de sécurité pour la machine virtuelle.

Configurer un système DNS personnalisé

Un DNS personnalisé est nécessaire pour le niveau 3 et inférieur. Il garantit que la résolution DNS pour le trafic réseau provenant du cluster est pointé vers l’instance de gestion réseau de niveau parent. Dans un environnement existant ou de production, incorporez les résolutions DNS suivantes dans votre conception DNS. Si vous souhaitez configurer un environnement de test pour le service de gestion réseau en couches et les Opérations Azure IoT, vous pouvez vous référer aux exemples suivants.

Configurer CoreDNS

Bien que la configuration du DNS puisse être réalisée de différentes manières, cet exemple utilise un mécanisme d'extension fourni par CoreDNS qui est le serveur DNS par défaut pour les clusters K3S. Les URL de la liste d'autorisation qui doivent être résolus sont ajoutés au CoreDNS.

Important

L'approche CoreDNS n'est applicable qu'au cluster K3S sur un hôte Ubuntu au niveau 3.

Créer un configmap à partir de la gestion réseau en couches de niveau 4 préversion

Une fois le cluster de niveau 4 et la gestion réseau en couches prêts, procédez comme suit.

  1. Confirmez l’adresse IP du service de gestion réseau en couches avec la commande suivante :

    kubectl get services -n azure-iot-operations

    La sortie doit se présenter comme suit. L’adresse IP du service est 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   29s

  2. Affichez les mappages de configuration avec la commande suivante :

    kubectl get cm -n azure-iot-operations

    La sortie doit ressembler à cet exemple :

    NAME                           DATA   AGE
aio-lnm-level4-config          1      50s
aio-lnm-level4-client-config   1      50s

  3. Personnalisez le aio-lnm-level4-client-config. Cette configuration est nécessaire dans le cadre de la configuration de niveau 3 pour transférer le trafic du cluster de niveau 3 à l’instance de gestion réseau en couches supérieure.

    # 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.yaml

    Cette étape crée un fichier nommé configmap-custom-level4.yaml

Configurer le niveau 3 CoreDNS de K3S

Après avoir configuré le cluster K3S et l'avoir déplacé vers la couche isolée de niveau 3, configurez le CoreDNS du K3S de niveau 3 avec la configuration client personnalisée qui a été générée précédemment.

  1. Copiez le configmap-custom-level4.yaml sur l'hôte de niveau 3 ou sur le système où vous accédez à distance au cluster.

  2. Exécutez les commandes suivantes :

    # 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.

  3. L’étape précédente définit la configuration DNS pour résoudre les URL autorisées à l’intérieur du cluster au niveau 4. Pour s'assurer que le DNS à l'extérieur du cluster fait de même, vous devez configurer systemd-resolved pour qu'il transmette le trafic à CoreDNS à l'intérieur du cluster K3S. Exécutez les commandes suivantes sur l’hôte K3S : créez le répertoire suivant :

        sudo mkdir /etc/systemd/resolved.conf.d

    Créez un fichier nommé lnm.conf avec le contenu suivant. L’adresse IP doit être l’adresse IP de cluster de niveau 3 du service kube-dns qui s’exécute dans l’espace de noms kube-system.

    [Resolve]
DNS=<PUT KUBE-DNS SERVICE IP HERE> 
DNSStubListener=no

    Redémarrez le programme de résolution DNS :

    sudo systemctl restart systemd-resolved

Contenu connexe

Qu’est-ce que la gestion du réseau en couches Azure IoT (préversion) ?