MicroShift 上の Secure Gateway
Secure Gateway を Red Hat Device Edge にデプロイし、ゲートウェイとその暗号化キャッシュを Roboflow Deployment Manager が管理する MicroShift ワークロードとして実行します。
Secure Gateway MicroShift（Red Hat のエッジデバイス向け Kubernetes ディストリビューション）を使用する Red Hat Device Edge でも動作します。専用のインストーラーが、Roboflow Deployment Manager（rfdm) が RHEL ホスト上で実行されます。Docker デプロイメントと同じゲートウェイ（Roboflow API をプロキシし、あなたのフリート向けにモデルの重みとコンテナーイメージをキャッシュする、制御された単一の送信ポイント）が、Red Hat Device Edge を標準化したホスト向けにパッケージされています。
アーキテクチャ
Roboflow Deployment Manager は systemd サービスとして RHEL ホスト上で実行され、MicroShift の Kubernetes API を通じてワークロードを管理します。ゲートウェイの設定、更新、稼働を維持します。
ゲートウェイとそのキャッシュバックエンド（保存時暗号化対応の S3 互換ストア SeaweedFS）は、次の Namespace で Deployment として実行されます:
roboflow-edgeNamespace。1 つの
LoadBalancerService がデバイス IP でゲートウェイを公開します。ポート443で HTTPS、そしてポート80.キャッシュは、MicroShift の LVMS ストレージプロビジョナーによって提供される永続ボリュームに保存されます。ボリューム要求は 60 GB で、ゲートウェイの 50 GB キャッシュに余裕分を加えたサイズです。
すべてのワークロードは、MicroShift の既定の制限付きセキュリティプロファイル下で非特権で実行されます。特権コンテナー、root ユーザー、カスタムのセキュリティコンテキスト権限はありません。
これはシングルノードのデプロイメントです。高可用性およびマルチノードクラスターはサポートされていません。
前提条件
有効な Red Hat サブスクリプションを持つ、x86_64 上の Red Hat Enterprise Linux 9.6 ホスト。インストーラーバンドルは
linux-amd64専用です。Red Hat build of MicroShift 4.16 以降がインストールされ、OpenShift pull secret が設定された状態で実行されていること。4.20（EUS）を推奨します。次を参照してください: サポートマトリクス.
少なくとも 60 GB の空きがある LVM ボリュームグループ。MicroShift の LVMS プロビジョナーがそこからゲートウェイのキャッシュボリュームを作成します。ボリュームグループがない、または空き容量が少なすぎる場合、ストレージ要求は
保留中のままで、キャッシュは開始されません。skopeoがホストにインストールされていること（sudo dnf install skopeo）。インストーラーはこれを使って付属のイメージを CRI-O のストレージにコピーし、存在しない場合は停止します。OpenShift CLI（
oc）がホストにインストールされており、そのバージョンが MicroShift リリースと一致していること。MicroShift はこれをインストールせず、このページの確認およびトラブルシューティングコマンドで使用します。sudo のsecure_path(/usr/binが使える場所にインストールしてください):sudoから外します/usr/local/binからPATHを外すため、ocそこに展開するとsudo: oc: command not found.ポート
80と443デバイス IP 上でゲートウェイが利用可能になります接続されたインストールでは、外向き HTTPS は
api.roboflow.comとrepo.roboflow.com
firewalld が実行中の場合（標準の RHEL インストールでは実行されています）、インストール前にゲートウェイのポートを開放し、MicroShift の Pod ネットワークを trusted ゾーンに入れてください。これを行わないと、Pod ネットワークとクライアントアクセスの両方が失敗します:
firewalld の再読み込みにより、OVN Pod が再起動するまで MicroShift の Pod ネットワークが壊れたままになります。そのため、再読み込みの後に次の回復手順を実行してください: トラブルシューティング.
インストーラーは、ゲートウェイがデバイス上のポート 80 と 443 を占有できるように、MicroShift の既定の ingress router を無効化します。このホストですでに router 経由で他のワークロードを提供している場合、このデプロイメントモデルはそれらと競合します。ゲートウェイには専用デバイスを使用してください。
接続済みホストにインストールする
MicroShift インストーラーバンドルをダウンロードし、整合性を検証します:
展開して、root でインストーラーを実行します:
インストーラーは次を行います:
MicroShift が実行中でサポート対象バージョンであること、およびストレージ用の LVM ボリュームグループが利用可能であることを確認します。
付属の Secure Gateway と SeaweedFS のイメージをホストのコンテナーストレージに読み込みます。レジストリからは何も取得しません。
CRI-O の設定でイメージを固定し、Kubernetes のディスク圧迫ガベージコレクションがそれらを削除しないようにします。
MicroShift の既定の ingress router を無効化して MicroShift を再起動し、ポート 80 と 443 をゲートウェイ用に解放します。
Roboflow Deployment Manager を systemd サービスとしてインストールし、デバイス設定を書き込みます。
Deployment Manager を起動し、次を作成します:
roboflow-edgeNamespace とゲートウェイおよびキャッシュをデプロイします。
デプロイを検証します:
両方の Pod は Runningであるべきで、ヘルスチェックは HTTP 200 を返すはずです。 -k フラグは、ゲートウェイの証明書を信頼するまで必要です。以下を参照してください。 TLS と信頼.
エアギャップ環境にインストールする
同じバンドルは、インターネットアクセスのないホストにもインストールできます。コンテナーイメージは OCI アーカイブとして同梱され、ホストのコンテナーストレージに直接読み込まれます。ワークロードは正確なバージョンタグを参照するため、インストール時もその後も、レジストリから何かが取得されることはありません。
接続されたマシンでバンドルをダウンロードして検証し、リムーバブルメディアまたは社内のファイル転送手順でデバイスに転送してから、展開して次を実行します install-microshift.sh を上記とまったく同じように実行します。検証も同じです。
TLS と信頼
既定では、Roboflow Deployment Manager はゲートウェイ用の自己署名証明書を生成し、次の場所に保存します: secure-gateway-tls Secret（type kubernetes.io/tls）の roboflow-edge Namespace にあります。ゲートウェイ Pod はこの Secret をマウントし、ポート 443 で HTTPS を提供します。証明書は Deployment Manager の再インストール後も保持されます。Deployment Manager は、証明書が存在しない場合、有効期限まで 30 日以内になった場合、証明書と秘密鍵が一致しなくなった場合、または新規発行の証明書が含むべきすべての名前をカバーしなくなった場合に、それを置き換えます。
独自の証明書はそれらすべての名前をカバーしている必要があります。そうでない場合、Deployment Manager は次回の reconcile で自己署名の証明書に置き換えます:
repo.roboflow.com,*.roboflow.com、およびlocalhost。クライアントは次の名前でゲートウェイにアクセスします:repo.roboflow.comため、証明書がそれをカバーしていない場合、コンテナーイメージの取得は失敗します。secure-gateway,secure-gateway.roboflow-edge.svc、およびsecure-gateway.roboflow-edge.svc.cluster.localデバイスのホスト名
IP アドレス
127.0.0.1およびデバイス IP
独自の証明書を使用するには、Secret の内容を置き換えてゲートウェイを再起動します:
証明書は有効期限の 30 日以上前に更新してください。Secret 内の証明書が残り 30 日に入ると、Deployment Manager は新しく生成した自己署名証明書に置き換えます。デバイスの IP アドレスやホスト名を変更しても同じ結果になるため、どちらかを変更する前に証明書を再発行してください。
Deployment Manager は trust bundle も次の名前で公開します: roboflow-trust-bundle ConfigMap としてゲートウェイにマウントされます。ゲートウェイはこれを使用して、フリート内の他の Roboflow 管理デバイスが提示する TLS 証明書を信頼するため、証明書を手動で配布しなくてもデバイスがゲートウェイに認証できます。
推論サーバーの接続
Roboflow Inference Server を実行する各マシンで、ゲートウェイのクライアントインストールスクリプトを実行します。これはゲートウェイの証明書をマシンの信頼ストアに追加し、Roboflow のトラフィック（API 呼び出し、モデル重み、コンテナイメージの pull）をゲートウェイ経由にルーティングします:
この -k フラグがここでは必要です。マシンはまだゲートウェイの証明書を信頼しておらず、その証明書をこのスクリプトがインストールします。この操作は自分で制御できるネットワーク経路上でのみ行うか、あるいはスクリプトを自分でコピーして先に確認してください。
別の方法として、個々の Inference Server をゲートウェイに向けるには SECURE_GATEWAY 環境変数を使用します。以下を参照してください。 推論サーバーの接続。明示的なスキーム（SECURE_GATEWAY=https://<device-ip>）をバージョン間で一貫して使用してください。証明書はその IP をカバーしている必要があります。保留中の runtime-hardening ビルドでは、次に記載のとおり、裸のアドレスと平文の動作が変更されます: セキュリティ設定の移行。Inference Server もゲートウェイの証明書を信頼する必要がありますが、これはクライアントインストールスクリプトが代行します。外向きアクセスが必要なのはゲートウェイのみです: api.roboflow.com と repo.roboflow.com.
トラブルシューティング
キャッシュボリュームが停止したまま 保留中
LVM ボリュームグループがない、または 60 GB の空きがあるものがありません。空き容量は次で確認してください: sudo vgs。ボリュームグループに容量ができると、ボリュームは自動的にバインドされます。より小さいボリュームで実行するには、次を下げます: storage_size と CACHE_MAX_SIZE_GB を /opt/rfdm/config/rfconfig.json.
Gateway LoadBalancer Service が停止したまま <pending>
デバイス上のポート 80/443 はまだ使用中です。通常は既定の router がまだ有効だからです。インストーラーはこれを次のスニペットで設定します: /etc/microshift/config.d/10-roboflow-ingress.yaml。次のファイルではなく /etc/microshift/config.yamlを確認してください: sudo microshift show-config --mode effective が次を報告します: ingress.status: Removed。スニペットが消えている場合は戻して MicroShift を再起動してください。また、他のホストプロセスが 80 または 443 をバインドしていないことも確認してください。
firewalld の再読み込み後に接続が失敗する
firewalld の再読み込みにより、OVN ネットワーキング Pod が再起動するまで MicroShift の Pod ネットワークが壊れます。次の名前空間の Pod を削除してください: openshift-ovn-kubernetes Namespace で Pod を再作成させるか、MicroShift を再起動してください。
Node が NotReady; ovnkube-master Pod が次のエラーでクラッシュループする: ネットワークインターフェースの MTU (...) が、指定された overlay MTU (1500) に対して小さすぎます
ネットワークインターフェースの MTU が 1500 未満です（クラウド VPC や VPN 接続で一般的です。GCP は 1460 を使用します）。Pod の MTU をインターフェース MTU から 100 引いた値に設定してください: /etc/microshift/ovn.yaml：1460 のインターフェースの場合、このファイルには次の 1 行だけを含めます: mtu: 1360。その後、次を実行します: sudo systemctl stop microshift, echo 1 | sudo microshift-cleanup-data --ovn、および sudo systemctl start microshift。以前の MTU は OVN データベースに保存されているため、このクリーンアップ手順が必要です。
Gateway Pod が停止したまま ImagePullBackOff ホストのイメージクリーンアップ後
イメージの固定はバンドル内の正確な参照を保護しますが、 podman rmi または podman image prune ホスト上でこれを実行すると、CRI-O が使用する同じストレージから兄弟イメージや共有レイヤーを削除できてしまいます。デバイス上のコンテナーストレージを prune しないでください。イメージが消えてしまった場合は、インストーラーを再実行して再読み込みしてください。
ゲートウェイログ Init ハンドシェイクに失敗 ... local-cache-only モードで起動中
起動時にゲートウェイが Roboflow API に到達できませんでした（API キーが誤っている、外向き接続がない、またはキャッシュがまだ起動中である）。トラフィックの提供は続け、ローカルキャッシュも保持しますが、S3 バックアップのキャッシュなしで動作し、次回再起動までテレメトリやイベントをバックエンドに報告できません。原因を修正してから、次を実行してください: sudo oc rollout restart deployment/secure-gateway -n roboflow-edge --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
ログの場所
Deployment Manager: sudo journalctl -u rfdm。ゲートウェイとキャッシュ: sudo oc logs deployment/secure-gateway -n roboflow-edge （および deployment/seaweedfs）を --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
サポートマトリクス
4.19
9.6
4.20（EUS）
9.6
推奨
4.21
9.6
RHEL 10 上の MicroShift 4.21 は Red Hat Technology Preview であり、Secure Gateway ではサポートされていません。
MicroShift 4.16 が最小サポートバージョンです。偶数番号の MicroShift リリースには Extended Update Support（EUS）が付くため、長期運用のエッジデプロイメントには 4.20 が最適です。
最終更新
役に立ちましたか？