Compartilhar via

Executar módulos IoT Edge existentes de Azure Stack Edge Pro FPGA no Azure Stack Edge Pro GPU

  • Artigo

APLICA-SE A: Sim para SKU do Pro GPUAzure Stack Edge Pro – GPUSim para SKU do Pro RAzure Stack Edge Pro R

Observação

É altamente recomendável implantar a versão mais recente do IoT Edge em uma VM do Linux. O IoT Edge gerenciado no Azure Stack Edge usa uma versão mais antiga do runtime do IoT Edge que não tem os recursos e patches mais recentes. Para obter instruções, veja como implantar uma VM do Ubuntu. Para obter mais informações sobre outras distribuições do Linux com suporte que podem executar o IoT Edge, consulte Sistemas com suporte do Azure IoT Edge – Mecanismos de contêiner.

Este artigo detalha as alterações necessárias para um módulo de IoT Edge baseado em Docker que é executado no Azure Stack Edge Pro FPGA para que ele possa ser executado em uma plataforma de IoT Edge baseada em Kubernetes em um dispositivo de Azure Stack Edge Pro GPU.

Sobre a implementação de IoT Edge

A implementação de IoT Edge é diferente em dispositivos do Azure Stack Edge Pro FPGA versus em Azure Stack Edge Pro GPU. Para os dispositivos GPU, o Kubernetes é usado como uma plataforma de hospedagem para IoT Edge. O IoT Edge em dispositivos FPGA usa uma plataforma baseada em Docker. O modelo de aplicativo baseado no Docker IoT Edge é automaticamente traduzido para o modelo de aplicativo nativo do kubernetes. No entanto, algumas alterações ainda podem ser necessárias, pois há suporte apenas para um pequeno subconjunto do modelo de aplicativo Kubernetes.

Se você estiver migrando suas cargas de trabalho de um dispositivo FPGA para um dispositivo GPU, precisará fazer alterações nos módulos IoT Edge existentes para que elas sejam executados com êxito na plataforma Kubernetes. Talvez seja necessário especificar seus requisitos de armazenamento, rede, uso de recursos e proxy Web de maneira diferente.

Armazenamento

Considere as informações a seguir ao especificar o armazenamento para os módulos de IoT Edge.

  • O armazenamento para contêineres no Kubernetes é especificado usando montagens de volume.
  • A implantação no Kubernetes não pode ter associações para associar caminhos de host ou armazenamento persistentes.
    • Para armazenamento persistente, use Mounts com o tipo volume.
    • Para caminhos de host, use Mounts com o tipo bind.
  • Para o IoT Edge no Kubernetes, a vinculação por meio de Mounts funciona apenas para o diretório e não para o arquivo.

Exemplo – armazenamento por meio de montagens de volume

Para o IoT Edge no Docker, caminho do host são usadas para mapear os compartilhamentos no dispositivo para caminhos dentro do contêiner. Aqui estão as opções de criação de contêiner usadas em dispositivos FPGA:

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

Para caminhos de host para IoT Edge em kubernetes, um exemplo de uso de Mounts com Type bind é mostrado aqui:

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

Para os dispositivos de GPU que executam o IoT Edge no kubernetes, as montagens de volume são usadas para especificar o armazenamento. Para provisionar o armazenamento usando compartilhamentos, o valor de Mounts.Source seria o nome do compartilhamento SMB ou NFS provisionado em seu dispositivo de GPU. O /home/input é o caminho no qual o volume está acessível dentro do contêiner. Aqui estão as opções de criação de contêiner usadas nos dispositivos de 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"
        }]
    }
}

Rede

Considere as informações a seguir ao especificar a rede para os módulos de IoT Edge.

  • HostPort a especificação é necessária para expor um serviço dentro e fora do cluster.
    • K8sExperimental opções para limitar a exposição do serviço somente ao cluster.
  • A comunicação entre módulos requer HostPort especificação e conexão usando a porta mapeada (e não usando a porta exposta do contêiner).
  • A rede de hosts funciona com dnsPolicy = ClusterFirstWithHostNet o, pois todos os contêineres (especialmente edgeHub ) também não precisam estar na rede host.
  • A adição de mapeamentos de porta para TCP, UDP na mesma solicitação não funciona.

Exemplo - acesso externo a módulos

Para quaisquer módulos IoT Edge que especificam associações de porta, um endereço IP é atribuído usando o intervalo de IP do serviço externo kubernetes que foi especificado na interface do usuário local do dispositivo. Não há nenhuma alteração nas opções de criação de contêiner entre IoT Edge no Docker vs IoT Edge em kubernetes, conforme mostrado no exemplo a seguir.

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

No entanto, para consultar o endereço IP atribuído ao seu módulo, você pode usar o painel do kubernetes, conforme descrito em obter endereço IP para serviços ou módulos.

Como alternativa, você pode se conectar à interface do PowerShell do dispositivo e usar o iotedge comando list para listar todos os módulos em execução em seu dispositivo. A saída do comando também indicará os IPs externos associados ao módulo.

Uso do recurso

Com as configurações de IoT Edge baseadas em kubernetes em dispositivos GPU, os recursos como aceleração de hardware, memória e requisitos de CPU são especificados de forma diferente do que nos dispositivos FPGA.

Uso da aceleração de computação

Para implantar módulos no FPGA, use as opções de criação de contêiner conforme mostrado na seguinte configuração: 

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

Para GPU, use especificações de solicitação de recurso em vez de Vinculações de Dispositivo, conforme mostrado na configuração mínima a seguir. Você solicita recursos nvidia em vez de ao seu, e não precisa especificar o wireserver.

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

Uso de memória e CPU

Para definir a memória e o uso da CPU, use os limites de processador para módulos na seção k8s-experimental. 

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

A especificação de memória e CPU não é necessária, mas geralmente é uma boa prática. Se requests não for especificado, os valores definidos em limites serão usados como o mínimo necessário.

O uso de memória compartilhada para módulos também requer uma maneira diferente. Por exemplo, você pode usar o modo host IPC para acesso compartilhado de memória entre soluções de Análise Dinâmica de Vídeo e inferência, conforme descrito em Implantar Análise Dinâmica de Vídeo no Azure Stack Edge.

Proxy Web

Considere as seguintes informações ao configurar o proxy Web:

Se você tiver um proxy Web configurado na rede, configure as seguintes variáveis de ambiente para a edgeHub implantação em sua configuração de IoT Edge baseada em Docker nos dispositivos FPGA:

  • https_proxy : <proxy URL>
  • UpstreamProtocol : AmqpWs (a menos que o proxy da Web permita o Amqp tráfego)

Para as configurações de IoT Edge kubernetes em dispositivos GPU, você precisará configurar essa variável adicional durante a implantação:

  • no_proxy: localhost

  • IoT Edge proxy na plataforma Kubernetes usa as portas 35000 e 35001. Certifique-se de que seu módulo não seja executado nessas portas ou que ele possa causar conflitos de porta.

Outras diferenças

  • Estratégia de implantação: talvez seja necessário alterar o comportamento de implantação de todas as atualizações do módulo. O comportamento padrão para módulos IoT Edge é atualização contínua. Esse comportamento impede que o módulo atualizado seja reiniciado se o módulo estiver usando recursos como aceleração de hardware ou portas de rede. Esse comportamento pode ter efeitos inesperados, especialmente ao lidar com volumes persistentes na plataforma Kubernetes para os dispositivos GPU. Para substituir esse comportamento padrão, você pode especificar um Recreate na k8s-experimental seção em seu módulo.

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

  • Nomes de módulos: os nomes de módulo devem seguir as convenções de nomenclatura kubernetes. Talvez seja necessário renomear os módulos em execução no IoT Edge com o Docker quando você move esses módulos para IoT Edge com Kubernetes. Para obter mais informações sobre Nomenclatura, consulte kubernetes Naming Conventions.

  • outras opções:

    • Determinadas opções de criação do Docker que funcionaram em dispositivos FPGA não funcionarão no ambiente kubernetes em seus dispositivos de GPU. Por exemplo:, como – EntryPoint.
    • Variáveis de ambiente, como, : precisam ser substituídas por __.
    • O status de criação de contêineres para um pod kubernetes leva ao status de retirada de um módulo no recurso do Hub IOT. Embora haja vários motivos para o Pod estar nesse status, um motivo comum é quando uma imagem de contêiner grande está sendo transferida por uma conexão de largura de banda de rede baixa. Quando o Pod estiver nesse estado, o status do módulo será exibido como retirada no Hub IOT, embora o módulo esteja apenas iniciando.

Próximas etapas