Akri サービス アーキテクチャ

重要

Azure Arc によって有効にされる Azure IoT Operations Preview は、 現在プレビュー段階です。 運用環境ではこのプレビュー ソフトウェアを使わないでください。

一般公開リリースが使用可能になった場合は、新しい Azure IoT Operations インストールを展開する必要があります。プレビューのインストールをアップグレードすることはできません。

ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

この記事は、Akri サービスのアーキテクチャを理解するのに役立ちます。 Akri サービスのコア コンポーネントについて学習すると、それらを使用してデバイスと資産を検出し、Kubernetes クラスターに追加できます。

Akri サービスは、オープンソースの Cloud Native Computing Foundation (CNCF) プロジェクトである Akri の、Microsoft が管理する商用バージョンです。

コア コンポーネント

Akri サービスは、次の 5 つのコンポーネントで構成されています。

  • Akri 構成はカスタム リソースであり、デバイスに名前を付ける場所です。 この構成は、探すデバイスの種類を Akri サービスに指示します。
  • Akri インスタンスは、デバイスの可用性と使用状況を追跡するカスタム リソースです。 各 Akri インスタンスは、リーフ デバイスを表します。
  • Akri 検出ハンドラーは、構成されたデバイスを探し、検出されたデバイスについてエージェントに通知します。
  • Akri エージェントは、Akri インスタンスのカスタム リソースを作成します。
  • Akri コントローラーは、構成されたデバイスを使用するのに役立ちます。 コントローラーは、各 Akri インスタンスを確認し、リソースに接続して使用する方法を認識するブローカー ポッドをデプロイします。

Akri サービス アーキテクチャのダイアグラム。

カスタム リソース定義

カスタム リソース定義 (CRD) は、新しいオブジェクトの種類を定義できる Kubernetes API 拡張機能です。 2 つの Akri サービス CRD があります。

  • 構成
  • インスタンス

Akri 構成 CRD

構成 CRD は Akri サービスを構成します。 検出するリソースと、リソースを検出するノードにデプロイするポッドを記述する構成を作成します。 詳細については、Akri 構成 CRD を参照してください。 CRD スキーマは、次の設定を含め、すべての構成に必要な設定を指定します。

  • リソースを検索するための検出プロトコル。 たとえば、ONVIF や udev などです。
  • このリソースでワークロードをスケジュールできるノードの最大数を定義する spec.capacity
  • 報告されたこれらのリソースのそれぞれをスケジュールするブローカー ポッドを定義する spec.brokerPodSpec
  • 個々のリソースのブローカー ポッドのセットにアクセスするための単一の安定したエンドポイントを提供するサービスを定義する spec.instanceServiceSpec
  • 構成に関連付けられているすべてのリソースのすべてのブローカーのセットにアクセスするための単一の安定したエンドポイントを提供するサービスを定義する spec.configurationServiceSpec

Akri インスタンス CRD

各 Akri インスタンスは、クラスターに表示される個々のリソースを表します。 たとえば、クラスターに 5 台の IP カメラが表示されている場合、インスタンスは 5 つあります。 インスタンス CRD により、Akri サービスの調整とリソースの共有ができるようになります。 これらのインスタンスには内部状態が格納され、ユーザーが編集するためのものではありません。 詳細については、リソース共有の詳細に関するページを参照してください。

エージェント

Akri エージェントは、検出されたリソース用の Kubernetes Device-Plugins を実装します。 Akri エージェントは、次のタスクを実行します。

  • 構成の変更を監視して、検索するリソースを決定します。
  • リソースの可用性を監視して、公開するリソースを決定します。 エッジ環境では、リソースの可用性が頻繁に変化します。
  • リソースの正常性と可用性に対する変更があれば Kubernetes に通知します。

これらのタスクをインスタンスに格納されている状態と組み合わせることで、複数のノードがリソースを共有しながら、spec.capacity 設定によって定義された制限に従うことができます。

詳細については、エージェントの詳細に関するページを参照してください。

検出ハンドラー

検出ハンドラーはデバイスを検索します。 デバイスの例を次に示します。

  • ノードに接続されている USB センサー。
  • ノードに埋め込まれた GPU。
  • ネットワーク上の IP カメラ。

検出ハンドラーは、検出されたすべてのデバイスをエージェントに報告します。 多くの場合、OPC UA などのネットワーク プロトコルか、独自のプロトコルかどうかにかかわらず、デバイスのセットを検出するためのプロトコル実装があります。 検出ハンドラーは、discovery.proto で定義されている DiscoveryHandler サービスを実装します。 検出ハンドラーは、discovery.proto で定義されている Registration サービスをホストするエージェントに登録するために必要です。

詳細については、カスタム検出ハンドラーに関するページを参照してください。

コントローラー

Akri コントローラーの目標は次のとおりです。

  • リソースの可用性を有効にするポッドとサービスを作成または削除する。
  • 任意の時点でインスタンスがクラスターの状態に合わせて調整されていることを確実にする。

これらの目標を達成するために、コントローラーは次のことを行います。

  • インスタンスの変更を監視して、どのポッドとサービスが存在する必要があるかを判断する。
  • 存在しなくなったインスタンスに含まれているノードがないか監視する。

これらのタスクにより、Akri コントローラーは、プロトコル ブローカーと Kubernetes サービスがすべてのノードで実行され、必要なリソースが公開されていることを確認でき、spec.capacity によって定義されている制限に従うことができます。

詳細については、コントローラーの詳細に関するドキュメントを参照してください。