Saltar al contenido principal
Actualmente, Vantage 3.0 autoalojado presenta un pequeño conjunto de restricciones. Téngalas en cuenta antes de dimensionar o planificar una implementación.

​
Restricciones arquitectónicas

​
Una instancia del operador por clúster

El Helm chart vantage-operator usa nombres de recursos de ámbito de clúster y no parametrizados: el ClusterRole manager-role, el ClusterRoleBinding manager-rolebinding y la ServiceAccount controller-manager. Instalar el chart dos veces en el mismo clúster (incluso en distintos espacios de nombres) genera conflictos con estos recursos. Instala solo una instancia de este chart por clúster.

​
Soporte para la implementación

​
Entornos de implementación compatibles

Vantage 3.0 autoalojado es compatible con AKS y con Kubernetes autogestionado. Las integraciones validadas se documentan en Compatibility. No se han validado otras versiones de Kubernetes, mallas de servicios, controladores de ingress, motores de bases de datos ni sustituciones de componentes; póngase en contacto con su equipo de cuenta de ABBYY antes de usar en producción una combinación que no figure en la lista.

​
Compatibilidad con bases de datos

​
Los informes requieren SQL Server

PostgreSQL es compatible con los servicios de Vantage, pero la carga de trabajo de informes utiliza migraciones específicas de SQL Server y no está disponible con PostgreSQL. Configure vantage.databaseProvider: PostgreSQL y mantenga vantage.reportingEnabled: false para las implementaciones con PostgreSQL.

​
Envío de correo

​
SMTP solo admite autenticación básica

SendGrid es el proveedor de correo predeterminado: proporcione un secreto sendgridApiKey y Vantage lo usará sin necesidad de configuración adicional. SMTP solo se usa cuando configura spec.smtp, y actualmente esta opción solo admite autenticación básica o ninguna autenticación. Si su relay de correo requiere otro esquema de autenticación y no puede usar SendGrid, prevea un relay intermedio que la reduzca a autenticación básica.

​
Consideraciones operativas

​
Los controladores de ingress alternativos requieren el contrato de rutas de Vantage

Las rutas de ingress validadas son la configuración integrada de Istio en AKS y la configuración documentada de Traefik en Kubernetes autogestionado. Cualquier otro controlador de ingress debe implementar las mismas rutas, reescrituras, comportamiento de TLS, protección del estado interno y protocolo HTTPS reenviado. La validación de cualquier otro controlador o implementación de rutas es su responsabilidad. Cuando TLS termina antes de un backend HTTP, los servicios de autenticación de Vantage deben respetar X-Forwarded-Proto. Si los charts de carga de trabajo no exponen la variable de entorno requerida, use un mecanismo compatible de mutación de admisión, como se describe en Self-Managed Kubernetes.

​
KEDA se limita a la versión 2.17.x

Los charts de carga de trabajo actuales de Vantage usan un campo de escalado de KEDA que se eliminó en KEDA 2.18. Use KEDA 2.17.3. Con KEDA 2.18 o posterior, los recursos ScaledObject afectados no pueden crear sus HPA y permanecen degradados. Consulte Escalado automático con KEDA.

​
La instalación de skills no aparece en ArgoCD

Las skills se instalan mediante un trabajo de Kubernetes independiente, no a través de una aplicación de ArgoCD gestionada por un operador, por lo que ArgoCD actualmente no ofrece visibilidad del progreso de la instalación de skills. El recurso Vantage puede mostrar Ready mientras el trabajo sigue en ejecución; puede usar Vantage mientras la instalación de skills continúa. Supervise el trabajo directamente con kubectl wait. Consulte Lifecycle para ver los comandos.

​
Siguientes pasos

Migrar desde Vantage 2.7

Planifique la migración desde una implementación autoalojada existente de la versión 2.7.

Actualización

Flujo de trabajo manual para actualizar entre versiones 3.0.