Azure IoT Layered Network Management 用のサンプル ネットワーク環境を作成する (プレビュー)

重要

Azure Arc によって有効にされる Azure IoT Operations Preview は、現在プレビュー段階です。 運用環境ではこのプレビュー ソフトウェアを使わないでください。

一般提供リリースが利用可能になったタイミングで新しい Azure IoT Operations のインストールをデプロイする必要があります。 プレビュー インストールをアップグレードすることはできません。

ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

Azure IoT Layered Network Management (プレビュー) サービスを使用するには、分離されたネットワーク環境を構成する必要があります。 たとえば、ISA-95/Purdue ネットワーク アーキテクチャなどです。 このページでは、分離を実現する方法に応じてテスト環境を設定する例をいくつか示します。

  • 物理セグメント化 - ネットワークは物理的に分離されます。 この場合、インターネットに接続するネットワークと分離されたネットワークの両方に接続するには、Layered Network Management をデュアル NIC (ネットワーク インターフェイス カード) ホストに展開する必要があります。
  • 論理セグメント化 - ネットワークは、VLAN、サブネット、ファイアウォールなどの構成で論理的にセグメント化されます。 Layered Network Management には単一のエンドポイントがあり、独自のネットワーク レイヤーと分離レイヤーに表示されるように構成されています。

どちらの方法でも、分離されたネットワーク層でカスタム DNS を構成して、ネットワーク トラフィックを上位レイヤーの Layered Network Management インスタンスに転送する必要があります。

重要

Layered Network Management のドキュメントで説明されているネットワーク環境は、Layered Network Management をテストするための例です。 運用環境のネットワークやクラスター トポロジーのビルド方法向けの推奨ではありません。

物理セグメント化を使用して分離ネットワークを構成する

次の構成例は、最小限の物理デバイスを備えた単純な分離ネットワークです。

物理デバイスの分離ネットワーク構成の図。

  • ワイヤレス アクセス ポイントはローカル ネットワークの設定に使用され、インターネット アクセスは提供されません。
  • レベル 4 クラスターは、インターネットとローカル ネットワークに接続するデュアル ネットワーク インターフェイス カード (NIC) 物理マシンでホストされる単一ノード クラスターです。
  • レベル 3 クラスターは、物理マシンでホストされる単一ノード クラスターです。 このデバイス クラスターは、ローカル ネットワークにのみ接続します。

Layered Network Management は、デュアル NIC クラスターにデプロイされます。 ローカル ネットワーク内のクラスターは、Azure および Arc サービスにアクセスするためのプロキシとして Layered Network Management に接続します。 さらに、ドメイン名解決を提供し、トラフィックを Layered Network Management に向けるために、ローカル ネットワークにカスタム DNS が必要になります。 詳細については、「カスタム DNS の構成」を参照してください。

論理セグメント化を使用して分離ネットワークを構成する

次の図は、各レベルが論理的にサブネットでセグメント化された、分離されたネットワーク環境です。 このテスト環境では、各レベルに 1 つずつ、複数のクラスターがあります。 これらのクラスターは、AKS Edge Essentials または K3S です。 レベル 4 ネットワークの Kubernetes クラスターは、インターネットに直接アクセスできます。 レベル 3 以下の Kubernetes クラスターは、インターネットにアクセスできません。

論理セグメント化の分離ネットワークの図。

このテストのセットアップにおける複数のネットワーク レベルは、ネットワーク内のサブネットを使用して実現されます。

  • レベル 4 サブネット (10.104.0.0/16) - このサブネットはインターネットにアクセスできます。 すべての要求は、インターネット上の宛先に送信されます。 このサブネットには、IP アドレス 10.104.0.10 を持つ単一の Windows 11 マシンがあります。
  • レベル 3 サブネット (10.103.0.0/16) - このサブネットはインターネットにアクセスできないため、レベル 4 の IP アドレス 10.104.0.10 にのみアクセスできるように構成されています。 このサブネットには、IP アドレス 10.103.0.33 の Windows 11 マシンと、DNS サーバーをホストする Linux マシンが含まれています。 DNS サーバーは、「カスタム DNS の構成」の手順を使用して構成されます。 DNS 構成内のすべてのドメインを、アドレス 10.104.0.10 にマップする必要があります。
  • レベル 2 サブネット (10.102.0.0/16) - レベル 3 と同様に、このサブネットはインターネットにアクセスできません。 レベル 3 の IP アドレス 10.103.0.33 にのみアクセスできるように構成されます。 このサブネットには、IP アドレス 10.102.0.28 の Windows 11 マシンと、DNS サーバーをホストする Linux マシンが含まれています。 このネットワークには、IP アドレス 10.102.0.28 の Windows 11 マシン (ノード) が 1 つあります。 DNS 構成内のすべてのドメインを、アドレス 10.103.0.33 にマップする必要があります。

この種類のネットワーク環境をセットアップするには、次の例を参照してください。

最小ハードウェアを使用した論理セグメント化の例

この例では、両方のマシンがインターネットに接続するアクセス ポイント (AP) に接続されています。 レベル 4 のホスト コンピューターは、インターネットにアクセスできます。 レベル 3 のホストは、AP の構成でインターネットにアクセスするためにブロックされます。 たとえば、ファイアウォールやクライアント制御などです。 両方のマシンが同じネットワーク内に存在するため、レベル 4 クラスターでホストされている Layered Network Management インスタンスは、既定でレベル 3 のマシンとクラスターに表示されます。 ドメイン名解決を提供し、トラフィックを Layered Network Management に向けるために、ローカル ネットワークに追加のカスタム DNS を設定する必要があります。 詳細については、「カスタム DNS の構成」を参照してください。

論理分離ネットワーク構成の図。

Azure での論理セグメント化の例

この例では、仮想ネットワークLinux 仮想マシンを Azure で使用してテスト環境を作成します。

重要

仮想環境は、探索と評価のみを目的としています。 詳細については、Azure IoT Operations (プレビュー) の検証済み環境について参照してください。

  1. ご利用の Azure サブスクリプションに、仮想ネットワークを作成します。 少なくとも 2 つのレイヤー (レベル 4 とレベル 3) のサブネットを作成します。 Azure での仮想ネットワークのスクリーンショット。
  2. ジャンプボックスまたは開発者 マシン用の追加のサブネットを作成して、レイヤー間でコンピューターまたはクラスターにリモートでアクセスするオプションです。 この設定は、2 つ以上のネットワーク レイヤーを作成する場合に便利です。 それ以外の場合は、ジャンプボックス マシンをレベル 4 のネットワークに接続できます。
  3. 各レベルのネットワーク セキュリティ グループを作成し、それに応じてサブネットにアタッチします。
  4. レベル 4 のセキュリティ グループには既定値を使用できます。
  5. レベル 3 (および下位レベル) のセキュリティ グループに対して、追加のインバウンド規則とアウトバウンド規則を構成する必要があります。
    • インバウンドとアウトバウンドのセキュリティ規則を追加して、すべてのネットワーク トラフィックを拒否します。
    • 優先順位が高い場合は、レベル 4 サブネットの IP 範囲との間のネットワーク トラフィックを許可するインバウンドとアウトバウンドのセキュリティ規則を追加します。
    • [省略可能] ジャンプボックス サブネットを作成する場合は、このサブネットとの間のトラフィックを許可するためのインバウンド規則とアウトバウンド規則を作成します。 レベル 3 セキュリティ グループのスクリーンショット。
  6. レベル 3 とレベル 4 で Linux VM を作成します。
    • VM の仕様については、検証済みの環境について参照してください。
    • VM を作成するときは、前の手順で作成したサブネットにマシンを接続します。
    • VM のセキュリティ グループの作成をスキップします。

カスタム DNS の構成

レベル 3 以下には、カスタム DNS が必要です。 これにより、クラスター内で発信されるネットワーク トラフィックの DNS 解決が、親レベルの Layered Network Management インスタンスを指します。 既存または運用環境では、次の DNS 解決を DNS 設計に組み込みます。 Layered Network Management サービスと Azure IoT Operations 用のテスト環境を設定する場合は、次の例を参照できます。

CoreDNS を構成する

DNS のセットアップはさまざまな方法で実現できますが、この例では、K3S クラスターの既定の DNS サーバーである CoreDNS によって提供される拡張メカニズムを使用します。 解決する必要がある許可リストの URL が CoreDNS に追加されます。

重要

CoreDNS アプローチは、レベル 3 の Ubuntu ホスト上の K3S クラスターにのみ適用されます。

レベル 4 Layered Network Management から configmap を作成する (プレビュー)

レベル 4 クラスターと Layered Network Management の準備ができたら、次の手順を実行します。

  1. 次のコマンドを使用して、Layered Network Management サービスの IP アドレスを確認します。

    kubectl get services -n azure-iot-operations
    

    出力は次のようになります。 サービスの IP アドレスは 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. 次のコマンドを使用して、構成マップを表示します。

    kubectl get cm -n azure-iot-operations
    

    出力は次の例のようになります。

    NAME                           DATA   AGE
    aio-lnm-level4-config          1      50s
    aio-lnm-level4-client-config   1      50s
    
  3. aio-lnm-level4-client-config をカスタマイズします。 この構成は、レベル 3 クラスターから最上位レベルの Layered Network Management インスタンスにトラフィックを転送するために、レベル 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.yaml
    

    この手順では、configmap-custom-level4.yaml という名前のファイルを作成します。

K3S のレベル 3 CoreDNS を構成する

K3S クラスターを設定し、それをレベル 3 の分離レイヤーに移動した後、以前に生成されたカスタマイズ済みのクライアント構成でレベル 3 K3S の CoreDNS を構成します。

  1. configmap-custom-level4.yaml をレベル 3 のホスト、またはクラスターにリモートでアクセスするシステムにコピーします。

  2. 次のコマンドを実行します。

    # 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. 前の手順では、クラスター内の許可リストに登録されている URL をレベル 4 に解決するように DNS 構成を設定します。 クラスター外の DNS が確実に同じ動作をするには、K3S クラスター内の CoreDNS にトラフィックを転送するように systemd-resolved を構成する必要があります。 K3S ホストで次のコマンドを実行します。次のディレクトリを作成します。

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

    次の内容を含む lnm.conf という名前のファイルを作成します。 IP アドレスは、kube-system 名前空間で実行されている kube-dns サービスのレベル 3 クラスター IP アドレスである必要があります。

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

    DNS リゾルバーを再起動します。

    sudo systemctl restart systemd-resolved
    

Azure IoT Layered Network Management とは (プレビュー)