ネットワーク
接続
OpenLM Platform は、次の接続に依存します。
| 接続元 | 接続先 | ポート | 用途 |
|---|---|---|---|
| ユーザーのブラウザー | プラットフォームのアドレス | 443 | ユーザーが行うすべての操作 |
| エージェント（ライセンスサーバーエージェント、ワークステーションエージェント） | プラットフォームのアドレス | 443 | 使用状況データの送信 |
| Pod | プラットフォームのアドレス | 443 | サインイントークンの確認（次のセクションを参照） |
| Pod | SQL Server | 1433（または独自のポート） | データ |
| Pod | MongoDB | 27017（または独自のポート） | データ |
| Pod | Kafka | 9092（または独自のポート） | サービス間のイベント |
| Pod | Redis | 6379（または独自のポート） | キャッシュ、API ゲートウェイ |
| ノード | public.ecr.aws | 443 | イメージのプル |
| ノード | docker.tyk.io | 443 | API ゲートウェイのイメージのプル |
| Pod | namespace 内の互いの Pod | さまざま | サービス間通信 |
namespace 内のサービス間トラフィックは、クラスターネットワーク上のプレーン HTTP を使用します。このトラフィックがクラスターの外に出ることはありません。
クラスター内からプラットフォームのアドレスに到達する
Pod は、OpenLM Platform にそのパブリックアドレスで到達できる必要があります。これは、最も見落とされやすいネットワーク要件です。
いくつかのサービスは、すべてのサインイントークンを、identity サービスの パブリック アドレス https://<DOMAIN>/identity に問い合わせて確認します。トークン内のアドレスはユーザーがサインインしたアドレスと一致する必要があるため、内部のショートカットは使用しません。そのため、Pod は次の 3 つすべてを実行できる必要があります。
DOMAINをアドレスに 名前解決 する。- ポート 443 でそのアドレスに 接続 する。
- その証明書を 信頼 する。TLS 証明書 を参照してください。
3 つのいずれかが失敗すると、ユーザーはホームページを開けますが、データを読み込むすべての画面が失敗し、サービスのログに IdentityUnavailable が記録されます。
Pod が到達できない場合
ネットワークによっては、Pod からクラスター自身の外部ロードバランサーへのトラフィックが戻ってこないことがあります。これはヘアピン問題と呼ばれ、オンプレミスのロードバランサーや一部のファイアウォールでよく発生します。また、DNS 名が、クラスターの DNS が使用しない内部ゾーンにしか存在しない場合もあります。
これを解決するには、クラスター内でのみ、その名前がIngress コントローラーの内部サービスに解決されるようにします。CoreDNS を使用するクラスター（EKS、AKS、K3s）では、書き換えルールを追加します。
rewrite name exact openlm.example.com traefik.kube-system.svc.cluster.local
ホスト名を DOMAIN に、ターゲットをIngress コントローラーのサービス（<service>.<namespace>.svc.cluster.local）に置き換えます。ルールを配置する場所は Kubernetes ディストリビューションによって異なります。EKS、AKS、または K3s を参照してください。クラスター外のユーザーには影響しません。
DNS を変更した後は、OpenLM Platform のサービスを再起動して再接続させます: kubectl -n openlm rollout restart deployment。
DNS のルール
DNS 名には、次のルールに従います。
- 50 文字未満: DNS 名は 50 文字未満にする必要があります。UI の Web サーバーは名前を固定サイズのテーブルに保持するため、長すぎる名前では Web サーバーが起動しません。
- IPv4: Pod は IPv4 を使用します。ノードの DNS リゾルバーが IPv6 でしか応答しない場合、Pod は外部の名前を解決できません。クラスターの DNS が IPv4 のリゾルバーを参照するように設定します。
- すべてに 1 つの名前: OpenLM Platform を 2 つの名前で公開しないでください。サインイントークンには名前が含まれるため、2 つ目の名前を使用するユーザーはサインインできなくなります。
データサービス
データサービスへの接続は、次のように設定します。
- Pod から到達できる名前（または IP）を使用します。VPN 経由でノート PC から使用できるデータベース名が、クラスター内では解決できない場合があります。
- クラウドのマネージドサービスは、通常、ファイアウォールまたはセキュリティグループの背後にあります。クラスターの 送信元アドレス を許可します。EKS と AKS では NAT ゲートウェイの IP、それ以外ではノードの IP です。EKS と AKS では、代わりにクラスターのセキュリティグループまたはサブネットを許可することもできます。
- Kafka は、Pod から到達できるアドレスを アドバタイズ する必要があります。データサービス: Kafka を参照してください。
レジストリミラー
OpenLM のイメージはすべて public.ecr.aws/r3q3q2f4/olm-* から取得され、タグは 1.YYMMDD.HHMM の形式です。ノードがインターネットに到達できない場合は、このパスを自社のレジストリ（Artifactory、Nexus、Quay、Harbor、ECR、ACR）にミラーします。
public.ecr.aws用の プルスルーキャッシュまたはリモートリポジトリ が最も簡単な方法です。イメージ名はそのままで、レジストリのホストだけが変わります。- コンテナーランタイムのミラー設定、または OpenShift ではクラスターのイメージミラーポリシー（
ImageDigestMirrorSet/ImageTagMirrorSet）で、クラスターがミラーを参照するように設定します。
各リリースのイメージは、そのリリースの リリースノート に記載されています。
ネットワークポリシー
チャートは NetworkPolicy を作成しません。クラスターが既定でトラフィックを拒否する場合は、次のトラフィックを許可します。
- Ingress コントローラーから
openlm内の Pod へ、サービスが公開するすべてのポートで。 openlm内の Pod 間。openlm内の Pod からデータサービスへ、およびポート 443 で OpenLM Platform のアドレスへ。
ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。