Red Hat Device Edge、Red Hat build of MicroShift 4.16の新機能によってチームのエッジ拡張をサポート

Red Hat Device Edgeは、リソースに制約のある現場に配置されたデバイスのワークロードへのニーズに応えるプラットフォームです。最も小規模かつ遠隔の場所向けに設計されたRed Hat Device Edgeは、Red Hat Enterprise Linux、Ansible Automation Platform、そしてRed HatのMicroShiftビルドを組み合わせたものです。

MicroShiftは、小規模でリソースに制約のあるエッジデバイス向けに最適化されたKubernetes ディストリビューションであり、データセンター内から最も遠いエッジに至るまでのオーケストレーションを実現します。MicroShift 4.16には、大規模なエッジデバイスのフリート運用を容易にする、いくつかの新たな利便性向上機能が搭載されています。また、複数のネットワークに接続する機能や、GitOps による新しいアプリケーションライフサイクル管理などを提供するとともに、長期サポートバージョンに簡単に直接更新できます。MicroShift 4.16 は、さまざまなエッジロケーション向けの一貫したツールとプロセスによって、チームの拡張を引き続きサポートします。

最も興味深い機能のいくつかを見てみましょう。

RHEL 9.4 および EUS から EUS に直接更新

まず、基盤となるオペレーティングシステムと、考えられる更新のパスから始めましょう。Red Hat Enterprise Linux （RHEL） 9.4上のMicroShift 4.16は、Extended Update Support（EUS） リリースです。これは、以前のリリースでサポートされていたRHEL 9.2および9.3から切り替えたものです。オペレーティングシステムの変更点については、RHEL 9.4のリリースノートをお読みください。

EUS から EUS への直接更新がサポートされているため、1 回の再起動で 4.14 から 4.16 に直接更新できます。4.15をスキップすることで、2回ではなく1回の再起動で済むため、エッジ展開のダウンタイムを最小限に抑えることができます。OSTree ベースのシステムでは、ロールバックも完全にサポートされています。Greenbootのヘルスチェックで異常なシステムが検出された場合、自動的に以前のイメージ（4.14に戻る）にロールバックします。

MicroShift の偶数バージョンは EUS リリースです。EUS において、Red Hatはクリティカルかつ重要な影響のあるセキュリティアップデートと、緊急優先のバグ修正のバックポートを提供します。正確な日付と詳細については、製品ライフサイクルのページを参照してください。

Multus を使用して複数のネットワークにポッドをアタッチする

MicroShift Multusプラグインでは、複数のネットワークの使用がサポートされるようになりました。高度なネットワーク要件である場合は、ポッドに追加のネットワークをアタッチできます。一般的な使用例としては、産業用制御システムやセンサーネットワークの運用ネットワークに接続する必要があるポッドがあります。

オプションのMultusプラグインは、新規インストールの場合は初日にインストールすることができますし、2 日目以降にインストールすることもできます。デプロイメントまたはイメージビルドに RPMパッケージmicroshift-multusを追加するだけです。

MicroShift Multus RPM パッケージをインストールした後、Bridge、MACVLAN、または IPVLANプラグインを使用して、NetworkAttachmentDefinition APIで追加のネットワークを作成できます。

これは、IPv6 への中間パスとしても有効です。MicroShift 自体は現在 IPv6 をサポートしていませんが、IPv6 の完全サポートが近い将来のロードマップに含まれています。それまでは、ブリッジネットワークプラグインを使用して、ポッドを IPv6 アドレスの NIC に接続できます。

キャプション： MicroShiftによる複数のネットワーク

MicroShiftで拡大するGitOps（技術プレビュー）  

OpenShift GitOpsチームとの緊密なコラボレーションによって、MicroShiftは現在、オプションのインストールとして実行される小型で軽量なGitOpsエージェントをサポートするようになりました。これにより、エッジデプロイメントの大規模なアプリケーションライフサイクル管理を、一貫して実行できるようになります。

従来の集中型コンピューティングと比較すると、多数のエッジデバイスを管理するのは困難な場合があります。さまざまな場所、接続性の問題、対応するスタッフ、アーキテクチャの違いに対処する必要があるからです。複雑なデプロイメントを使用するマイクロサービスベースのアプリケーションにおいては、さらに管理が複雑になる可能性があります。しかし、どれほど困難であっても、あらゆるエッジデバイスのすべてのデプロイメントを、同一の一貫したバージョンで行うことが極めて重要です。

近年では、このような課題に対する最も一般的なソリューションとして、GitOpsベースのアプローチが発展してきました。このアプローチでは、Gitリポジトリがターゲットの設定をホストします。このリポジトリは、既存のGitワークフローを使用して変更されます（例えば、プルリクエストはレビュー後に、承認されます）。データセンターのデプロイメントでは、保留中のGitリポジトリーの設定とクラスタ内の実際の設定を調整する中央コントローラーが、通常1つあります。違いが見つかれば報告するか、クラスターに同期して修正します。これは、中央のGitOpsコントローラーがAPI エンドポイントを使って管理対象のクラスターに設定の変更をプッシュするため、プッシュ型のアプローチと呼ばれています。Argo CDは、そのようなGitOpsコントローラーを提供する有名なオープンソースプロジェクトです。

ただし、エッジのデプロイメントにおいては、いくつかの欠点があります。多くの場合、エッジデバイスはファイアウォールの背後にあるため、コアシステムからAPIエンドポイントに接続できません。接続可能な状態でしか調整が機能しないため、オフライン中は人間が行ったローカルの変更が検出されず、修正されません。

これらの課題は、プルベースのアプローチによって解決できます。このモデルでは、エンドポイントが保留中のアップデートに接続します。それぞれのエッジデバイスには独自のローカルGitOpsコントローラーが付与され、ローカルのクラスタAPIとリモートのGitリポジトリを調整します。保留中の設定は、接続が可能になるとGitからプルされ、ローカルにキャッシュされます。そして、APIサーバーとの調整は、接続されていない状態でも行うことができます。また、エッジデバイスから中央のGitリポジトリへの接続が開始されるため、この方法はファイアウォールに適しています。

この方法において重要な考慮事項となるのは、エッジデバイス上で実行されるGitOpsコントローラーです。追加リソースを消費するため、小型で軽量なコントローラーを用意することが重要になります。そして、まさにそれこそが、MicroShiftで現在利用できるものなのです。MicroShift で小型で軽量な Argo CDをデプロイするには、microshift-gitops RPMパッケージを追加します。

キャプション： GitOpsのプロセス

カスタムAPIサーバー証明書

デフォルトのAPIサーバー証明書は、内部のMicroShiftクラスター認証局 （CA） が発行します。クラスター外部のクライアントは、APIサーバー証明書を簡単に検証できません。このことは、APIを公開する必要がある場合に課題となりますが、自己署名証明書はセキュリティ要件によって許可されていません。

APIサーバー証明書は、クライアントが信頼するカスタムCAによって外部的に発行されたカスタムサーバー証明書に置き換えることができます。別の名前で複数の証明書を発行することも可能です。設定方法の詳細については、こちらのドキュメントを参照してください。

Ingressルーターの制御

以前のバージョンでは、Ingressルーターは常にオンになっており、ポート80と443で利用できるすべてのIPをリッスンしていました。これは、Ingressトラフィックが特定のネットワーク上でのみ発生する可能性がある、マルチホームのエッジデバイスにおいて問題になる可能性があります。また、攻撃対象領域を最小限に抑えるという、セキュリティのベストプラクティスとも合致していません。

MicroShift 4.16以降、管理者は次のことが可能になります。

1. ルーターを無効にできます。MicroShift が送信のみに使用されるケースもあります。例えば、ポッドが下位の現場システムと上位のクラウドシステムにのみ接続している産業用 IoT ソリューションでは、受信サービスがまったくありません。これにより、攻撃対象領域が最小化され、ルーターポッドが起動されないため、リソースの消費を抑えることができます。
2. ルーターがリッスンするポートを設定できます。
3. ルーターがリッスンするIPアドレスとネットワークインターフェースを設定できます。ルーターが現場の内部ネットワークにのみ接続可能であり、上位の公共ネットワークには接続できない（またはその逆、またはその両方の）産業空間のユースケースがあります。

設定可能な監査ログ

以前は、MicroShiftの監査ログ機能（すべてのAPI呼び出しをログに記録）は、ハードコードされた監査ログポリシーと設定を使用していました。4.16以降は、監査ログをより詳細に設定できるようになったため、組織の監査ログルールに準拠するのに役立ちます。

設定値を使用して監査ログファイルのローテーションと保持を制御すると、ファーエッジデバイスのストレージ容量の限界を超えないようにすることができます。このようなデバイスでは、ログデータの蓄積によってホストシステムまたはクラスタのワークロードが制限され、デバイスが動作しなくなる可能性があります。そのため、監査ログポリシーを設定することで、重要な処理領域を継続的に利用できるようにすることができます。

監査ログを制限するために設定した値によって、監査ログのバックアップのサイズ、数、および経過時間の制限を適用することができます。フィールド値は、優先順位を付けずに互いに独立して処理されます。

例えば以下の方法によって、フィールドを組み合わせて設定することで、保持されるログの最大ストレージ制限を定義できます。

• maxFileSizeとmaxFilesの両方で、ログストレージの上限を設定します。
• maxFileAge値を設定すると、maxFiles値に関係なく、ファイル名のタイムスタンプより古いファイルが自動的に削除されます。

さらに、監査プロファイルを設定して、監査ログに書き込まれる詳細レベルを制御することもできます。

MicroShift の進化

この記事では、MicroShiftの多くの機能の概要のみをご紹介しました。MicroShift 4.16の新機能の完全なリストについては、リリースノートを参照してください。また、詳細についてはドキュメントをお読みください。