Köra befintliga IoT Edge-moduler från Azure Stack Edge Pro FPGA-enheter på Azure Stack Edge Pro GPU-enhet

Artikel
10/26/2023

GÄLLER FÖR: Yes for Pro GPU SKU Azure Stack Edge Pro – GPU Yes for Pro R SKU Azure Stack Edge Pro R

Kommentar

Vi rekommenderar starkt att du distribuerar den senaste IoT Edge-versionen på en virtuell Linux-dator. Den hanterade IoT Edge på Azure Stack Edge använder en äldre version av IoT Edge-körningen som inte har de senaste funktionerna och korrigeringarna. Anvisningar finns i Distribuera en virtuell Ubuntu-dator. Mer information om andra Linux-distributioner som stöds som kan köra IoT Edge finns i System som stöds av Azure IoT Edge – Containermotorer.

Den här artikeln beskriver de ändringar som krävs för en Docker-baserad IoT Edge-modul som körs på Azure Stack Edge Pro FPGA så att den kan köras på en Kubernetes-baserad IoT Edge-plattform på Azure Stack Edge Pro GPU-enhet.

Om IoT Edge-implementering

IoT Edge-implementeringen skiljer sig på Azure Stack Edge Pro FPGA-enheter jämfört med på Azure Stack Edge Pro GPU-enheter. För GPU-enheter används Kubernetes som värdplattform för IoT Edge. IoT Edge på FPGA-enheter använder en Docker-baserad plattform. Den dockerbaserade IoT Edge-programmodellen översätts automatiskt till den inbyggda Kubernetes-programmodellen. Vissa ändringar kan dock fortfarande behövas eftersom endast en liten delmängd av Kubernetes-programmodellen stöds.

Om du migrerar dina arbetsbelastningar från en FPGA-enhet till en GPU-enhet måste du göra ändringar i befintliga IoT Edge-moduler för att de ska kunna köras på Kubernetes-plattformen. Du kan behöva ange dina krav för lagring, nätverk, resursanvändning och webbproxy på olika sätt.

Lagring

Tänk på följande information när du anger lagring för IoT Edge-modulerna.

Lagring för containrar på Kubernetes anges med hjälp av volymmonteringar.
Distribution på Kubernetes kan inte ha bindningar för att associera beständiga lagrings- eller värdsökvägar.
- För beständig lagring använder du Mounts med typen volume.
- För värdsökvägar använder du Mounts med typen bind.
För IoT Edge på Kubernetes fungerar bindning genom Mounts endast för katalog och inte för fil.

Exempel – Lagring via volymmonteringar

För IoT Edge på docker används bindningar för värdsökväg för att mappa resurserna på enheten till sökvägar i containern. Här är alternativen för att skapa containrar som används på FPGA-enheter:

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

För värdsökvägar för IoT Edge på Kubernetes visas ett exempel på användning med Mounts typ bind här:

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

För GPU-enheter som kör IoT Edge på Kubernetes används volymmonteringar för att ange lagring. Om du vill etablera lagring med hjälp av Mounts.Source resurser är värdet för namnet på den SMB- eller NFS-resurs som etablerades på GPU-enheten. /home/input är den sökväg där volymen är tillgänglig i containern. Här är alternativen för att skapa containrar som används på GPU-enheterna:

{
    "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"
        }]
    }
}

Nätverk

Tänk på följande information när du anger nätverk för IoT Edge-modulerna.

HostPort specifikation krävs för att exponera en tjänst både i och utanför klustret.
- K8sExperimental-alternativ för att begränsa exponeringen av tjänsten endast för kluster.
Kommunikation mellan moduler kräver HostPort specifikation och anslutning med mappad port (och inte med containerns exponerade port).
Värdnätverk fungerar med dnsPolicy = ClusterFirstWithHostNet, med att alla containrar (särskilt edgeHub) inte behöver finnas i värdnätverket också.
Att lägga till portmappningar för TCP fungerar inte UDP i samma begäran.

Exempel – Extern åtkomst till moduler

För alla IoT Edge-moduler som anger portbindningar tilldelas en IP-adress med kubernetes externa tjänst-IP-intervall som angavs i enhetens lokala användargränssnitt. Det finns inga ändringar i alternativen för att skapa containrar mellan IoT Edge på docker vs IoT Edge på Kubernetes enligt följande exempel.

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

Men om du vill fråga den IP-adress som tilldelats till din modul kan du använda Kubernetes-instrumentpanelen enligt beskrivningen i Hämta IP-adress för tjänster eller moduler.

Du kan också Anslut till Enhetens PowerShell-gränssnitt och använda iotedge listkommandot för att visa alla moduler som körs på enheten. Kommandots utdata anger också de externa IP-adresser som är associerade med modulen.

Resursanvändning

Med Kubernetes-baserade IoT Edge-installationer på GPU-enheter anges resurser som maskinvaruacceleration, minne och CPU-krav på olika sätt än på FPGA-enheterna.

Användning av beräkningsacceleration

Om du vill distribuera moduler på FPGA använder du alternativen för att skapa containrar enligt följande konfiguration:

{
    "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"
    ]
}

För GPU använder du specifikationer för resursbegäran i stället för Enhetsbindningar enligt följande minimala konfiguration. Du begär nvidia-resurser i stället för katapult och du behöver inte ange wireserver.

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

Minnes- och CPU-användning

Om du vill ange minnes- och CPU-användning använder du processorgränser för moduler i avsnittet k8s-experimental .

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

Minnes- och CPU-specifikationen är inte nödvändiga, men i allmänhet är det bra. Om requests inte anges används de värden som anges i gränser som det minsta som krävs.

Att använda delat minne för moduler kräver också ett annat sätt. Du kan till exempel använda värd-IPC-läget för delad minnesåtkomst mellan lösningar för livevideoanalys och slutsatsdragning enligt beskrivningen i Distribuera Live Video Analytics på Azure Stack Edge.

Webbproxy

Tänk på följande information när du konfigurerar webbproxy:

Om du har en webbproxy konfigurerad i nätverket konfigurerar du följande miljövariabler för distributionen edgeHub på din Docker-baserade IoT Edge-konfiguration på FPGA-enheter:

https_proxy : <proxy URL>
UpstreamProtocol : AmqpWs (om inte webbproxyn tillåter Amqp trafik)

För Kubernetes-baserade IoT Edge-installationer på GPU-enheter måste du konfigurera den här ytterligare variabeln under distributionen:

no_proxy:Localhost
IoT Edge-proxy på Kubernetes-plattformen använder port 35000 och 35001. Kontrollera att modulen inte körs vid dessa portar eller att den kan orsaka portkonflikter.

Andra skillnader

Distributionsstrategi: Du kan behöva ändra distributionsbeteendet för eventuella uppdateringar av modulen. Standardbeteendet för IoT Edge-moduler är löpande uppdatering. Det här beteendet förhindrar att den uppdaterade modulen startas om om modulen använder resurser som maskinvaruacceleration eller nätverksportar. Det här beteendet kan ha oväntade effekter, särskilt när du hanterar beständiga volymer på Kubernetes-plattformen för GPU-enheterna. Om du vill åsidosätta det här standardbeteendet kan du ange ett Recreate i k8s-experimental avsnittet i modulen.
```
{
  "k8s-experimental": {
    "strategy": {
      "type": "Recreate"
    }
  }
}
```
Modulnamn: Modulnamn bör följa Kubernetes namngivningskonventioner. Du kan behöva byta namn på modulerna som körs på IoT Edge med Docker när du flyttar modulerna till IoT Edge med Kubernetes. Mer information om namngivning finns i Namngivningskonventioner för Kubernetes.
Andra alternativ:
- Vissa docker-skapandealternativ som fungerade på FPGA-enheter fungerar inte i Kubernetes-miljön på dina GPU-enheter. Till exempel: , som – EntryPoint.
- Miljövariabler som : behöver ersättas med __.
- Containern Skapa status för en Kubernetes-podd leder till backoff-status för en modul på IoT Hub-resursen. Det finns ett antal orsaker till att podden har den här statusen, men en vanlig orsak är när en stor containeravbildning hämtas över en anslutning med låg nätverksbandbredd. När podden är i det här tillståndet visas statusen för modulen som backoff i IOT Hub även om modulen precis har startats.

Nästa steg

Läs mer om hur du konfigurerar GPU för att använda en modul.

Dela via