Restricciones arquitectónicas
Una instancia del operador por clúster
El Helm chartvantage-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. Configurevantage.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 secretosendgridApiKey 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 respetarX-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 recursosScaledObject 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 recursoVantage 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.