Skapa exempelnätverksmiljö för Azure IoT Layered Network Management (förhandsversion)
Om du vill använda Tjänsten Azure IoT Layered Network Management (förhandsversion) måste du konfigurera en isolerad nätverksmiljö. Till exempel ISA-95/Purdue Network-arkitekturen. Den här sidan innehåller några exempel på hur du konfigurerar en testmiljö beror på hur du vill uppnå isoleringen.
- Fysisk segmentering – Nätverken separeras fysiskt. I det här fallet måste Layered Network Management (förhandsversion) distribueras till en dubbel nätverkskortsvärd (nätverksgränssnittskort) för att ansluta till både det Internetuppkopplade nätverket och det isolerade nätverket.
- Logisk segmentering – Nätverket är logiskt segmenterat med konfigurationer som VLAN, undernät eller brandvägg. Layered Network Management har en enda slutpunkt och konfigurerad för att vara synlig för sitt eget nätverkslager och det isolerade lagret.
Båda metoderna kräver att du konfigurerar en anpassad DNS i det isolerade nätverksskiktet för att dirigera nätverkstrafiken till layered Network Management-instansen i det övre lagret.
Viktigt!
De nätverksmiljöer som beskrivs i dokumentationen för Layered Network Management är exempel för testning av layered network management. Det är inte en rekommendation om hur du skapar nätverks- och klustertopologin för produktion.
Konfigurera isolerat nätverk med fysisk segmentering
Följande exempelkonfiguration är ett enkelt isolerat nätverk med minsta fysiska enheter.
- Den trådlösa åtkomstpunkten används för att konfigurera ett lokalt nätverk och ger inte internetåtkomst.
- Nivå 4-kluster är ett kluster med en nod som finns på en fysisk dator med dubbla nätverkskort (NIC) som ansluter till Internet och det lokala nätverket.
- Nivå 3-kluster är ett kluster med en nod som finns på en fysisk dator. Det här enhetsklustret ansluter bara till det lokala nätverket.
Layered Network Management distribueras till det dubbla NIC-klustret. Klustret i det lokala nätverket ansluter till Layered Network Management som proxy för att få åtkomst till Azure- och Arc-tjänster. Dessutom skulle det behövas en anpassad DNS i det lokala nätverket för att tillhandahålla domännamnsmatchning och peka trafiken till Layered Network Management. Mer information finns i Konfigurera anpassad DNS.
Konfigurera isolerat nätverk med logisk segmentering
Följande diagram illustrerar en isolerad nätverksmiljö där varje nivå segmenteras logiskt med undernät. I den här testmiljön finns det flera kluster ett på varje nivå. Klustren kan vara AKS Edge Essentials eller K3S. Kubernetes-klustret i nivå 4-nätverket har direkt internetåtkomst. Kubernetes-klustren på nivå 3 och lägre har inte internetåtkomst.
Flera nivåer av nätverk i den här testkonfigurationen utförs med hjälp av undernät i ett nätverk:
- Nivå 4-undernät (10.104.0.0/16) – Det här undernätet har åtkomst till Internet. Alla begäranden skickas till destinationerna på Internet. Det här undernätet har en enda Windows 11-dator med IP-adressen 10.104.0.10.
- Nivå 3-undernät (10.103.0.0/16) – Det här undernätet har inte åtkomst till Internet och är konfigurerat för att endast ha åtkomst till IP-adressen 10.104.0.10 på nivå 4. Det här undernätet innehåller en Windows 11-dator med IP-adressen 10.103.0.33 och en Linux-dator som är värd för en DNS-server. DNS-servern konfigureras med hjälp av stegen i Konfigurera anpassad DNS. Alla domäner i DNS-konfigurationen måste mappas till adressen 10.104.0.10.
- Nivå 2-undernät (10.102.0.0/16) – Precis som nivå 3 har det här undernätet inte åtkomst till Internet. Den är konfigurerad för att endast ha åtkomst till IP-adressen 10.103.0.33 på nivå 3. Det här undernätet innehåller en Windows 11-dator med IP-adressen 10.102.0.28 och en Linux-dator som är värd för en DNS-server. Det finns en Windows 11-dator (nod) i det här nätverket med IP-adressen 10.102.0.28. Alla domäner i DNS-konfigurationen måste mappas till adressen 10.103.0.33.
Se följande exempel för att konfigurera den här typen av nätverksmiljö.
Exempel på logisk segmentering med minsta möjliga maskinvara
I det här exemplet är båda datorerna anslutna till en åtkomstpunkt (AP) som ansluter till Internet. Värddatorn på nivå 4 kan komma åt Internet. Nivå 3-värden blockeras för åtkomst till Internet med AP:s konfiguration. Till exempel brandvägg eller klientkontroll. Eftersom båda datorerna finns i samma nätverk är layered Network Management-instansen på nivå 4-klustret som standard synlig för dator och kluster på nivå 3. En extra anpassad DNS måste konfigureras i det lokala nätverket för att tillhandahålla domännamnsmatchning och peka trafiken till Layered Network Management. Mer information finns i Konfigurera anpassad DNS.
Exempel på logisk segmentering i Azure
I det här exemplet skapas en testmiljö med ett virtuellt nätverk och en virtuell Linux-dator i Azure.
Viktigt!
Virtuell miljö är endast avsedd för utforskning och utvärdering. Mer information finns i miljöer som stöds för Azure IoT-åtgärder.
- Skapa ett virtuellt nätverk i din Azure-prenumeration. Skapa undernät för minst två lager (nivå 4 och nivå 3).
- Det är valfritt att skapa ett extra undernät för jumpbox- eller utvecklardatorn för fjärråtkomst till datorn eller klustret mellan lager. Den här konfigurationen är praktisk om du planerar att skapa fler än två nätverkslager. Annars kan du ansluta jumpbox-datorn till nivå 4-nätverket.
- Skapa nätverkssäkerhetsgrupper för varje nivå och anslut till undernätet i enlighet med detta.
- Du kan använda standardvärdet för säkerhetsgruppen nivå 4.
- Du måste konfigurera ytterligare regler för inkommande och utgående trafik för säkerhetsgruppen nivå 3 (och lägre nivå).
- Lägg till regler för inkommande och utgående säkerhet för att neka all nätverkstrafik.
- Med högre prioritet lägger du till regler för inkommande och utgående säkerhet för att tillåta nätverkstrafik till och från IP-intervallet för nivå 4-undernät.
- [Valfritt] Om du skapar ett jumpbox-undernät skapar du regler för inkommande och utgående trafik för att tillåta trafik till och från det här undernätet.
- Skapa virtuella Linux-datorer på nivå 3 och nivå 4.
- Se miljöer som stöds för specifikation av den virtuella datorn.
- När du skapar den virtuella datorn ansluter du datorn till det undernät som skapades i tidigare steg.
- Hoppa över skapandet av säkerhetsgruppen för den virtuella datorn.
Konfigurera anpassad DNS
En anpassad DNS krävs för nivå 3 och lägre. Det säkerställer att DNS-matchning för nätverkstrafik som kommer från klustret pekas på den överordnade nivån Layered Network Management-instansen. I en befintlig miljö eller produktionsmiljö lägger du till följande DNS-matchningar i DNS-designen. Om du vill konfigurera en testmiljö för Layered Network Management-tjänsten och Azure IoT Operations kan du läsa följande exempel.
Konfigurera CoreDNS
Dns-konfigurationen kan göras på många olika sätt, men i det här exemplet används en tilläggsmekanism som tillhandahålls av CoreDNS som är standard-DNS-servern för K3S-kluster. URL:er på listan över tillåtna adresser som måste lösas läggs till i CoreDNS.
Viktigt!
CoreDNS-metoden gäller endast för K3S-kluster på Ubuntu-värden på nivå 3.
Skapa konfigurationskarta från nivå 4 Layered Network Management
När nivå 4-klustret och Layered Network Management är klara utför du följande steg.
Bekräfta IP-adressen för Layered Network Management-tjänsten med följande kommando:
kubectl get services -n azure-iot-operationsResultatet bör likna följande. IP-adressen för tjänsten är
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 29sVisa konfigurationsmappningarna med följande kommando:
kubectl get cm -n azure-iot-operationsUtdata bör se ut som i följande exempel:
NAME DATA AGE aio-lnm-level4-config 1 50s aio-lnm-level4-client-config 1 50saio-lnm-level4-client-configAnpassa . Den här konfigurationen behövs som en del av konfigurationen på nivå 3 för att vidarebefordra trafik från nivå 3-klustret till den översta nivåinstansen för nätverkshantering på nivå 3.# 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.yamlDet här steget skapar en fil med namnet
configmap-custom-level4.yaml
Konfigurera nivå 3 CoreDNS för K3S
När du har konfigurerat K3S-klustret och flyttat det till det isolerade nivå 3-lagret konfigurerar du CoreDNS på nivå 3 K3S med den anpassade klientkonfigurationen som genererades tidigare.
configmap-custom-level4.yamlKopiera till nivå 3-värden eller till systemet där du fjärråtkomst till klustret.Kör följande kommandon:
# 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 address matches the ip address of the level 4 Layered Network Management instance.I föregående steg anges DNS-konfigurationen så att de tillåtna URL:erna i klustret matchas till nivå 4. För att säkerställa att DNS utanför klustret gör detsamma måste du konfigurera systemupplösad för att vidarebefordra trafik till CoreDNS i K3S-klustret. Kör följande kommandon på K3S-värden: Skapa följande katalog:
sudo mkdir /etc/systemd/resolved.conf.dSkapa en fil med namnet
lnm.confmed följande innehåll. IP-adressen ska vara ip-adressen på nivå 3 för kube-dns-tjänsten som körs i kube-system-namnområdet.[Resolve] DNS=<PUT KUBE-DNS SERVICE IP HERE> DNSStubListener=noStarta om DNS-matcharen:
sudo systemctl restart systemd-resolved