> ## 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. # Requisitos previos > La infraestructura que debe estar preparada antes de instalar Vantage 3.0 autoalojado. 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](/es/vantage/self-hosted/v3.0/providers/azure) o [Self-Managed Kubernetes](/es/vantage/self-hosted/v3.0/providers/self-managed). **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](/es/vantage/self-hosted/v3.0/compatibility#supported-kubernetes-versions) 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](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs) debe estar habilitada. ArgoCD también necesita una [conexión al repositorio](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/) 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](/es/vantage/self-hosted/v3.0/compatibility). | 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](/es/vantage/self-hosted/v3.0/providers/self-managed#configure-ingress-and-tls). | | **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 de ABBYY (`abbyy.jfrog.io`, repositorio `abbyy-docker`). 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](/es/vantage/self-hosted/v3.0/providers/azure#image-pull-access). | | [KEDA](https://keda.sh/) 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](/es/vantage/self-hosted/v3.0/performance/autoscaling). |
### Compatibilidad con KEDA
Algunos recursos `ScaledObject` de KEDA de Vantage dependen de una instancia de [Prometheus](https://prometheus.io/) 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](/es/vantage/self-hosted/v3.0/performance/autoscaling) para conocer el comportamiento de los desencadenadores y la verificación, y [Monitoring](/es/vantage/self-hosted/v3.0/monitoring/overview) para el flujo de métricas.
### Requisitos de los nodos de Kubernetes
Una instalación base de Vantage consta de aproximadamente 100 pods (y de una línea base de aproximadamente 140 si se habilita la compatibilidad con KEDA). El entorno de validación de AKS utiliza 12 nodos Standard B-series de 8 vCPU. Tómelo como una línea base de instalación probada, no como un tamaño de producción universal: proporcione en Kubernetes autogestionado una capacidad asignable equivalente o superior y, después, dimensione según el volumen de documentos, la concurrencia, la disponibilidad, la monitorización y la tolerancia a fallos.
#### 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. Segmente aún más los nodos worker de TechCore designando nodos específicos que *no* deban ejecutar trabajos relacionados con el entrenamiento. Las cargas de trabajo relacionadas con el entrenamiento tienen la siguiente toleración: ```yaml theme={null} - key: k8s.abbyy.com/techcore operator: Equal value: training effect: NoSchedule ``` Puede añadir un taint `k8s.abbyy.com/techcore=training:NoSchedule` a los nodos que *no* deban ejecutar cargas de trabajo de entrenamiento. Consulte la [documentación oficial de Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) para obtener más información sobre los taints y las tolerations.
## Servicios externos
Prepárelos antes de la instalación. Los productos probados específicos se enumeran en [Compatibilidad](/es/vantage/self-hosted/v3.0/compatibility). | 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](/es/vantage/self-hosted/v3.0/secrets-and-keyvault). 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](/es/vantage/self-hosted/v3.0/known-limitations#smtp-supports-basic-auth-only). | | **Almacenamiento de objetos** | Las connection strings provienen de su proveedor de secretos. Consulte [Secretos y Key Vault](/es/vantage/self-hosted/v3.0/secrets-and-keyvault). 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. | | **Backend de secretos**¶ | Azure Key Vault cuando se usa el proveedor de Azure. Con el proveedor de Kubernetes, cree previamente Secrets nativos de Kubernetes directamente o matérialicelos desde su almacén de secretos existente con una herramienta como External Secrets Operator. Consulte [Secretos y Key Vault](/es/vantage/self-hosted/v3.0/secrets-and-keyvault). | † 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
Requisitos previos de AKS, configuración de identidad y procedimiento de instalación. Use su propio mesh, ingress, secrets, servicios de datos y registro. Versiones compatibles de Kubernetes, distribuciones y versiones de dependencias.