Erstellen einer Beispielnetzwerkumgebung für Azure IoT Layered Network Management Preview
Wichtig
Die von Azure Arc unterstützte Vorschauversion von „Azure IoT Einsatz“ befindet sich derzeit in der Vorschauphase. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.
Sie müssen eine neue Installation von Azure IoT Einsatz bereitstellen, wenn ein allgemein verfügbares Release verfügbar wird. Sie werden kein Upgrade für eine Preview-Installation durchführen können.
Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Um den Azure IoT Layered Network Management Preview-Dienst zu verwenden, müssen Sie eine isolierte Netzwerkumgebung konfigurieren. Beispielsweise die ISA-95/Purdue Network-Architektur. Diese Seite enthält einige Beispiele für das Einrichten einer Testumgebung, die davon abhängt, wie Sie die Isolation erreichen möchten.
- Physische Segmentierung – Die Netzwerke werden physisch getrennt. In diesem Fall muss das Layered Network Management auf einem dualen NIC-Host (Netzwerkschnittstellenkarte) bereitgestellt werden, um eine Verbindung mit dem internetorientierten Netzwerk und dem isolierten Netzwerk herzustellen.
- Logische Segmentierung – Das Netzwerk wird logisch mit Konfigurationen wie VLAN, Subnetz oder Firewall segmentiert. Das Layered Network Management verfügt über einen einzelnen Endpunkt und ist so konfiguriert, dass er für seine eigene Netzwerkebene und die isolierte Ebene sichtbar ist.
Beide Ansätze erfordern, dass Sie ein benutzerdefiniertes DNS auf der isolierten Netzwerkebene konfigurieren, um den Netzwerkdatenverkehr in die Instanz der Layered Network Management in der oberen Ebene zu leiten.
Wichtig
Die in der Layered Network Management-Dokumentation beschriebenen Netzwerkumgebungen sind Beispiele zum Testen des Layered Network Management. Sie stellen keine Empfehlungen für den Aufbau Ihrer Netzwerk- und Clustertopologie für die Produktion dar.
Konfigurieren Sie ein isoliertes Netzwerk mit physischer Segmentierung
Die folgende Beispielkonfiguration ist ein einfaches isoliertes Netzwerk mit minimalen physischen Geräten.
- Der drahtlose Zugriffspunkt wird zum Einrichten eines lokalen Netzwerks verwendet und bietet keinen Internetzugang.
- Der Cluster der Ebene 4 ist ein einzelner Knotencluster, der auf einem physischen Computer (Dual Network Interface Card, NIC) gehostet wird, der eine Verbindung mit dem Internet und dem lokalen Netzwerk herstellt.
- Der Cluster der Ebene 3 ist ein einzelner Knotencluster, der auf einem physischen Computer gehostet wird. Dieser Gerätecluster verbindet sich nur mit dem lokalen Netzwerk.
Layered Network Management wird im dualen NIC-Cluster bereitgestellt. Der Cluster im lokalen Netzwerk verbindet sich mit Layered Network Management als Proxy, um auf Azure und Arc-Dienste zuzugreifen. Darüber hinaus wäre ein benutzerdefiniertes DNS im lokalen Netzwerk erforderlich, um die Auflösung von Domänennamen bereitzustellen und den Datenverkehr an Layered Network Management weiterzuleiten. Weitere Informationen finden Sie unter Konfigurieren von benutzerdefiniertem DNS.
Konfigurieren von isolierten Netzwerken mit logischer Segmentierung
Das folgende Diagramm zeigt eine isolierte Netzwerkumgebung, in der jede Ebene logisch mit Subnetzen segmentiert wird. In dieser Testumgebung gibt es mehrere Cluster auf jeder Ebene. Die Cluster können AKS Edge Essentials oder K3S sein. Der Kubernetes-Cluster im Netzwerk der Ebene 4 verfügt über direkten Internetzugang. Die Kubernetes-Cluster der Ebene 3 und darunter haben keinen Internetzugang.
Die verschiedenen Ebenen von Netzwerken in dieser Testeinrichtung werden mithilfe von Subnetzen in einem Netzwerk durchgeführt:
- Subnetz der Ebene 4 (10.104.0.0/16) – Dieses Subnetz hat Zugriff auf das Internet. Alle Anforderungen werden an die Ziele im Internet gesendet. Dieses Subnetz verfügt über einen einzelnen Windows 11-Computer mit der IP-Adresse 10.104.0.10.
- Subnetz der Ebene 3 (10.103.0.0/16) – Dieses Subnetz hat keinen Zugriff auf das Internet und ist so konfiguriert, dass nur Zugriff auf die IP-Adresse 10.104.0.10 in Ebene 4 besteht. Dieses Subnetz enthält einen Windows 11-Computer mit der IP-Adresse 10.103.0.33 und einem Linux-Computer, auf dem ein DNS-Server gehostet wird. Der DNS-Server wird mithilfe der Schritte unter Konfigurieren von benutzerdefiniertem DNS konfiguriert. Alle Domänen in der DNS-Konfiguration müssen der Adresse 10.104.0.10 zugeordnet werden.
- Subnetz der Ebene 2 (10.102.0.0/16) – Wie Ebene 3 hat dieses Subnetz keinen Zugriff auf das Internet. Es ist so konfiguriert, dass es nur Zugriff auf die IP-Adresse 10.103.0.33 in Ebene 3 hat. Dieses Subnetz enthält einen Windows 11-Computer mit der IP-Adresse 10.102.0.28 und einem Linux-Computer, auf dem ein DNS-Server gehostet wird. In diesem Netzwerk gibt es einen Windows 11-Computer (Knoten) mit IP-Adresse 10.102.0.28. Alle Domänen in der DNS-Konfiguration müssen der Adresse 10.103.0.33 zugeordnet werden.
Weitere Informationen zum Einrichten dieser Netzwerkumgebung finden Sie in den folgenden Beispielen.
Beispiel für eine logische Segmentierung mit minimaler Hardware
In diesem Beispiel sind beide Computer mit einem Zugriffspunkt (AP) verbunden, der eine Verbindung mit dem Internet herstellt. Der Hostcomputer der Ebene 4 kann auf das Internet zugreifen. Der Host der Ebene 3 wird für den Zugriff auf das Internet mit der Konfiguration der AP blockiert. Beispiel: Firewall- oder Clientsteuerung. Da sich beide Computer im selben Netzwerk befinden, ist die auf Ebene 4 gehostete Layered Network Management-Instanz standardmäßig für den Computer und das Cluster der Ebene 3 sichtbar. Ein zusätzliches benutzerdefiniertes DNS muss im lokalen Netzwerk eingerichtet werden, um die Auflösung von Domänennamen bereitzustellen und den Datenverkehr auf die Layered Network Management zu verweisen. Weitere Informationen finden Sie unter Konfigurieren von benutzerdefiniertem DNS.
Beispiel für die logische Segmentierung in Azure
In diesem Beispiel wird eine Testumgebung mit einem virtuellen Netzwerk und einem virtuellen Linux-Computer in Azure erstellt.
Wichtig
Die virtuelle Umgebung dient nur zur Erkundung und Auswertung. Weitere Informationen finden Sie unter überprüfte Umgebungen für Azure IoT Operations Preview.
- Erstellen Sie ein virtuelles Netzwerk in Ihrem Azure-Abonnement. Erstellen Sie Subnetze für mindestens zwei Ebenen (Ebene 4 und Ebene 3).
- Es ist optional, ein zusätzliches Subnetz für den Jumpbox- oder Entwickler-Computer zu erstellen, um remote auf den Computer oder das Cluster über Ebenen zuzugreifen. Diese Einrichtung ist praktisch, wenn Sie mehr als zwei Netzwerkebenen erstellen möchten. Andernfalls können Sie den Jumpbox-Computer mit dem Netzwerk der Ebene 4 verbinden.
- Erstellen Sie Netzwerksicherheitsgruppen für jede Ebene und fügen Sie sie entsprechend an das Subnetz an.
- Sie können den Standardwert für die Sicherheitsgruppe der Ebene 4 verwenden.
- Sie müssen zusätzliche eingehende und ausgehende Regeln für die Sicherheitsgruppe der Ebene 3 (und niedriger) konfigurieren.
- Fügen Sie eingehende und ausgehende Sicherheitsregeln hinzu, um den gesamten Netzwerkdatenverkehr zu verweigern.
- Fügen Sie mit höherer Priorität eingehende und ausgehende Sicherheitsregeln hinzu, um Netzwerkdatenverkehr zu und aus dem IP-Bereich von Subnetzebene 4 zuzulassen.
- [Optional] Wenn Sie ein Jumpbox-Subnetz erstellen, erstellen Sie eingehende und ausgehende Regeln zum Zulassen von Datenverkehr zu und von diesem Subnetz.
- Erstellen Sie Linux-VMs auf Ebene 3 und Ebene 4.
- Informationen zur Spezifikation der VM finden Sie in überprüften Umgebungen.
- Verbinden Sie beim Erstellen des virtuellen Computers den Computer mit dem Subnetz, das in früheren Schritten erstellt wurde.
- Überspringen Sie die Sicherheitsgruppenerstellung für den virtuellen Computer.
Konfigurieren von benutzerdefiniertem DNS
Für Ebene 3 und darunter ist ein benutzerdefiniertes DNS erforderlich. Es stellt sicher, dass die DNS-Auflösung für Netzwerkdatenverkehr, der innerhalb des Clusters stammt, auf die Instanz der übergeordneten Ebene für die Layered Network Management-Instanz verweist. Integrieren Sie in einer vorhandenen oder Produktionsumgebung die folgenden DNS-Auflösungen in Ihr DNS-Design. Wenn Sie eine Testumgebung für Layered Network Management Service und Azure IoT Operations einrichten möchten, schauen Sie unter den folgenden Beispielen.
Konfigurieren von CoreDNS
Während das DNS-Setup auf viele verschiedene Arten erreicht werden kann, verwendet dieses Beispiel einen Erweiterungsmechanismus, der von CoreDNS bereitgestellt wird, welcher der Standard-DNS-Server für K3S-Cluster ist. URLs in der Zulassungsliste, die aufgelöst werden müssen, werden dem CoreDNS hinzugefügt.
Wichtig
Der CoreDNS-Ansatz gilt nur für K3S-Cluster auf dem Ubuntu-Host auf Ebene 3.
Erstellen von configmap aus Ebene 4 Layered Network Management Preview
Führen Sie die folgenden Schritte aus, nachdem der Cluster der Ebene 4 und die Layered Network Management bereit sind.
Bestätigen Sie die IP-Adresse des Layered Network Management-Diensts mit dem folgenden Befehl:
kubectl get services -n azure-iot-operationsDie Ausgabe sollte wie im folgenden Beispiel aussehen. Die IP-Adresse des Diensts lautet
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 29sAnsicht der Konfigurationszuordnungen mit folgendem Befehl:
kubectl get cm -n azure-iot-operationsDie Ausgabe sollte wie im folgenden Beispiel aussehen:
NAME DATA AGE aio-lnm-level4-config 1 50s aio-lnm-level4-client-config 1 50sAnpassen von
aio-lnm-level4-client-config. Diese Konfiguration wird als Teil der Ebene 3-Einrichtung benötigt, um den Datenverkehr vom Ebene 3-Cluster an die Layered Network Management-Instanz der obersten Ebene weiterzuleiten.# 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.yamlIn diesem Schritt wird eine Datei mit dem Namen
configmap-custom-level4.yamlerstellt
Konfigurieren der Ebene 3 CoreDNS von K3S
Nachdem Sie den K3S-Cluster eingerichtet und auf die isolierte Ebene 3 verschoben haben, konfigurieren Sie den CoreDNS der Ebene 3 K3S mit der zuvor erstellten angepassten Clientkonfiguration.
Kopieren Sie den
configmap-custom-level4.yaml-Host der Ebene 3 oder auf das System, von dem aus Sie auf den Cluster zugreifen.Führen Sie die folgenden Befehle aus:
# 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.Der vorherige Schritt setzt die DNS-Konfiguration zur Auflösung der auf die Positivliste gesetzten URLs innerhalb des Clusters auf Ebene 4. Um sicherzustellen, dass DNS außerhalb des Clusters dasselbe tut, müssen Sie „systemd-resolved“ konfigurieren, dass der Datenverkehr an CoreDNS innerhalb des K3S-Clusters weitergeleitet wird. Führen Sie die folgenden Befehle auf dem K3S-Host aus: Erstellen Sie das folgende Verzeichnis:
sudo mkdir /etc/systemd/resolved.conf.dErstellen Sie eine Datei namens
lnm.confmit folgendem Inhalt. Die IP-Adresse sollte die IP-Adresse der Ebene 3 des kube-dns-Diensts sein, der im kube-System-Namespace ausgeführt wird.[Resolve] DNS=<PUT KUBE-DNS SERVICE IP HERE> DNSStubListener=noStarten Sie den DNS-Konfliktlöser neu:
sudo systemctl restart systemd-resolved