Executar módulos IoT Edge existentes a partir de dispositivos FPGA do Azure Stack Edge Pro no dispositivo GPU do Azure Stack Edge Pro

APLICA-SE A: Azure Stack Edge Pro - GPUAzure Stack Edge Pro R

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

Sobre a implementação do IoT Edge

A implementação do IoT Edge é diferente em dispositivos FPGA do Azure Stack Edge Pro em comparação com dispositivos de GPU do Azure Stack Edge Pro. 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 do IoT Edge é convertido automaticamente para o modelo de aplicativo nativo do Kubernetes. No entanto, algumas alterações ainda podem ser necessárias, pois apenas um pequeno subconjunto do modelo de aplicativo Kubernetes é suportado.

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 eles sejam executados com êxito na plataforma Kubernetes. Talvez seja necessário especificar seus requisitos de armazenamento, rede, uso de recursos e proxy da Web de forma diferente.

Armazenamento

Considere as seguintes informações ao especificar o armazenamento para os módulos do IoT Edge.

• O armazenamento para contêineres no Kubernetes é especificado usando montagens de volume.
• A implantação no Kubernetes não pode ter ligações para associar armazenamento persistente ou caminhos de host.
  • 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, bind through Mounts funciona apenas para diretório, e não para arquivo.

Exemplo - Armazenamento através de montagens de volume

Para o IoT Edge no docker, as associações de 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 no Kubernetes, um exemplo de uso Mounts com tipo bind é mostrado aqui:

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

Para os dispositivos GPU que executam o IoT Edge no Kubernetes, as montagens de volume são usadas para especificar o armazenamento. Para provisionar armazenamento usando compartilhamentos, o valor de seria o nome do compartilhamento SMB ou NFS que foi provisionado Mounts.Source em seu dispositivo 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 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 do IoT Edge.

• HostPort A especificação é necessária para expor um serviço dentro e fora do cluster.
  • K8sOpções experimentais para limitar a exposição do serviço apenas 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 ao contêiner).
• A rede de host funciona com dnsPolicy = ClusterFirstWithHostNet, com isso todos os contêineres (especialmente edgeHub) não precisam estar na rede host também.
• Adicionar mapeamentos de porta para TCP, UDP na mesma solicitação não funciona.

Exemplo - Acesso externo aos módulos

Para todos os módulos do IoT Edge que especificam ligações de porta, um endereço IP é atribuído usando o intervalo de IP do serviço externo do Kubernetes especificado na interface do usuário local do dispositivo. Não há alterações nas opções de criação de contêiner entre IoT Edge no docker vs IoT Edge no 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 no dispositivo. A saída do comando também indicará os IPs externos associados ao módulo.

Utilização de recursos

Com as configurações do 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 dos 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 recursos em vez de Ligações de dispositivo, conforme mostrado na configuração mínima a seguir. Você solicita recursos da nvidia em vez de catapulta, e não precisa especificar o wireserver.

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

Memória e uso da CPU

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

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

A memória e a especificação da CPU não são necessárias, mas geralmente são boas práticas. Se requests não for especificado, os valores definidos em limites são usados como o mínimo necessário.

Usar memória compartilhada para módulos também requer uma maneira diferente. Por exemplo, você pode usar o modo IPC do Host para acesso à memória compartilhada entre as soluções Live Video Analytics e Inference, conforme descrito em Implantar o Live Video Analytics no Azure Stack Edge.

Proxy Web

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

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

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

Para as configurações do IoT Edge baseadas em Kubernetes em dispositivos GPU, você precisará configurar esta variável adicional durante a implantação:

• no_proxy: localhost

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

Outras diferenças

• Estratégia de implantação: talvez seja necessário alterar o comportamento de implantação para quaisquer atualizações no módulo. O comportamento padrão para módulos do IoT Edge é a 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 dispositivos GPU. Para substituir esse comportamento padrão, você pode especificar um Recreate na k8s-experimental seção do módulo.

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

• Nomes de módulos: Os nomes dos módulos devem seguir as convenções de nomenclatura do Kubernetes. Talvez seja necessário renomear os módulos em execução no IoT Edge com Docker ao mover esses módulos para o IoT Edge com Kubernetes. Para obter mais informações sobre nomenclatura, consulte Convenções de nomenclatura do Kubernetes.

• Outras opções:

  • Certas opções de criação do docker que funcionavam em dispositivos FPGA não funcionarão no ambiente Kubernetes em seus dispositivos GPU. Por exemplo: , como – EntryPoint.
  • Variáveis de ambiente, como as que : precisam ser substituídas por __.
  • Contêiner A criação de status para um pod do Kubernetes leva ao status de backoff para um módulo no recurso do Hub IoT. Embora haja uma série de razões para o pod estar nesse status, um motivo comum é quando uma imagem de contêiner grande está sendo puxada por uma conexão de baixa largura de banda de rede. Quando o pod está nesse estado, o status do módulo aparece como backoff no IOT Hub, embora o módulo esteja apenas iniciando.

Próximos passos

• Saiba mais sobre como configurar a GPU para usar um módulo.