> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # 前提条件 > Vantage 3.0 セルフホスト型をインストールする前に必要なインフラストラクチャ。 このページでは、Vantage 3.0 セルフホスト型のインストールに必要な前提条件について説明します。このページに記載されているものはすべて、ご自身のサブスクリプションとクラスター内に用意してください。このページでは、作成する必要があるものについて説明しており、それを作成するツールについては扱いません。完全な手順については、[Azure](/ja/vantage/self-hosted/v3.0/providers/azure) または [セルフマネージド Kubernetes](/ja/vantage/self-hosted/v3.0/providers/self-managed) を選択してください。 **Vantage 3.0 では、2.7 以前とは異なるデプロイ モデルを採用しています。** 以前のバージョンでは、ABBYY が提供する Ansible および Azure CLI スクリプトで作成・構成される、ABBYY が厳密に指定したインフラストラクチャが必要でした。このモデルは 3.0 ではサポートされていません。 * Kubernetes クラスター、データベース、ストレージ アカウント、Key Vault などのインフラストラクチャは、お客様自身でプロビジョニングします。ABBYY は、3.0 向けのプロビジョニング スクリプト、テンプレート、その他のインフラストラクチャ自動化機能を提供しません。 * インストーラーがデプロイするのは Vantage Core のみです。ArgoCD、お客様のサービス メッシュと Ingress コントローラー、シークレット統合、モニタリング スタックなど、Vantage が依存するサードパーティ ソフトウェアは、通常 Helm を使用して、お客様自身でインストールおよび保守します。 * 文書化されている構成は、ABBYY がテストしたシナリオです。文書化された例に基づいてインストールを調整できますが、その調整内容の検証はお客様の責任となります。
## オペレーターの要件
Vantage オペレーター は Kubernetes と ArgoCD 上で動作します。 | コンポーネント | バージョン | テスト済みバージョン | 注記 | | ---------- | ------------------ | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Kubernetes | サポート対象バージョンの対応表を参照 | AKS 1.33.6; セルフマネージド Kubernetes 1.36.1 | 完全な一覧については、[互換性](/ja/vantage/self-hosted/v3.0/compatibility#supported-kubernetes-versions)を参照してください。 | | ArgoCD | `>= 2.6.0` | AKS では v3.3.2; セルフマネージド Kubernetes では v3.4.3 | [ApplicationSet Progressive Syncs](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs) 機能を有効にする必要があります。また、Vantage コンポーネントのチャートをプルできるようにするため、ArgoCD には OCI レジストリへの[リポジトリ接続](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/)も必要です。 | | Helm | `>= 3.0.0` | AKS では v4.2.0; セルフマネージド Kubernetes では v3.21.1 | オペレーターおよび Vantage チャートのインストールに使用します。 |
## クラスターレベルの要件
これらのサービスとコンポーネントは、Vantage をインストールする前にクラスタに存在している必要があります。検証済みの具体的なバージョンは、[互換性](/ja/vantage/self-hosted/v3.0/compatibility) に記載されています。 | Component | Notes | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Service mesh** | AKS では Istio、セルフマネージド Kubernetes では Linkerd を使用します。mesh は、Vantage 名前空間内で ワークロード 間の mTLS を提供する必要があります。Vantage をインストールする前に、適切な名前空間インジェクションを有効にしてください。 | | **Ingress controller** | このチャートには Istio の ingress パスが含まれています。別の controller を使用する場合は、built-in ingress を無効にし、[Self-Managed Kubernetes](/ja/vantage/self-hosted/v3.0/providers/self-managed#configure-ingress-and-tls) に記載されている Vantage のルーティング、リライト、TLS、および forwarded-scheme の要件を実装してください。 | | **Secrets Store CSI driver**¶ | driver 本体に加えて、Azure Key Vault Provider プラグインが必要です。Azure secrets provider を使用する場合に必須です。実行時に、クラウドの Key Vault からシークレットと証明書を pod に提供します。 | | **TLS certificates** | **公開 CA による署名が必須です**。Istio external ingress gateway と同じ名前空間にあり、`dnsRecord` の値に対して有効な `kubernetes.io/tls` 型のシークレットが必要です。 | | **OCI レジストリ** | Vantage artifacts の格納先 レジストリ です。オペレーター の migration job により、ABBYY source レジストリ (`abbyy.jfrog.io`、repository `abbyy-docker`) から artifacts がここにコピーされます。ワークロード はこの レジストリ から Vantage イメージを pull するため、Kubernetes image pull secrets を使用するか、Azure では AKS managed identity に `AcrPull` を付与して pull access を構成してください。詳細は [Image pull access](/ja/vantage/self-hosted/v3.0/providers/azure#image-pull-access) を参照してください。 | | [KEDA](https://keda.sh/) 2.17.3 (任意、推奨) | autoscaling コンポーネントです。KEDA サポート を有効にすると、ワークロード レプリカはシステム利用率に基づいて自動的にスケールアップおよびスケールダウンされます。現在の Vantage ワークロード charts では KEDA 2.17.x が必要です。2.18 以降は使用しないでください。詳細は [Autoscaling with KEDA](/ja/vantage/self-hosted/v3.0/performance/autoscaling) を参照してください。 |
### KEDA サポート
一部の Vantage KEDA `ScaledObject` リソースは、`observability` 名前空間内の [Prometheus](https://prometheus.io/) インスタンスに依存しています。Prometheus サービスには `http://prometheus-operated.observability.svc.cluster.local:9090` でアクセスできる必要があり、チャートで作成された `ServiceMonitor` を介して Vantage アプリケーションのメトリクスをスクレイプする必要があります。トリガーの動作と確認については [KEDA によるオートスケーリング](/ja/vantage/self-hosted/v3.0/performance/autoscaling) を、メトリクス パイプラインについては [モニタリング](/ja/vantage/self-hosted/v3.0/monitoring/overview) を参照してください。
### Kubernetes ノード要件
Vantage の基本インストールは、約 100 個の pod (KEDA サポートを有効にした場合のベースラインは約 140 個) で構成されます。AKS の検証環境では、Standard 8-vCPU B-series ノード 12 台を使用しています。これは汎用的な本番環境のサイジングではなく、検証済みインストールのベースラインとして捉えてください。セルフマネージド Kubernetes では、少なくともこれと同等のスケジューリング可能な容量を確保したうえで、ドキュメント処理量、同時実行性、可用性、監視、障害耐性に応じてサイジングしてください。
#### TechCore Worker ノード
Vantage には、「techcore workers」と呼ばれる複数のワークロードが含まれています。これらのワークロードは、アプリケーションの主要な処理の大部分を担います (UI や API アプリケーションを実行するワークロードとは対照的です) 。これらのワークロード専用の Kubernetes ノードプールを用意することを推奨します。そのためには、techcore worker ワークロードをスケジュールするノードセットに、ラベル `k8s.abbyy.com/techcore=true` を追加します。 さらに、学習関連の処理を実行*しない*特定のノードを指定して、TechCore Worker ノードを細分化します。学習関連のワークロードには、次の Toleration があります。 ```yaml theme={null} - key: k8s.abbyy.com/techcore operator: Equal value: training effect: NoSchedule ``` `k8s.abbyy.com/techcore=training:NoSchedule` の taint をこれらのノードに追加することで、学習ワークロードを実行すべき*でない*ノードに taint を設定できます。 taint と toleration の詳細については、[Kubernetes の公式ドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)を参照してください。
## 外部サービス
インストール前に以下を用意してください。検証済みの具体的な製品は、[互換性](/ja/vantage/self-hosted/v3.0/compatibility) に記載されています。 | Service | Notes | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Database server** | SQL Server または PostgreSQL。Vantage では、[Secrets and Key Vault](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault) に記載されている接続文字列エイリアスごとに、個別の論理データベースが 1 つ必要です。データベースは事前に存在している必要はありません。各サービスのマイグレーターが初回実行時にデータベースを作成します。SQL Server の `reporting` データベースは Columnstore Indexing をサポートしている必要があります。PostgreSQL ではレポート機能は利用できません。 | | **Redis** | キャッシュ、ロック、クライアントキャッシュに使用されます。 | | **SendGrid**† | デフォルトのメールプロバイダーです。代わりに SMTP (`spec.smtp`) を設定しない限り必須です。シークレットプロバイダー経由で `sendgridApiKey` を指定してください。 | | **SMTP server**† | SendGrid の任意の代替手段で、`spec.smtp` が設定されている場合にのみ使用されます。サポートされるのは basic auth または認証なしのみです。[Known Limitations](/ja/vantage/self-hosted/v3.0/known-limitations#smtp-supports-basic-auth-only) を参照してください。 | | **Object storage** | 接続文字列はシークレットプロバイダーから取得します。[Secrets and Key Vault](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault) を参照してください。デフォルトの Azure Blob ではなくカスタムストレージバックエンド (`spec.storage.custom`) を使用する場合は、参照先の Kubernetes `StorageClass` を Vantage のインストール前にクラスター内で設定しておく必要があります。 | | **Secret backend**¶ | Azure プロバイダーを使用する場合は Azure Key Vault です。Kubernetes プロバイダーを使用する場合は、ネイティブの Kubernetes Secrets を事前に直接作成するか、External Secrets Operator などのツールを使って既存のシークレットストアから実体化してください。[Secrets and Key Vault](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault) を参照してください。 | † SendGrid と SMTP は相互排他的で、必要なのはいずれか一方のみです。 ¶ Azure シークレットプロバイダー (`vantage.secrets.azure`) を使用する場合にのみ必須です。Kubernetes Secrets プロバイダー (`vantage.secrets.kubernetes`) は、インストール先の名前空間にある既存の `Secret` リソースを読み取るため、CSI ドライバーもクラウドの Key Vault も必要ありません。
## 次のステップ
AKS の前提条件、identity の設定、インストール手順。 独自の mesh、ingress、secrets、データ サービス、レジストリ を使用。 サポート対象の Kubernetes バージョン、ディストリビューション、依存関係のバージョン。