Requisitos previos

Esta página describe los requisitos previos para instalar Vantage 3.0 autoalojado. En su propia suscripción y clúster, aprovisiona todo lo indicado en esta página; aquí se describe qué debe crear, no las herramientas para hacerlo. Para consultar el procedimiento completo, elija Azure o Self-Managed Kubernetes.

Vantage 3.0 usa un modelo de implementación distinto al de 2.7 y versiones anteriores. Las versiones anteriores requerían la infraestructura especificada exactamente por ABBYY, creada y configurada mediante scripts de Ansible y Azure CLI proporcionados por ABBYY. Ese modelo no es compatible con 3.0:

Usted aprovisiona su propia infraestructura: el clúster de Kubernetes, las bases de datos, las cuentas de almacenamiento y el Key Vault. ABBYY no proporciona scripts de aprovisionamiento, plantillas ni ningún otro tipo de automatización de infraestructura para 3.0.
El instalador implementa únicamente Vantage Core. El software de terceros del que depende Vantage, como ArgoCD, su service mesh y controlador de ingress, su integración con secrets y su pila de monitorización, lo instala y mantiene usted, normalmente mediante Helm.
Las configuraciones documentadas son escenarios que ABBYY ha probado. Puede adaptar su instalación basándose en los ejemplos documentados; validar cualquier adaptación es su responsabilidad.

Requisitos del operador

El operador de Vantage se ejecuta en Kubernetes y ArgoCD.

Componente	Versión	Versión probada	Notas
Kubernetes	Consulte la matriz de versiones compatibles	AKS 1.33.6; Kubernetes autogestionado 1.36.1	Consulte Compatibilidad para ver la lista completa.
ArgoCD	`>= 2.6.0`	v3.3.2 en AKS; v3.4.3 en Kubernetes autogestionado	La función ApplicationSet Progressive Syncs debe estar habilitada. ArgoCD también necesita una conexión al repositorio de su registro de OCI para poder obtener los charts de componentes de Vantage.
Helm	`>= 3.0.0`	v4.2.0 en AKS; v3.21.1 en Kubernetes autogestionado	Se usa para instalar el operador y los charts de Vantage.

Requisitos a nivel de clúster

Estos servicios y componentes deben estar presentes en el clúster antes de instalar Vantage. Las versiones concretas probadas se enumeran en Compatibilidad.

Componente	Notas
Malla de servicios	Istio en AKS o Linkerd en Kubernetes autogestionado. La malla debe proporcionar mTLS entre cargas de trabajo en el namespace de Vantage. Habilite la inyección en el namespace correspondiente antes de instalar Vantage.
Controlador de ingress	El chart incluye una ruta de ingress de Istio. Si usa otro controlador, desactive el ingress integrado e implemente los requisitos de Vantage para enrutamiento, reescritura, TLS y esquema de reenvío documentados en Self-Managed Kubernetes.
controlador Secrets Store CSI¶	El propio controlador, más el complemento Azure Key Vault Provider. Obligatorio cuando se usa el proveedor de secretos de Azure. Expone secretos y certificados desde su Key Vault en la nube a los pods en tiempo de ejecución.
Certificados TLS	Deben estar firmados por una CA pública. Un secreto de tipo `kubernetes.io/tls` válido para su valor `dnsRecord`, en el mismo namespace que el ingress gateway externo de Istio.
Registro OCI	Registro de destino para los artefactos de Vantage. El trabajo de migración del operador copia los artefactos en él desde el registro de origen proporcionado por ABBYY; obtenga el host del registro y el repositorio de su equipo de cuentas de ABBYY. Sus cargas de trabajo extraen las imágenes de Vantage de este registro: configure el acceso de extracción con secretos de extracción de imágenes de Kubernetes o, en Azure, concediendo `AcrPull` a la identidad administrada de AKS. Consulte Image pull access.
KEDA 2.17.3 (opcional, recomendado)	Un componente de escalado automático. Cuando la compatibilidad con KEDA está habilitada, las réplicas de la carga de trabajo se escalan automáticamente hacia arriba y hacia abajo en función de la utilización del sistema. Los charts actuales de carga de trabajo de Vantage requieren KEDA 2.17.x; no use 2.18 ni versiones posteriores. Consulte Autoscaling with KEDA.

Compatibilidad con KEDA

Algunos recursos ScaledObject de KEDA de Vantage dependen de una instancia de Prometheus en el namespace observability. Debe poder accederse al servicio de Prometheus en http://prometheus-operated.observability.svc.cluster.local:9090, y este debe recopilar las métricas de la aplicación de Vantage mediante el ServiceMonitor creado por el chart. Consulte Autoscaling with KEDA para conocer el comportamiento de los desencadenadores y la verificación, y Monitoring para el flujo de métricas.

Requisitos de los nodos de Kubernetes

Vantage distribuye sus cargas de trabajo entre tres pools de nodos: un pool de nodos predeterminado para la UI, la API y los servicios de plataforma, un pool de nodos de TechCore para los workers de procesamiento de documentos y un pool de nodos de entrenamiento para los workers relacionados con el entrenamiento. Etiquete y aplique taints a los pools de TechCore y de entrenamiento tal como se describe debajo, de modo que el trabajo de procesamiento quede aislado del resto de la aplicación.

Nodos worker de TechCore

Vantage incluye varias cargas de trabajo denominadas “workers de TechCore”. Estas cargas de trabajo realizan gran parte del procesamiento principal de la aplicación (a diferencia de las cargas de trabajo que ejecutan aplicaciones de UI y API). Se recomienda dedicar un pool de nodos de Kubernetes específicamente a estas cargas de trabajo. Para ello, agregue la etiqueta k8s.abbyy.com/techcore=true al conjunto de nodos en los que deben ejecutarse las cargas de trabajo de los workers de TechCore y añada a esos nodos el siguiente taint:

- key: k8s.abbyy.com/techcore
  value: "true"
  effect: NoSchedule

Nodos worker de entrenamiento

Segmente aún más los nodos worker de TechCore designando nodos específicos que deban ejecutar trabajos relacionados con el entrenamiento. Las cargas de trabajo relacionadas con el entrenamiento tienen la siguiente toleración:

- key: k8s.abbyy.com/techcore
  operator: Equal
  value: training
  effect: NoSchedule

Añada el taint k8s.abbyy.com/techcore=training:NoSchedule a los nodos que deban ejecutar cargas de trabajo de entrenamiento. Solo las cargas de trabajo relacionadas con el entrenamiento toleran este taint, por lo que ninguna otra carga de trabajo de Vantage se programará en esos nodos. Consulte la documentación oficial de Kubernetes para obtener más información sobre los taints y las toleraciones.

Tamaños y cantidades de nodos de Kubernetes

La cantidad y el tamaño de los nodos dependen del perfil de instalación y de los componentes opcionales que habilite. Consulte la guía de Dimensionamiento para conocer los requisitos de CPU, memoria y cantidad de pods por pool de nodos en instalaciones mínimas y de producción.

Servicios externos

Prepárelos antes de la instalación. Los productos probados específicos se enumeran en Compatibilidad.

Servicio	Notas
Servidor de base de datos	SQL Server o PostgreSQL. Vantage necesita una base de datos lógica distinta por cada alias de connection string enumerado en Secretos y Key Vault. Las bases de datos no tienen que existir de antemano: el migrador de cada servicio crea su base de datos en la primera ejecución. La base de datos `reporting` de SQL Server debe admitir Columnstore Indexing. La generación de informes no está disponible con PostgreSQL.
Redis	Se utiliza para caché, bloqueos y caché del cliente.
SendGrid†	Proveedor de correo predeterminado. Obligatorio, a menos que configure SMTP (`spec.smtp`) en su lugar. Proporcione una `sendgridApiKey` mediante su proveedor de secretos.
Servidor SMTP†	Alternativa opcional a SendGrid; se usa solo cuando `spec.smtp` está configurado. Solo se admite autenticación básica o ninguna autenticación. Consulte Limitaciones conocidas.
Almacenamiento de objetos	Las connection strings provienen de su proveedor de secretos. Consulte Secretos y Key Vault. Si usa un backend de almacenamiento personalizado (`spec.storage.custom`) en lugar del Azure Blob predeterminado, la `StorageClass` de Kubernetes a la que se hace referencia debe estar configurada en el cluster antes de instalar Vantage, y sus volúmenes aprovisionados deben poder escribirse mediante un usuario sin privilegios de root. Consulte Configurar almacenamiento persistente.
Backend de secretos¶	Azure Key Vault cuando se usa el proveedor de Azure. Con el proveedor de Kubernetes, cree previamente Kubernetes Secrets nativos directamente o matérialicelos desde su almacén de secretos existente con una herramienta como External Secrets Operator. Consulte Secretos y Key Vault.

† SendGrid y SMTP son mutuamente excluyentes; solo se requiere uno de ellos. ¶ Obligatorio solo cuando se usa el proveedor de secretos de Azure (vantage.secrets.azure). El proveedor de Kubernetes Secrets (vantage.secrets.kubernetes) lee recursos Secret preexistentes en el namespace de instalación y no necesita ni el controlador CSI ni un Key Vault en la nube.

Siguientes pasos

Instalar en Azure

Requisitos previos de AKS, configuración de identidad y procedimiento de instalación.

Self-Managed Kubernetes

Use su propio mesh, ingress, secrets, servicios de datos y registro.

Compatibilidad

Versiones compatibles de Kubernetes, distribuciones y versiones de dependencias.

Dimensionamiento

Requisitos de CPU, memoria y número de pods por pool de nodos.

Prerequisites

Providers

Requisitos del operador

Requisitos a nivel de clúster

Compatibilidad con KEDA

Requisitos de los nodos de Kubernetes

Nodos worker de TechCore

Nodos worker de entrenamiento

Tamaños y cantidades de nodos de Kubernetes

Servicios externos

Siguientes pasos

Instalar en Azure

Self-Managed Kubernetes

Compatibilidad

Dimensionamiento

​Requisitos del operador

​Requisitos a nivel de clúster

​Compatibilidad con KEDA

​Requisitos de los nodos de Kubernetes

​Nodos worker de TechCore

​Nodos worker de entrenamiento

​Tamaños y cantidades de nodos de Kubernetes

​Servicios externos

​Siguientes pasos

Instalar en Azure

Self-Managed Kubernetes

Compatibilidad

Dimensionamiento

Requisitos del operador

Requisitos a nivel de clúster

Compatibilidad con KEDA

Requisitos de los nodos de Kubernetes

Nodos worker de TechCore

Nodos worker de entrenamiento

Tamaños y cantidades de nodos de Kubernetes

Servicios externos

Siguientes pasos