Delen via


Bestaande IoT Edge-modules uitvoeren vanaf Azure Stack Edge Pro FPGA-apparaten op een Azure Stack Edge Pro GPU-apparaat

VAN TOEPASSING OP: Ja voor Pro GPU-SKUAzure Stack Edge Pro - GPUJa voor Pro R SKUAzure Stack Edge Pro R

Notitie

We raden u ten zeerste aan de nieuwste IoT Edge-versie te implementeren op een Virtuele Linux-machine. De beheerde IoT Edge in Azure Stack Edge maakt gebruik van een oudere versie van IoT Edge-runtime die niet beschikt over de nieuwste functies en patches. Zie voor instructies hoe u een Ubuntu-VM implementeert. Zie Voor meer informatie over andere ondersteunde Linux-distributies die IoT Edge kunnen uitvoeren, azure IoT Edge ondersteunde systemen : containerengines.

In dit artikel worden de wijzigingen beschreven die nodig zijn voor een Op Docker gebaseerde IoT Edge-module die wordt uitgevoerd op Azure Stack Edge Pro FPGA, zodat deze kan worden uitgevoerd op een Op Kubernetes gebaseerd IoT Edge-platform op een Azure Stack Edge Pro GPU-apparaat.

Over IoT Edge-implementatie

De IoT Edge-implementatie verschilt op Azure Stack Edge Pro FPGA-apparaten versus die op Azure Stack Edge Pro GPU-apparaten. Voor de GPU-apparaten wordt Kubernetes gebruikt als hostingplatform voor IoT Edge. De IoT Edge op FPGA-apparaten maakt gebruik van een docker-platform. Het ioT Edge-toepassingsmodel op basis van docker wordt automatisch vertaald naar het systeemeigen Kubernetes-toepassingsmodel. Sommige wijzigingen zijn echter nog steeds nodig, omdat slechts een kleine subset van het Kubernetes-toepassingsmodel wordt ondersteund.

Als u uw workloads migreert van een FPGA-apparaat naar een GPU-apparaat, moet u wijzigingen aanbrengen in de bestaande IoT Edge-modules, zodat deze met succes kunnen worden uitgevoerd op het Kubernetes-platform. Mogelijk moet u de vereisten voor opslag, netwerken, resourcegebruik en webproxy anders opgeven.

Storage

Houd rekening met de volgende informatie bij het opgeven van opslag voor de IoT Edge-modules.

  • Opslag voor containers in Kubernetes wordt opgegeven met volumekoppelingen.
  • Implementatie in Kubernetes kan geen bindingen hebben voor het koppelen van permanente opslag- of hostpaden.
    • Gebruik dit type voor volumepermanente opslagMounts.
    • Voor hostpaden gebruikt Mounts u dit type bind.
  • Voor IoT Edge in Kubernetes werkt bind alleen Mounts voor map en niet voor bestand.

Voorbeeld: opslag via volumekoppelingen

Voor IoT Edge in docker worden hostpadbindingen gebruikt om de shares op het apparaat toe te wijzen aan paden in de container. Dit zijn de opties voor het maken van containers die worden gebruikt op FPGA-apparaten:

{
  "HostConfig": 
  {
   "Binds": 
    [
     "<Host storage path for Edge local share>:<Module storage path>"
    ]
   }
}

Voor hostpaden voor IoT Edge in Kubernetes wordt hier een voorbeeld van het gebruik Mounts met het type bind weergegeven:

{
    "HostConfig": {
        "Mounts": [
            {
                "Target": "<Module storage path>",
                "Source": "<Host storage path>",
                "Type": "bind"
            }
        ]
    }
}

Voor de GPU-apparaten met IoT Edge in Kubernetes worden volumekoppelingen gebruikt om opslag op te geven. Als u opslag wilt inrichten met behulp van Mounts.Source shares, is dit de waarde van de SMB- of NFS-share die is ingericht op uw GPU-apparaat. Het /home/input is het pad waarop het volume toegankelijk is binnen de container. Dit zijn de opties voor het maken van containers die worden gebruikt op de GPU-apparaten:

{
    "HostConfig": {
        "Mounts": [
        {
            "Target": "/home/input",
            "Source": "<nfs-or-smb-share-name-here>",
            "Type": "volume"
        },
        {
            "Target": "/home/output",
            "Source": "<nfs-or-smb-share-name-here>",
            "Type": "volume"
        }]
    }
}

Netwerk

Houd rekening met de volgende informatie bij het opgeven van netwerken voor de IoT Edge-modules.

  • HostPort specificatie is vereist om een service zowel binnen als buiten het cluster beschikbaar te maken.
    • K8sExperimental options to limit exposure of service only to cluster.
  • Communicatie tussen modules vereist HostPort specificatie en verbinding met behulp van toegewezen poort (en niet met behulp van de poort die beschikbaar is voor de container).
  • Hostnetwerken werken met dnsPolicy = ClusterFirstWithHostNet, omdat alle containers (met name edgeHub) niet ook op het hostnetwerk hoeven te zijn.
  • Het toevoegen van poorttoewijzingen voor TCP, UDP in dezelfde aanvraag werkt niet.

Voorbeeld: externe toegang tot modules

Voor ioT Edge-modules die poortbindingen opgeven, wordt een IP-adres toegewezen met behulp van het IP-adresbereik van de externe Kubernetes-service dat is opgegeven in de lokale gebruikersinterface van het apparaat. Er zijn geen wijzigingen in de opties voor het maken van containers tussen IoT Edge in docker versus IoT Edge in Kubernetes, zoals wordt weergegeven in het volgende voorbeeld.

{
    "HostConfig": {
        "PortBindings": {
            "5000/tcp": [
                {
                    "HostPort": "5000"
                }
            ]
        }
    }
}

Als u echter een query wilt uitvoeren op het IP-adres dat aan uw module is toegewezen, kunt u het Kubernetes-dashboard gebruiken zoals beschreven in IP-adres ophalen voor services of modules.

U kunt ook verbinding maken met de PowerShell-interface van het apparaat en de iotedge lijstopdracht gebruiken om alle modules weer te geven die op uw apparaat worden uitgevoerd. De uitvoer van de opdracht geeft ook de externe IP-adressen aan die aan de module zijn gekoppeld.

Resourcegebruik

Met de Op Kubernetes gebaseerde IoT Edge-instellingen op GPU-apparaten worden de resources zoals hardwareversnelling, geheugen en CPU-vereisten anders opgegeven dan op de FPGA-apparaten.

Gebruik van rekenversnelling

Als u modules in FPGA wilt implementeren, gebruikt u de opties voor het maken van containers, zoals wordt weergegeven in de volgende configuratie:

{
    "HostConfig": {
    "Privileged": true,
    "PortBindings": {
        "50051/tcp": [
        {
            "HostPort": "50051"
        }
        ]
    }
    },
    "k8s-experimental": {
    "resources": {
        "limits": {
        "microsoft.com/fpga_catapult": 2
        },
        "requests": {
        "microsoft.com/fpga_catapult": 2
        }
    }
    },
    "Env": [
    "WIRESERVER_ADDRESS=10.139.218.1"
    ]
}

Gebruik voor GPU specificaties voor resourceaanvragen in plaats van apparaatbindingen, zoals wordt weergegeven in de volgende minimale configuratie. U vraagt nvidia-resources aan in plaats van catapult en u hoeft het wireserverniet op te geven.

{
    "HostConfig": {
    "Privileged": true,
    "PortBindings": {
        "50051/tcp": [
        {
            "HostPort": "50051"
        }
        ]
    }
    },
    "k8s-experimental": {
    "resources": {
        "limits": {
        "nvidia.com/gpu": 2
        }    
    }
}

Geheugen- en CPU-gebruik

Als u geheugen- en CPU-gebruik wilt instellen, gebruikt u processorlimieten voor modules in de k8s-experimental sectie.

    "k8s-experimental": {
    "resources": {
        "limits": {
            "memory": "128Mi",
            "cpu": "500m",
            "nvidia.com/gpu": 2
        },
        "requests": {
            "nvidia.com/gpu": 2
        }
}

De geheugen- en CPU-specificatie zijn niet nodig, maar over het algemeen een goede gewoonte. Als requests dit niet is opgegeven, worden de waarden die zijn ingesteld in limieten gebruikt als het minimum dat is vereist.

Voor het gebruik van gedeeld geheugen voor modules is ook een andere manier vereist. U kunt bijvoorbeeld de host-IPC-modus gebruiken voor gedeelde geheugentoegang tussen Live Video Analytics- en deductieoplossingen, zoals beschreven in Live Video Analytics implementeren in Azure Stack Edge.

Webproxy

Houd rekening met de volgende informatie bij het configureren van de webproxy:

Als u een webproxy in uw netwerk hebt geconfigureerd, configureert u de volgende omgevingsvariabelen voor de edgeHub implementatie op uw Op Docker gebaseerde IoT Edge-installatie op FPGA-apparaten:

  • https_proxy : <proxy URL>
  • UpstreamProtocol : AmqpWs (tenzij de webproxy verkeer toestaat Amqp )

Voor de Op Kubernetes gebaseerde IoT Edge-instellingen op GPU-apparaten moet u deze extra variabele configureren tijdens de implementatie:

  • no_proxy: localhost

  • IoT Edge-proxy op het Kubernetes-platform maakt gebruik van poort 35000 en 35001. Zorg ervoor dat uw module niet wordt uitgevoerd op deze poorten of dat deze poortconflicten kan veroorzaken.

Andere verschillen

  • Implementatiestrategie: mogelijk moet u het implementatiegedrag wijzigen voor updates in de module. Het standaardgedrag voor IoT Edge-modules is rolling update. Dit gedrag voorkomt dat de bijgewerkte module opnieuw wordt opgestart als de module gebruikmaakt van resources zoals hardwareversnelling of netwerkpoorten. Dit gedrag kan onverwachte gevolgen hebben, speciaal bij het omgaan met permanente volumes op het Kubernetes-platform voor de GPU-apparaten. Als u dit standaardgedrag wilt overschrijven, kunt u een Recreate in de k8s-experimental sectie in uw module opgeven.

    {
      "k8s-experimental": {
        "strategy": {
          "type": "Recreate"
        }
      }
    }
    
  • Modulenamen: Modulenamen moeten de Kubernetes-naamconventies volgen. Mogelijk moet u de naam van de modules die worden uitgevoerd op IoT Edge wijzigen met Docker wanneer u deze modules verplaatst naar IoT Edge met Kubernetes. Zie Kubernetes-naamconventies voor meer informatie over naamgeving.

  • Andere opties:

    • Bepaalde docker-opties voor het maken van FPGA-apparaten werken niet in de Kubernetes-omgeving op uw GPU-apparaten. Bijvoorbeeld: , zoals – EntryPoint.
    • Omgevingsvariabelen, zoals : moeten worden vervangen door __.
    • Container maken status voor een Kubernetes-pod leidt tot uitstelstatus voor een module in de IoT Hub-resource. Hoewel er een aantal redenen zijn waarom de pod deze status heeft, is een veelvoorkomende reden dat een grote containerinstallatiekopie wordt opgehaald via een verbinding met een lage netwerkbandbreedte. Wanneer de pod deze status heeft, wordt de status van de module weergegeven als uitstel in IOT Hub, hoewel de module net wordt gestart.

Volgende stappen