メインコンテンツへスキップ
このガイドでは、お客様がプロビジョニングして運用する Kubernetes クラスターに Vantage 3.0 self-hosted をデプロイします。ここでは、Vantage がクラスターに対して必要とするインターフェイスを定義し、Linkerd、Traefik、External Secrets と HashiCorp Vault をその例として使用します。同じ要件を満たす同等のコンポーネントを使用できます。 このガイドでは、稼働中の Kubernetes クラスターが用意されていることを前提としています。Kubernetes、サービスメッシュ、ingress コントローラー、シークレット管理システム、データベース、ストレージ、レジストリのインストールは行いません。
vantage-operator と vantage-selfhosted のチャートは、同じバージョンを使用する必要があります。このページの例では、両方のチャートにバージョン 0.70.13 を使用しています。

​
参照アーキテクチャ

サポート対象および検証済みのコンポーネントのバージョンについては、Compatibility を参照してください。インフラストラクチャの完全な一覧とサイジングの基準については、Prerequisites を参照してください。

​
始める前に

次の値とリソースをあらかじめ用意してください。 また、次のものも必要です。
  • $your_vantage_hostname の DNS レコード (ingress のエントリ ポイントに名前解決されるもの) 。
  • そのホスト名に対する有効な TLS 証明書。
  • レジストリで認証が必要な場合は、Kubernetes の registry pull シークレット。
  • Secret aliases に記載されているすべてのアプリケーション シークレット。
  • データベース エイリアスごとに一意の論理データベース名。各サービスの マイグレーター は初回実行時にデータベースを作成します。
  • TechCore worker 用のラベルが付いたノード。

​
クラスターの準備

​
ArgoCD を設定する

ArgoCD をインストールし、ApplicationSet Progressive Syncs を有効にします。また、移行先の レジストリ から Vantage component のチャートを取得できる OCI リポジトリ接続も ArgoCD に必要です。 ArgoCD private repository documentation に従って、移行先の レジストリ を OCI Helm リポジトリとして登録します。レジストリの認証情報は、ArgoCD の Application マニフェストに直接記述するのではなく、既存のシークレット管理システムで管理してください。

​
サービスメッシュを構成する

Vantage では、ワークロード間で mTLS が必要です。サポートされているサービスメッシュをインストールして運用し、Vantage をインストールする前に $install_namespace のメッシュインジェクションを有効にします。 たとえば、Linkerd の場合:
続行する前に、名前空間で新たに作成したテスト用podに mesh のサイドカーが挿入されていることを確認してください。別の mesh を使用している場合は、その名前空間または workload への挿入手順に従ってください。

​
TechCore ワーカーノードを設定する

TechCore のワーカーワークロードは、次のラベルが付与されたノードを選択します。
少なくとも1つの一致するノードがないと、TechCore pod は Pending のままになります。training-worker の分離とサイジングの基準については、Kubernetes ノード要件を参照してください。

​
永続ストレージを Configure

Vantage をインストールする前に、StorageClass を作成または選択します。ストレージ実装は、本番環境で必要な可用性、耐久性、容量、拡張性、バックアップ、復旧の要件を満たしている必要があります。 これを Vantage の values で参照します。
StorageClass の名前は Kubernetes ディストリビューションに依存しません。開発クラスターのローカル ストレージ クラスを、損失やフェールオーバーの特性を評価せずに本番環境へそのままコピーしないでください。

​
データベースを準備する

Vantage は SQL Server と PostgreSQL をサポートしています。provider は必ず以下のとおり正確に設定してください。値では大文字と小文字が区別されます：
有効な値は SqlServer と PostgreSQL です。Postgresql や PostgreSql のような値は、アプリケーションのデータ プロバイダー名と一致しないため、ランタイムで失敗する可能性があります。 すべての Vantage サービスは、それぞれ別個の論理データベースを使用する必要があります。各サービスは独自にマイグレーションを実行するため、複数のサービスを 1 つのデータベースに向けると、マイグレーションの状態が競合します。データベース名と接続文字列を計画するには、Database aliases 配下のデータベース一覧を利用してください。データベースを手動で作成する必要はありません。各サービスのマイグレーターが初回実行時にデータベースを作成します。
Reporting を利用できるのは SQL Server の場合のみです。PostgreSQL を使用する場合は、vantage.reportingEnabled を false のままにしてください。
PostgreSQL の接続文字列は、先頭・末尾・途中に改行文字を含まない 1 行である必要があります。

​
Kubernetes Secrets を準備する

Kubernetes secrets プロバイダーは、$install_namespace 内の Kubernetes ネイティブの Secret リソースを読み取ります。Vantage は Vault やその他の外部シークレットストアに直接接続しません。External Secrets Operator、CSI ドライバー、またはその他の同期ツールを使用する場合は、Vantage をインストールする前に、必要な Kubernetes Secrets が作成されるように設定してください。 Kubernetes provider を選択します。
デフォルトでは、Vantage はドキュメントに記載されているシークレット名を使用します。objects を使用して、エイリアスを別のシークレットにマッピングします:
2 つの認証キーペアは、アプリケーション トークンの署名に使用されます。これらは、ingress controller で公開 HTTPS を終端する証明書とは別のものです。必要なキーと形式については、Certificate aliasesを参照してください。 複数のサービスで汎用のDatabase__ConnectionStringキーを使用する場合は、サービスごとに個別のSecretを作成し、各データベース エイリアスをvantage.secrets.kubernetes.objectsを通じてマッピングします。シークレット管理システムでは、共通の接続文字列テンプレートからこれらのSecretを生成できますが、生成される各接続文字列では、それぞれ異なるデータベース名を指定する必要があります。
operator は、事前チェック時にシークレット構成を検証します。対応するvantage-operatorチャートとvantage-selfhostedチャートでは、Vantage リリースの名前空間でのみバインドされる ClusterRole を通じて、operator に Secrets への読み取りアクセスを付与します。operator の名前空間やコントローラーの ServiceAccount をカスタマイズする場合は、Vantage チャート内の対応するoperator値を、そのインストールに合わせてください。カスタムのresourceNames制限には、Kubernetes provider が参照するすべてのSecretを含める必要があります。

​
レジストリアクセスを設定する

レジストリアクセスには、3 つの独立した利用主体があります。 各利用主体が実行される名前空間に、レジストリのシークレットを作成します。values ファイルには、平文のレジストリパスワードを記載しないでください。 OCI 移行では、ソースおよび宛先の認証情報シークレットを参照します。
送信先レジストリのプル用シークレットを、Vantageワークロードでデフォルトとして使用される、vantage.serviceAccountName で指定された ServiceAccount の imagePullSecrets に追加します。
コンポーネントの pod が別の ServiceAccount で実行されている場合は、その ServiceAccount にもレジストリのプルアクセスが必要です。名前空間の default ServiceAccount を変更する前に、pod の spec.serviceAccountName を確認してください。

​
自動スケーリングとメトリクスを設定する

KEDA のサポートは任意ですが、推奨されています。KEDA 2.17.3 を使用してください。KEDA 2.18 以降では、現在の Vantage workload チャートで使用されている scaler field が削除されたため、必要な HPA を作成できません。 一部の Vantage ScaledObject リソースは、この固定アドレスの Prometheus をクエリします。
KEDA を有効にする前に:
  1. KEDA 2.17.3 をインストールします。
  2. observability 名前空間に Prometheus Operator と Prometheus インスタンスをインストールします。
  3. それを管理する Service の名前が prometheus-operated で、ポート 9090 を公開していることを確認します。
  4. Vantage の ServiceMonitor を検出できるように Prometheus を設定します。
Vantage リソースで KEDA を有効にし、別個のトップレベル observability スタンザでチャートの ServiceMonitor を有効にします:
observability は最上位のキーです。vantage の下にネストしないでください。トリガー戦略、検証、キャパシティプランニングについては、KEDA を使用したオートスケーリングを参照してください。メッシュ固有のスクレイピング設定については、Prometheus による監視を参照してください。

​
ingress と TLS を設定する

チャートに組み込まれている ingress は Istio 用です。Traefik または他の ingress コントローラーを使用する場合は、これを無効にしてください:
ingress の構成では、次の要件を満たす必要があります。
  • 信頼できる証明書を使用して、vantage.dnsRecord の HTTPS を終端すること。
  • Vantage UI、API、認証、ヘルプ、SCIM、URL-shortener、ワークスペース、Verification、Try Any Skill の各パスを、それぞれ対応する Service にルーティングすること。
  • Vantage で使用される /api/vN/ から /publicapi/vN/ への書き換え、および /api/、SCIM、ハートビートの書き換えを適用すること。
  • UI のキャッチオールルートよりも前に、より具体的なルートを優先してマッチさせること。
  • 元の host とスキームを転送すること。これには、TLS が ingress controller で終端される場合の X-Forwarded-Proto: https も含まれます。
Traefik では、これらの要件を IngressRoute と順序付けされた Middleware リソースで実装します。ルートマニフェストは、バージョン管理される Vantage の構成として扱ってください。別の環境の値をそのままコピーするのではなく、ご利用のリリースに合わせて、hostname、名前空間、証明書用シークレット、生成される Service 名をパラメーター化してください。

​
ルーティング仕様

$install_namespace 内で生成された Kubernetes Service 名を確認し、以下の順序でこれらのルートを実装します。正規表現ルートと完全一致ルートは、プレフィックスルートおよびキャッチオールルートより優先する必要があります。 チャートに組み込まれている Istio ingress は、クライアントに不要な内部ステータス情報を公開する /api/status と /api/status/config もブロックします。これらのパスをブロックすることが推奨されますが、Vantage の動作に必須ではありません。使用している ingress コントローラー が直接拒否レスポンスを返せない場合は、一般的な /api ルールの前に、これらのパスを専用の拒否バックエンドにルーティングできます。

​
HTTPS スキームの転送

TLS が ingress コントローラーで終端され、バックエンド接続が HTTP の場合、Vantage の認証サービスは X-Forwarded-Proto を認識する必要があります。auth-identity、auth-adminapi2、api-gateway、api-registry のアプリケーションコンテナーに、次の環境変数が設定されていることを確認してください。
現在のワークロード チャートが環境変数による上書きをサポートしていない場合は、Kyverno や同等の mutating webhook など、標準の admission mutation の仕組みを使用してください。Vantage の pod を作成する前に、このミューテーションを適用してください。これを行わないと、OIDC の Discovery Document で http:// エンドポイントが通知され、ブラウザーでのサインインが失敗します。

​
オペレーターをインストールする

クラスターにオペレーターのインスタンスを1つインストールします。
operator レジストリでプルシークレットが必要な場合は、--wait の前にこのオプションをコマンドに追加します:

​
Vantage をインストールする

上で準備した設定をまとめた values ファイルを作成します。この簡略化した例では、セルフマネージド環境に固有の値のみを示しています。実際の環境に合わせて、完全なシークレットのマッピングと レジストリ の認証情報を追加してください。
vantage-selfhosted チャートをインストールします。
オペレーターがワークロードの Service を作成したら、Ingress コントローラーの設定を適用し、TLS 証明書の準備ができていることを確認してください。

​
インストールを監視する

カスタムリソースが Ready になるまで待ちます:
次に、生成された ArgoCD アプリケーションとワークロードを確認します。Ready だけで判断しないでください。
OCI 移行が有効な場合は、個別に監視してください：
Skill のインストールは別のジョブで実行され、Vantage が Ready を示した後も継続することがあります。
最後に、次の点を確認してください。
  • 生成されたすべての ArgoCD application が Synced かつ Healthy であること。
  • Vantage の pod が実行中で、mesh がインジェクトされていること。
  • Prometheus で Vantage の /metrics-text ターゲットが UP と表示されていること。
  • KEDA の ScaledObject リソースが Ready で、HPA のメトリクス値が <unknown> ではないこと。
  • OIDC の Discovery Document とブラウザーのリダイレクトで https:// URL が使用されていること。
  • https://$your_vantage_hostname で Vantage にアクセスできること。

​
次のステップ

シークレット

Kubernetes Secret のエイリアス、認証キーペア、データベース接続文字列。

監視

サービスメッシュ経由で Vantage をスクレイプするように Prometheus を設定します。

トラブルシューティング

operator、データベース、レジストリ、Ingress、オートスケーリングの障害を診断します。

アップグレード

operator と Vantage のチャートをまとめてアップグレードします。