Condividi tramite

Eseguire moduli IoT Edge esistenti dai dispositivi FPGA di Azure Stack Edge Pro nel dispositivo AZURE Stack Edge Pro GPU

  • Articolo

SI APPLICA A:Yes for Pro GPU SKUAzure Stack Edge Pro - GPUYes for Pro R SKUAzure Stack Edge Pro R

Nota

È consigliabile distribuire la versione più recente di IoT Edge in una macchina virtuale Linux. IoT Edge gestito in Azure Stack Edge usa una versione precedente del runtime di IoT Edge che non dispone delle funzionalità e delle patch più recenti. Per istruzioni, vedere Come distribuire una macchina virtuale Ubuntu. Per altre informazioni su altre distribuzioni Linux supportate che possono eseguire IoT Edge, vedere Sistemi supportati di Azure IoT Edge - Motori di contenitori.

Questo articolo illustra in dettaglio le modifiche necessarie per un modulo IoT Edge basato su Docker che viene eseguito in Azure Stack Edge Pro FPGA in modo che possa essere eseguito in una piattaforma IoT Edge basata su Kubernetes nel dispositivo AZURE Stack Edge Pro GPU.

Informazioni sull'implementazione di IoT Edge

L'implementazione di IoT Edge è diversa nei dispositivi FPGA di Azure Stack Edge Pro rispetto a quella nei dispositivi Azure Stack Edge Pro GPU. Per i dispositivi GPU, Kubernetes viene usato come piattaforma di hosting per IoT Edge. IoT Edge nei dispositivi FPGA usa una piattaforma basata su Docker. Il modello di applicazione basato su Docker di IoT Edge viene convertito automaticamente nel modello di applicazione nativa kubernetes. Tuttavia, alcune modifiche potrebbero essere ancora necessarie perché è supportato solo un piccolo subset del modello di applicazione Kubernetes.

Se si esegue la migrazione dei carichi di lavoro da un dispositivo FPGA a un dispositivo GPU, sarà necessario apportare modifiche ai moduli IoT Edge esistenti per l'esecuzione corretta nella piattaforma Kubernetes. Potrebbe essere necessario specificare i requisiti di archiviazione, rete, utilizzo delle risorse e proxy Web in modo diverso.

Storage

Quando si specifica l'archiviazione per i moduli IoT Edge, prendere in considerazione le informazioni seguenti.

  • Archiviazione per i contenitori in Kubernetes viene specificato usando i montaggi dei volumi.
  • La distribuzione in Kubernetes non può avere associazioni per l'associazione di percorsi di archiviazione o host permanenti.
    • Per l'archiviazione permanente, usare Mounts con il tipo volume.
    • Per i percorsi host, usare Mounts con il tipo bind.
  • Per IoT Edge in Kubernetes, il binding tramite Mounts funziona solo per la directory e non per il file.

Esempio: Archiviazione tramite montaggi di volumi

Per IoT Edge in Docker, le associazioni di percorso host vengono usate per eseguire il mapping delle condivisioni nel dispositivo ai percorsi all'interno del contenitore. Ecco le opzioni di creazione del contenitore usate nei dispositivi FPGA:

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

Per i percorsi host per IoT Edge in Kubernetes, di seguito è riportato un esempio di uso Mounts con tipo bind :

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

Per i dispositivi GPU che eseguono IoT Edge in Kubernetes, i montaggi dei volumi vengono usati per specificare l'archiviazione. Per effettuare il provisioning dell'archiviazione usando condivisioni, il valore di Mounts.Source sarà il nome della condivisione SMB o NFS di cui è stato effettuato il provisioning nel dispositivo GPU. /home/input è il percorso in cui il volume è accessibile all'interno del contenitore. Ecco le opzioni di creazione del contenitore usate nei dispositivi GPU:

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

Rete

Quando si specifica la rete per i moduli IoT Edge, prendere in considerazione le informazioni seguenti.

  • HostPort specifica è necessaria per esporre un servizio sia all'interno che all'esterno del cluster.
    • Opzioni K8sExperimental per limitare l'esposizione del servizio solo al cluster.
  • La comunicazione tra moduli richiede HostPort la specifica e la connessione tramite la porta mappata (e non l'uso della porta esposta dal contenitore).
  • La rete host funziona con dnsPolicy = ClusterFirstWithHostNet, con che tutti i contenitori (in particolare edgeHub) non devono essere presenti anche nella rete host.
  • L'aggiunta di mapping delle porte per TCP, UDP nella stessa richiesta non funziona.

Esempio - Accesso esterno ai moduli

Per tutti i moduli IoT Edge che specificano le associazioni di porte, viene assegnato un indirizzo IP usando l'intervallo ip del servizio esterno Kubernetes specificato nell'interfaccia utente locale del dispositivo. Non sono state apportate modifiche alle opzioni di creazione del contenitore tra IoT Edge in Docker e IoT Edge in Kubernetes, come illustrato nell'esempio seguente.

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

Tuttavia, per eseguire una query sull'indirizzo IP assegnato al modulo, è possibile usare il dashboard kubernetes come descritto in Ottenere l'indirizzo IP per i servizi o i moduli.

In alternativa, è possibile Connessione all'interfaccia di PowerShell del dispositivo e usare il iotedge comando list per elencare tutti i moduli in esecuzione nel dispositivo. L'output del comando indicherà anche gli indirizzi IP esterni associati al modulo.

Utilizzo della risorsa

Con le configurazioni di IoT Edge basate su Kubernetes nei dispositivi GPU, le risorse come l'accelerazione hardware, la memoria e i requisiti della CPU vengono specificati in modo diverso rispetto ai dispositivi FPGA.

Utilizzo dell'accelerazione del calcolo

Per distribuire i moduli in FPGA, usare le opzioni di creazione del contenitore come illustrato nella configurazione seguente: 

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

Per la GPU, usare le specifiche delle richieste di risorse anziché le associazioni di dispositivi, come illustrato nella configurazione minima seguente. È necessario richiedere risorse nvidia invece di catapulta e non è necessario specificare .wireserver

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

Utilizzo della memoria e della CPU

Per impostare l'utilizzo della memoria e della CPU, usare i limiti del processore per i moduli nella k8s-experimental sezione . 

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

La memoria e la specifica della CPU non sono necessarie, ma in genere è consigliabile. Se requests non viene specificato, i valori impostati nei limiti vengono usati come minimo obbligatorio.

L'uso della memoria condivisa per i moduli richiede anche un modo diverso. Ad esempio, è possibile usare la modalità IPC host per l'accesso alla memoria condivisa tra Analisi video live e soluzioni di inferenza, come descritto in Distribuire Analisi video live in Azure Stack Edge.

Proxy Web

Quando si configura il proxy Web, prendere in considerazione le informazioni seguenti:

Se nella rete è configurato un proxy Web, configurare le variabili di ambiente seguenti per la distribuzione nella edgeHub configurazione di IoT Edge basata su Docker nei dispositivi FPGA:

  • https_proxy : <proxy URL>
  • UpstreamProtocol : AmqpWs (a meno che il proxy Web non consenta Amqp il traffico)

Per le configurazioni di IoT Edge basate su Kubernetes nei dispositivi GPU, è necessario configurare questa variabile aggiuntiva durante la distribuzione:

  • no_proxy:Localhost

  • Il proxy IoT Edge nella piattaforma Kubernetes usa la porta 35000 e 35001. Assicurarsi che il modulo non venga eseguito su queste porte o che possa causare conflitti di porta.

Altre differenze

  • Strategia di distribuzione: potrebbe essere necessario modificare il comportamento di distribuzione per tutti gli aggiornamenti del modulo. Il comportamento predefinito per i moduli IoT Edge è l'aggiornamento in sequenza. Questo comportamento impedisce il riavvio del modulo aggiornato se il modulo usa risorse come l'accelerazione hardware o le porte di rete. Questo comportamento può avere effetti imprevisti, specialmente quando si gestiscono volumi persistenti nella piattaforma Kubernetes per i dispositivi GPU. Per eseguire l'override di questo comportamento predefinito, è possibile specificare un nella Recreate k8s-experimental sezione del modulo.

    {
  "k8s-experimental": {
    "strategy": {
      "type": "Recreate"
    }
  }
}

  • Nomi dei moduli: i nomi dei moduli devono seguire le convenzioni di denominazione di Kubernetes. Potrebbe essere necessario rinominare i moduli in esecuzione in IoT Edge con Docker quando si spostano tali moduli in IoT Edge con Kubernetes. Per altre informazioni sulla denominazione, vedere Convenzioni di denominazione di Kubernetes.

  • Altre opzioni:

    • Alcune opzioni di creazione di Docker che funzionano sui dispositivi FPGA non funzioneranno nell'ambiente Kubernetes nei dispositivi GPU. Ad esempio: , come – EntryPoint.
    • Le variabili di ambiente, : ad esempio, devono essere sostituite da __.
    • Lo stato creazione del contenitore per un pod Kubernetes comporta lo stato di backoff per un modulo nella risorsa hub IoT. Anche se esistono diversi motivi per cui il pod si trova in questo stato, un motivo comune è che viene eseguito il pull di un'immagine contenitore di grandi dimensioni su una connessione a larghezza di banda di rete bassa. Quando il pod è in questo stato, lo stato del modulo viene visualizzato come backoff nell'hub IOT anche se il modulo è appena avviato.

Passaggi successivi