如何在 akri 中向 brokerpod 提供附加信息，或根据 udev 规则启动不同的 brokerpod

为了实现在 Akri 中启动不同的自定义 brokerpod 的目标，具体取决于 udev 规则，并将其他信息传递给这些 brokerpod，您需要修改 Helm chart 配置。
关键是在 Akri 中正确设置 udev 配置，以根据 udev 规则匹配特定设备，并相应地自定义 brokerPod 配置。

+---------------------------------------------------------------+
|                          Kubernetes Cluster                   |
|                                                               |
|   +-------------------+           +----------------------+    |
|   |  Akri Controller  |<----------|     Broker Pods      |    |
|   +-------------------+           +----------------------+    |
|              |                              |                 |
|              |    Discovers Devices         |                 |
|              |    Matching udev Rules  /----+----\            |
|              |                         |         |            |
|   +-------------------+      +-----------+     +------------+ |
|   |   udev Discovery  |----->| Broker A  |     | Broker B   | |
|   |    Configuration  |      +-----------+     +------------+ |
|   +-------------------+             |                |        |
|              |                      |                |        |
|              |    Matches Devices   |                |        |
|              |    Based on Rules    |                |        |
|   +-------------------+             |                |        |
|   |   udev Rule 1     |-------------+                |        |
|   |   udev Rule 2     |------------------------------+        |
|   +-------------------+                                       |
+---------------------------------------------------------------+

首先，定义多个 udev 配置，每个配置都根据 udev 规则面向一组特定的设备。每个配置都应该指定一个不同的 brokerPod，以便在发现与其 udev 规则匹配的设备时部署。

然后，为每个 udev 规则自定义 brokerpod：对于每个 udev 配置，指定不同的 brokerPod 镜像或配置。这样可以确保根据不同的 brokerpod 对应的设备启动它们。

要将其他信息传递给 brokerpod，例如哪个 udev 规则触发了它的启动，您可以使用环境变量或 Kubernetes 和 Akri 支持的其他配置方法。

首先，定义多个 udev 配置，每个配置都根据 udev 规则面向一组特定的设备。每个配置都应该指定一个不同的 brokerPod，以便在发现与其 udev 规则匹配的设备时部署。

然后，为每个 udev 规则自定义 brokerpod：对于每个 udev 配置，指定不同的 brokerPod 镜像或配置。这样可以确保根据不同的 brokerpod 对应的设备启动它们。

要将其他信息传递给 brokerpod，例如哪个 udev 规则触发了它的启动，您可以使用环境变量或 Kubernetes 和 Akri 支持的其他配置方法。

需要调整 Helm 图表以反映这些多种配置。这可能如下所示（为说明而简化）：

udev:
    discovery:
    enabled: true
    configuration:
    - name: akri-udev-rule1
        discoveryDetails:
        udevRules: ['ATTR{product}=="AAAA"']
        brokerPod:
        image:
            repository: custom-image-for-rule1
    - name: akri-udev-rule2
        discoveryDetails:
        udevRules: ['ATTR{product}=="BBBB"']
        brokerPod:
        image:
            repository: custom-image-for-rule2

将此修改后的 Helm 图表部署到 Kubernetes 集群。然后，Akri 将根据它发现的与指定 udev 规则匹配的设备部署不同的 brokerpod。

如果 brokerpod 未按预期运行，请检查 Akri 控制器和 brokerpod 的日志中是否有任何错误消息。(, ,kubectl get podskubectl logs <broker-pod-name>kubectl describe pod <broker-pod-name>)

现在更重要的部分是甚至给出环境变量，而不是它甚至可以是同一个 brokerpod。在那里，我仍然不确定如何将某些内容从 udev 规则传递到 pod。

将特定信息从 udev 规则传递到 Akri 中的代理 pod 将涉及两个步骤：首先，捕获 udev 规则中的必要信息，其次，通常通过环境变量将此信息传输到代理 pod。

要捕获 udev 规则中的信息，请使用 udev 规则语法将设备属性匹配并分配给环境变量。
捕获值的 anudev 规则示例：ATTR{product}

ACTION=="add", ATTR{product}=="AAAA", ENV{MY_UDEV_ENV}="$attr{product}"

然后使用 Akri 的配置将捕获的信息从 udev 规则传递到代理 pod。这通常是通过在代理 pod 的环境变量配置中引用 udev 规则中设置的环境变量来完成的。 然而，Akri 似乎并不直接支持将自定义环境变量从 udev 规则动态传递到代理 pod。Akri 的代理 pod 环境变量通常是预定义的，并且在 Helm 图表中是静态的。

一种可能的解决方法是使用自定义代理 pod，该 pod 可以根据已知的静态环境变量（如设备 ID 或节点名称）向节点或 Akri 控制器查询特定设备信息。
例如，您的代理 Pod 可能是一个脚本或应用程序，它首先读取静态环境变量以获取设备 ID 或节点名称，然后执行查询或查找以查找该设备的相应 udev 信息。

在代理 Pod 配置中设置静态环境变量的简化示例如下： 然后，您的自定义代理 Pod 逻辑将用于执行进一步的操作或查询以获取动态信息。yaml udev: configuration: - name: akri-udev-rule1 brokerPod: env: - name: STATIC_ENV value: "SomeStaticValue" STATIC_ENV

+-----------------------------------------------------------+
|                      Kubernetes Cluster                   |
|                                                           |
|  +-------------------+        +----------------------+    |
|  |  Akri Controller  |        |     Broker Pods      |    |
|  +-------------------+        +----------------------+    |
|           |                              ^                |
|           |    Discovers Devices         |                |
|           |    Matching udev Rules       |                |
|           |                              |                |
|  +----------------------+                |                |
|  |   udev Discovery     |----------------|                |
|  |    Configuration     |                |                |
|  +----------------------+                |                |
|           |                              |                |
|           |    Matches Devices           |                |
|           |    Based on Rules            |                |
|  +----------------------+                |                |
|  |    udev Rule with    |----------------+                |
|  |  Captured Information|                                 |
|  +----------------------+                                 |
|           |                                               |
|           |    Environment Variable (Static)              |
|           |                                               |
|  +----------------------+                                 |
|  |   Custom Broker Pod  |                                 |
|  |      Logic (Script/  |                                 |
|  |     Application)     |                                 |
|  +----------------------+                                 |
|           ^                                               |
|           | Queries for Additional Info                   |
|           | Based on Static Env Variable                  |
+-----------------------------------------------------------+

开发一个自定义代理 Pod 应用程序/脚本，该应用程序/脚本使用静态环境变量来派生或获取其他详细信息。
这可能涉及查询本地系统、Kubernetes API 或其他机制，以将静态信息与 udev 规则捕获的动态详细信息相关联。

这种方法需要在代理 pod 端进行自定义开发工作，因为到目前为止，将任意 udev 规则派生的信息动态传递到代理 pod 并不是一个原生功能。关键在于代理 pod 中的自定义逻辑，该逻辑可以解释或使用静态环境变量来发现与其关联的设备的更多动态详细信息。

在 Akri 中实现使用静态环境变量检索其他设备信息的自定义代理 Pod 涉及在代理 Pod 中创建自定义应用程序或脚本。该自定义逻辑负责使用静态环境变量来派生或获取与设备相关的动态信息。

使用 Python 脚本作为示例的概念实现将是自定义代理 Pod 容器映像的脚本部分：

broker_logic.py:

import os
import some_device_query_library  # Hypothetical library to query device info

def get_dynamic_device_info(static_env_var):
    # Logic to use static environment variable to find dynamic device information
    # That could involve querying the local system, Kubernetes API, etc.
    # For example, using a static device ID to find more details about the device
    device_id = static_env_var
    device_info = some_device_query_library.query_device_info(device_id)
    return device_info

if __name__ == "__main__":
    # Retrieve the static environment variable
    static_env_var = os.getenv('STATIC_ENV', 'default_value')

    # Get dynamic device information
    dynamic_info = get_dynamic_device_info(static_env_var)
    
    # Implement your logic here using the dynamic device information
    print(f"Dynamic Device Info: {dynamic_info}")

自定义代理 Pod 的 Dockerfile：

FROM python:3.8-slim

# Copy the Python script into the container
COPY broker_logic.py /broker_logic.py

# Set the command to run the script
CMD ["python", "/broker_logic.py"]

生成 Docker 映像并将其推送到容器注册表。

docker build -t my-custom-broker-image .
docker push my-custom-broker-image

然后在 akri 配置中引用自定义代理映像：

udev:
    configuration:
    - name: akri-udev-rule1
        brokerPod:
        image:
            repository: my-custom-broker-image
            tag: latest
        env:
            - name: STATIC_ENV
            value: "SomeStaticValue"

这假设自定义代理 Pod 可以通过某种方式（如查询 Kubernetes API、本地系统查询等）基于静态环境变量检索其他信息。
实际实现细节将根据设备信息的公开方式以及它如何与环境变量中可用的静态信息相关联而有所不同。