Vantage 3.0 uses a different deployment model than 2.7 and earlier. Previous releases required ABBYY’s exact specified infrastructure, created and configured by ABBYY-provided Ansible and Azure CLI scripts. That model is not supported in 3.0:
- You provision your own infrastructure: the Kubernetes cluster, databases, storage accounts, and key vault. ABBYY does not provide provisioning scripts, templates, or other infrastructure automation for 3.0.
- The installer deploys Vantage Core only. Third-party software that Vantage relies on, such as ArgoCD, your service mesh and ingress controller, your secrets integration, and your monitoring stack, is installed and maintained by you, usually via Helm.
- The documented configurations are scenarios ABBYY has tested. You can adapt your installation based on the documented examples; validating an adaptation is your responsibility.
Operator requirements
The Vantage operator runs on top of Kubernetes and ArgoCD.| Component | Version | Tested version | Notes |
|---|---|---|---|
| Kubernetes | See the supported-version matrix | AKS 1.33.6; self-managed Kubernetes 1.36.1 | See Compatibility for the full list. |
| ArgoCD | >= 2.6.0 | v3.3.2 on AKS; v3.4.3 on self-managed Kubernetes | The ApplicationSet Progressive Syncs feature must be enabled. ArgoCD also needs a repository connection to your OCI registry so it can pull Vantage component charts. |
| Helm | >= 3.0.0 | v4.2.0 on AKS; v3.21.1 on self-managed Kubernetes | Used to install the operator and Vantage charts. |
Cluster-level requirements
These services and components must be present in the cluster before you install Vantage. Concrete tested versions are listed on Compatibility.| Component | Notes |
|---|---|
| Service mesh | Istio on AKS or Linkerd on self-managed Kubernetes. The mesh must provide workload-to-workload mTLS in the Vantage namespace. Enable the appropriate namespace injection before installing Vantage. |
| Ingress controller | The chart includes an Istio ingress path. With another controller, disable the built-in ingress and implement the Vantage routing, rewrite, TLS, and forwarded-scheme requirements documented on Self-Managed Kubernetes. |
| Secrets Store CSI driver¶ | The driver itself plus the Azure Key Vault Provider plugin. Required when using the Azure secrets provider. Surfaces secrets and certificates from your cloud key vault into pods at runtime. |
| TLS certificates | Must be signed by a public CA. A kubernetes.io/tls-type secret valid for your dnsRecord value, in the same namespace as the Istio external ingress gateway. |
| OCI registry | Destination registry for Vantage artifacts. The operator’s migration job copies artifacts into it from the ABBYY source registry (abbyy.jfrog.io, repository abbyy-docker). Your workloads pull Vantage images from this registry: configure pull access with Kubernetes image pull secrets or, on Azure, by granting AcrPull to the AKS managed identity. See Image pull access. |
| KEDA 2.17.3 (optional, recommended) | An autoscaling component. When KEDA support is enabled, workload replicas are automatically scaled up and down based on system utilization. The current Vantage workload charts require KEDA 2.17.x; do not use 2.18 or later. See Autoscaling with KEDA. |
KEDA Support
Some Vantage KEDAScaledObject resources depend on a Prometheus instance in the observability namespace. The Prometheus service must be reachable at http://prometheus-operated.observability.svc.cluster.local:9090, and it must scrape Vantage application metrics through the chart-created ServiceMonitor. See Autoscaling with KEDA for trigger behavior and verification, and Monitoring for the metrics pipeline.
Kubernetes Node Requirements
A base installation of Vantage consists of approximately 100 pods (and a baseline of approximately 140 when KEDA support is enabled). The AKS validation environment uses 12 Standard 8-vCPU B-family nodes. Treat this as a tested installation baseline rather than a universal production size: provide equivalent or greater schedulable capacity on self-managed Kubernetes, then size for document volume, concurrency, availability, monitoring, and failure tolerance.TechCore Worker Nodes
Vantage includes several workloads referred to as “techcore workers”. These workloads carry out much of the main processing of the application (as opposed to workloads running UI and API applications). It is recommended to dedicate a pool of Kubernetes nodes specifically to these workloads. Do so by adding the labelk8s.abbyy.com/techcore=true to the set of nodes on which techcore worker workloads should be scheduled.
Further segment TechCore worker nodes by designating specific nodes that should not run training-related work. Training-related workloads possess the following toleration:
k8s.abbyy.com/techcore=training:NoSchedule taint on these nodes.
See official Kubernetes documentation for more details on taints and tolerations.
External services
Provision these before installing. Concrete tested products are listed on Compatibility.| Service | Notes |
|---|---|
| Database server | SQL Server or PostgreSQL. Vantage needs one distinct logical database per connection-string alias listed under Secrets and Key Vault. The databases do not need to exist ahead of time: each service’s migrator creates its database on first run. The SQL Server reporting database must support Columnstore Indexing. Reporting is unavailable with PostgreSQL. |
| Redis | Used for cache, locks, and client cache. |
| SendGrid† | Default mail provider. Required unless you configure SMTP (spec.smtp) instead. Provide a sendgridApiKey via your secrets provider. |
| SMTP server† | Optional alternative to SendGrid; used only when spec.smtp is configured. Only basic auth or no auth is supported. See Known Limitations. |
| Object storage | Connection strings come from your secrets provider. See Secrets and Key Vault. If you use a custom storage backend (spec.storage.custom) instead of the default Azure Blob, the referenced Kubernetes StorageClass must be configured in the cluster before you install Vantage. |
| Secret backend¶ | Azure Key Vault when using the Azure provider. With the Kubernetes provider, pre-create native Kubernetes Secrets directly or materialize them from your existing secret store with a tool such as External Secrets Operator. See Secrets and Key Vault. |
vantage.secrets.azure). The Kubernetes Secrets provider (vantage.secrets.kubernetes) reads from pre-existing Secret resources in the install namespace and needs neither the CSI driver nor a cloud key vault.
What’s next
Install on Azure
AKS prerequisites, identity setup, and the install procedure.
Self-Managed Kubernetes
Bring-your-own mesh, ingress, secrets, data services, and registry.
Compatibility
Supported Kubernetes versions, distributions, and dependency versions.