Запуск существующих модулей IoT Edge с устройств FPGA Azure Stack Edge Pro на устройстве GPU Azure Stack Edge Pro

Статья
04/18/2023

ОБЛАСТЬ ПРИМЕНЕНИЯ: Да для SKU GPU Pro Azure Stack Edge Pro — GPU Да для SKU R Pro Azure Stack Edge Pro R

Примечание.

Настоятельно рекомендуется развернуть последнюю версию IoT Edge на виртуальной машине Linux. Управляемый IoT Edge в Azure Stack Edge использует старую версию среды выполнения IoT Edge, которая не имеет последних функций и исправлений. Инструкции см. в статье о развертывании виртуальной машины Ubuntu. Дополнительные сведения о других поддерживаемых дистрибутивах Linux, которые могут запускать IoT Edge, см. в поддерживаемых системах Azure IoT Edge — обработчиках контейнеров.

В этой статье подробно описаны изменения, необходимые для модуля IoT Edge на основе Docker, который работает на FPGA Azure Stack Edge Pro, для того чтобы он мог работать на платформе IoT Edge на основе Kubernetes на устройстве GPU Azure Stack Edge Pro.

О реализации IoT Edge

Реализация IoT Edge различается на устройствах FPGA Azure Stack Edge Pro и на устройствах GPU Azure Stack Edge Pro. Для устройств GPU в качестве платформы размещения для IoT Edge используется Kubernetes. Для IoT Edge на устройствах FPGA используется платформа на основе Docker. Модель приложений для IoT Edge на основе Docker автоматически преобразуется в собственную модель приложения Kubernetes. Однако некоторые изменения все же могут потребоваться, так как поддерживается только небольшое подмножество модели приложения Kubernetes.

При переносе рабочих нагрузок с устройства FPGA на устройство GPU необходимо внести изменения в существующие модули IoT Edge, чтобы они успешно выполнялись на платформе Kubernetes. Возможно, потребуется по-разному указать требования к хранилищу, сети, использованию ресурсов и веб-прокси.

Хранилище

При указании хранилища для модулей IoT Edge учитывайте следующие сведения.

Хранилище для контейнеров в Kubernetes указывается с помощью подключений томов.
Развертывание в Kubernetes не может иметь привязок для связывания постоянного хранилища или путей к узлам.
- Для постоянного хранилища используйте Mounts с типом volume.
- Для путей к узлам используйте Mounts с типом bind.
Для IoT Edge в Kubernetes привязка с помощью Mounts работает только для каталога, но не для файла.

Пример. Хранилище посредством подключений томов

Для IoT Edge на Docker общие папки на устройстве сопоставляются с путями внутри контейнера с помощью привязок путей к узлам. Ниже приведены параметры создания контейнера, используемые на устройствах FPGA.

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

Для путей к узлам IoT Edge на Kubernetes пример использования Mounts с типом bind показан здесь:

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

Для устройств GPU, работающих с IoT Edge на Kubernetes, для указания хранилища используются подключения томов. Для подготовки хранилища с использованием общих папок значением Mounts.Source будет имя общего ресурса SMB или NFS, подготовленного на устройстве GPU. /home/input— путь, по которому том доступен в пределах контейнера. Ниже приведены параметры создания контейнера, используемые на устройствах 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"
        }]
    }
}

Network

При указании сетевого подключения для модулей IoT Edge учитывайте следующие сведения.

Необходима спецификация HostPort для предоставления службы как внутри кластера, так и за его пределами.
- Параметры K8sExperimental позволяют ограничить прелоставление службы только кластером.
Для взаимодействия между модулями требуется спецификация HostPort и подключение с помощью сопоставленного порта (а не с использованием порта, предоставленного контейнером).
Сетевое подключение узла работает с dnsPolicy = ClusterFirstWithHostNet, и все контейнеры (особенно edgeHub) не обязательно должны находиться в сети узла.
Добавление сопоставлений портов для TCP и UDP в одном и том же запросе не работает.

Пример. Внешний доступ к модулям

Для любых модулей IoT Edge, которые задают привязки портов, IP-адрес назначается с помощью диапазона IP-адресов внешней службы Kubernetes, указанного в локальном пользовательском интерфейсе устройства. В параметрах создания контейнера между IoT Edge на Docker и IoT Edge на Kubernetes нет изменений, как показано в следующем примере.

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

Однако для запроса IP-адреса, назначенного вашему модулю, можно использовать панель мониторинга Kubernetes, как описано в статье Получение IP-адреса для служб или модулей.

Кроме того, можно подключиться к интерфейсу PowerShell устройства и использовать команду iotedge list для вывода списка всех модулей, выполняющихся на устройстве. Выходные данные команды также будут показывать внешние IP-адреса, связанные с модулем.

Использование ресурсов

При настройке IoT Edge на основе Kubernetes на устройствах GPU ресурсы, такие как аппаратное ускорение, память и требования к ЦП, указываются иначе, нежели на устройствах FPGA.

Использование ускорения вычислений

Чтобы развернуть модули в FPGA, используйте параметры создания контейнера, как показано в следующей конфигурации:

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

Для GPU используйте спецификации запросов ресурсов вместо привязок устройств, как показано в следующей минимальной конфигурации. При этом запрашиваются ресурсы nvidia вместо catapult, и не нужно указывать wireserver.

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

Использование памяти и ЦП

Чтобы задать использование памяти и ЦП, используйте ограничения процессора для модулей в разделе k8s-experimental.

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

Спецификация памяти и ЦП не обязательна, но обычно рекомендуется. Если параметр requests не указан, то значения, заданные в ограничениях, используются в качестве минимально необходимых.

Использование общей памяти для модулей также требует другого способа. Например, можно использовать режим IPC узла для доступа к общей памяти между Аналитикой видеотрансляций и решениями для вывода, как описано в статье Развертывание Аналитики видеотрансляций на Azure Stack Edge.

Веб-прокси

При настройке веб-прокси учитывайте следующие сведения.

Если в вашей сети настроен веб-прокси, настройте следующие переменные среды для развертывания edgeHub в системе IoT Edge на основе Docker на устройствах FPGA:

https_proxy : <proxy URL>
UpstreamProtocol : AmqpWs (если веб-прокси не разрешает трафик Amqp)

Для систем IoT Edge на основе Kubernetes на устройствах GPU во время развертывания необходимо настроить следующую дополнительную переменную:

no_proxy: localhost
Прокси-сервер IoT Edge на платформе Kubernetes использует порты 35000 и 35001. Убедитесь, что модуль не выполняется на этих портах, в противном случае возможны конфликты портов.

Другие различия

Стратегия развертывания. Может потребоваться изменить поведение развертывания для любых обновлений модуля. Поведение по умолчанию для модулей IoT Edge — последовательное обновление. Такое поведение предотвращает перезапуск обновленного модуля, если модуль использует такие ресурсы, как аппаратное ускорение или сетевые порты. Такое поведение может привести к непредвиденным последствиям, особенно при работе с постоянными томами на платформе Kubernetes для устройств GPU. Чтобы переопределить это поведение по умолчанию, можно указать Recreate в разделе k8s-experimental модуля.
```
{
  "k8s-experimental": {
    "strategy": {
      "type": "Recreate"
    }
  }
}
```
Имена модулей. Имена модулей должны соответствовать соглашениям об именовании Kubernetes. Модули, выполняемые на IoT Edge с использованием Docker, при перемещении на IoT Edge с использованием Kubernetes может потребоваться переименовать. Дополнительные сведения об именовании см. в статье Соглашения об именовании Kubernetes.
Другие параметры.
- Некоторые параметры создания Docker, которые работали на устройствах FPGA, не будут работать в среде Kubernetes на устройствах GPU. Например, например— EntryPoint.
- Переменные среды, такие как :, необходимо заменить на __.
- Состояние создания контейнера для модуля Kubernetes pod приводит к состоянию задержки (backoff) для модуля на ресурсе Центра Интернета вещей. Существует ряд причин, по которым модуль Pod может находиться в этом состоянии, однако обычно дело в том, что большой образ контейнера передается через медленное подключение с низкой пропускной способностью сети. Когда модуль Pod находится в этом состоянии, состояние модуля отображается как задержка в Центре Интернета вещей, хотя модуль всего лишь запускается.

Следующие шаги

Дополнительные сведения о настройке GPU для использования модуля.

Поделиться через