Bestaande IoT Edge-modules uitvoeren vanaf Azure Stack Edge Pro FPGA-apparaten op een Azure Stack Edge Pro GPU-apparaat
VAN TOEPASSING OP: Azure Stack Edge Pro - GPUAzure 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
volume
permanente opslagMounts
. - Voor hostpaden gebruikt
Mounts
u dit typebind
.
- Gebruik dit type voor
- 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 nameedgeHub
) 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 wireserver
niet 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 toestaatAmqp
)
Voor de Op Kubernetes gebaseerde IoT Edge-instellingen op GPU-apparaten moet u deze extra variabele configureren tijdens de implementatie:
no_proxy
: localhostIoT 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 dek8s-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
- Meer informatie over het configureren van GPU voor het gebruik van een module.