エッジのクラスター

計算集約型のアプリケーションには、リソースに制約が多いことを考慮すると、IoTデバイスでは対応できないデータ処理とストレージ用に高いコンピューティング能力が必要です。そのため、企業は、運用チームが必要なストレージ、計算、低遅延、高パフォーマンス、高帯域幅を満たすことができる動的で堅牢な環境として、エッジでクラスターを使用できます。また、可用性の高いオンプレミス共有サービスの中には、エッジクラウドのデプロイメントなど、Kubernetesクラスターが設計した拡張性を必要とする場合があります。

エッジクラスターは、多くの場合、企業の論理的なリソース境界となる可能性があります。ハイエンドのエッジデバイスは、企業にとって投資するには高価です。多数のレガシーの固定機能または専用デバイスがすでにデプロイされ、予算化されている場合があります。エッジ・クラスター・テクノロジーは、エッジネイティブ・アプローチを使用してアプリケーションをモダナイズし、将来性を確保する方法を企業に提供します。これは、このようなデバイスを、デバイス管理またはIoTプラットフォーム・ソリューションを実行する小規模なフットプリント・エッジ・クラスターに接続することで実現されます。その後、エッジ・クラスターはエッジ・デバイスのように管理および運用されます。

エッジのクラスターには、次の主要なメリットがあります。

• スケーラブル： お客様が需要に応じてクラスターに容量を追加できる容易さを提供します。自動スケールに設定できるため、オペレーションチームの時間と労力が削減されます。
• 分散： より多くのデータがエッジ・クラスターで処理および分析されるため、インサイトと行動が迅速化するため、クラウドにデータを送信するための費用と時間を回避できます。
• コンプライアンス： エッジ・クラスターでデータを処理することは、規制コンプライアンスのニーズ、データ・レジデンシー、データ分離にも役立ちます。
• 安全： クラスター上でホストされているすべてのアプリ・サーバー間の安全な通信。
• 高可用性： クラスター上のフェイルバック・オプションと、アプリケーションの継続的なスムーズな動作の必要性に応じて新しいノードを作成する機能によって、信頼性が向上します。

小売の例で見てみましょう。小売業者は、特定の商品を店舗の棚から取り出したり、安全なリコールにより購入できようにしたいと考えています。中央インベントリーを更新し、その更新を複数の店舗にプッシュする必要があります。

このシナリオには、IoT（モノのインターネット）デバイス、カメラ、センサーと組み合わせた店舗内のエッジ・クラスターが適しています。在庫管理システムが特定のSKU（在庫管理単位）に取り出し済みとしてフラグを立てる一方で、店舗マネージャーには物理製品を棚から取り出しているという通知も送られます。同時に、販売時点管理（POS）システムが更新され、その特定製品のバーコードが無効になります。適切に設計されたエッジ・クラスター・ソリューションは、コストのかかる遅延や人的エラーを発生させることなく、このような迅速なアクションを大規模に可能にします。

図1は、セキュリティー・カメラと在庫カメラ、販売時点管理システム（POS）、エントリー・センサー、冷凍庫の温度センサーを備えた一般的なグリッド・レイアウト店舗にデプロイされたエッジ・クラスターを示しています。

別の例として運輸部門を見てみましょうネットワークへの接続が制限されている貨物船は、何百台ものリーファーを運びます。リーファー・コンテナとは、簡単に言えば、肉、野菜、医薬品などの温度に敏感な商品を腐敗させずにコンテナによって移動させるために、コンテナ船によって運ぶ大型冷蔵庫のことです。内容物によって、これらのリーファー内の温度が決まります。

リーファー・コンテナは内部を安定した温度に保つだけでなく、湿度を制御し、十分な気流を促進する必要もあります。サーモスタット、ファンなど、リーファーの重要なコンポーネントの監視と管理は、船舶上の制限された接続シナリオであっても、エッジ・クラスターによって最適に行われます。この構成では、クラウドベースのインフラストラクチャーを必要とせずに、船上での監視とアラートも可能になります。船舶が港に到着すると、エッジ・クラスターは出荷ドックまたはクラウド上のエッジ・ハブと再接続します。人間の介入をほとんど必要とせずに、これらのリーファーやその他のデバイスを大規模に管理することは、適切に設計されたエッジ・クラスター・ソリューションを通じてのみ可能です。

エッジクラスターは、QSR（クイックサービス・レストラン）、列車、救急車、キオスク、店舗、倉庫、生産現場などの限られたスペースで利用可能な棚に収まるほど小さい場合があります。その環境に関連するワークロードをデプロイできます。こうしたものには、ビデオ検知アプリケーション、温度検知アプリケーション、チケット発行アプリケーション、ミッションクリティカル音声サービス、さらにはAR/VRアプリケーションなどが含まれます。

上記のシナリオにおける中程度のKubernetesクラスター・インストールの代表例として、K3を使用した実装方法の詳細を次に示します。MinikubeやMicrok8sなどの同様のKubernetesディストリビューションを使用できることを覚えておいてください。以下のリストは、基本的な1マスター、2ワーカー・ノードK3（https://k3s.io/）クラスターのセットアップを示しています。各コンポーネントで実行するために必要な最小限のコマンドセットが示されています。3ノード・トポロジーは以下の表に示されています。

K3S_URLはマスター・ノードのIPアドレスであり、6443はHTTPSリッスン・ポートです。デフォルトでは、K3sはDockerではなくcontainerdコンテナを使用することに注意してください。

マスター

$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd

ワーカー 1

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"

ワーカー 2

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585

IBM Edge Application Manager (IEAM) の観点から見ると、エッジ クラスターはエッジ デバイスに似ています。どちらにもエッジ エージェントがインストールされているためです。図2は、エッジ・クラスターの高レベルのコンポーネントを示しています。

エッジ・クラスターは、基本的にKubernetesベースのクラスターであるエッジ・ノードです。それでは、小さなクラスターをエッジ・ノードとして設定する理論的根拠は何でしょうか。各エッジ・ノード（この場合はエッジ・クラスター）は、エッジ・クラスターの所有者の組織の下でエクスチェンジに登録されます。登録は、そのエッジ・クラスターにのみ適用される ID とセキュリティー・トークンで構成されます。自律エージェント・プロセスがそのエッジ・クラスター上で実行され、エッジ・クラスターの所有者が設定したポリシーが適用されます。同時に、自律契約チャットボット（またはagbot）には、これらのエッジ・クラスターにサービスをデプロイするためのデプロイメント・ポリシーが割り当てられます。

上記は、 Kubernetes オペレーターを介してエッジ クラスター上にエッジ サービスを展開し、エッジ デバイスで使用されるものと同じ自律展開メカニズムを有効にすることを可能にする IBM Edge Application Manager 製品の手順について説明しています。これは、コンテナ管理プラットフォームとしてのKubernetesのフルパワーがエッジサービスで利用できることを意味します。

製品ナレッジ センターのこのリンクには、エッジ クラスターにエッジ エージェントをインストールする手順が詳しく記載されています。その後、そのエッジ・クラスターに関連するアプリケーションをインストールできます。ご想像のとおり、IEAMはKubernetes、K3s、MiniKube、Microk8s、Red Hat OpenShiftをサポートしています。

このブログでは、クラスターをエッジ（必ずしもディープ・エッジではなく、オンプレミスの遠隔地にあるエッジ・ノード）にデプロイすることで提供される独自のビジネス価値について説明しました。再び繰り返しますが、エッジノードクラスターの機能は、管理ハブクラスターからOCPや他のKubernetesベースのクラスターのリモートインスタンスへのワークロードの管理とデプロイに役立ちます。

エッジ・クラスターを使用すると、オペレーションと同じ場所にコンピューティングを配置する必要があるか、またはエッジ・デバイスでサポートできるものよりも多くの拡張性、可用性、機能を必要とするエッジでのユースケースが可能になります。さらに、エッジ・クラスターがエッジ・デバイスに近いため、エッジ・デバイスで実行されるサービスをサポートするために必要なアプリケーション・サービスを提供することは珍しいことではありません。

Open Container Initiative（OCI）コンテナを開発、管理、実行するための、新しいオープンソースのコンテナ管理ツールがあります。Podman（ポッド・マネージャーの略）と呼ばれるこれは、エッジクラスターに適したオプションです。PodmanはLibodライブラリーの一部として提供されており、コンテナの作成と保守に使用できます。Dockerコンテナを実行できますが、現時点ではLinuxベースのオペレーティング・システムでのみ実行されています。Podman の詳細については、こちら。

IBM Cloud Architecture Centerは、多数のハイブリッドおよびマルチクラウドのリファレンス・アーキテクチャーを提供しています。

新しく公開されたエッジ関連の自動車リファレンス アーキテクチャもご覧いただけます。

記事をレビューしてくださったJoe Pearson氏とDavid Booz氏に感謝します。

エッジコンピューティングに関するこのブログ記事の他の記事をご覧ください。

• パート3：「エッジでのアーキテクチャ」
• パート4：「エッジでのDevOps 」
• パート7：「エッジにおけるセキュリティ」
• パート8：「エッジでの分析」
• 第9回：「エッジにおける5G 」
• パート10：「エッジのクラスター」
• パート11：「エッジでの自動化」
• パート12：「エッジでのネットワークスライシング」
• パート13：「エッジのデータ」
• パート14：「エッジにおけるアーキテクチャ上の決定」
• パート15：「エッジでのGitOps 」
• パート17：「エッジにおけるストレージサービス」
• 第18回：「エッジにおけるクラウド・サービス」
• 第20回：「エッジにおけるデータ主権」
• 第22回：「エッジでつながる製品」
• パート23：「エッジにおける基礎モデル」

• IBM Garage
  
• IBM Edge Application Manager
  

• K3s のインストール
• K3s ドキュメンテーション
• クラスターへのIEAMエージェントのインストール
• リーファー・コンテナとは
• DockerからPodmanへの移行
• Linux Foundationのオープン・コンテナ・イニシアチブ