Saltar al contenido principal
Esta guía implementa Vantage 3.0 autoalojado en un clúster de Kubernetes que usted aprovisiona y opera. Define las interfaces que Vantage requiere del clúster y usa Linkerd, Traefik y External Secrets con HashiCorp Vault como ejemplos. Puede usar componentes equivalentes que cumplan los mismos requisitos. Esta guía parte de un clúster de Kubernetes ya en funcionamiento. No instala Kubernetes, la malla de servicios, el controlador de ingress, el sistema de gestión de secretos, las bases de datos, el almacenamiento ni los registros de contenedores.
Los charts vantage-operator y vantage-selfhosted deben usar la misma versión. Los ejemplos de esta página usan la versión 0.70.13 para ambos charts.

​
Arquitectura de referencia

Para conocer las versiones de componentes compatibles y probadas, consulte Compatibilidad. Para ver el inventario completo de la infraestructura y la referencia base de dimensionamiento, consulte Requisitos previos.

​
Antes de comenzar

Tenga listos los siguientes valores y recursos: También necesita:
  • Un registro DNS para $your_vantage_hostname que se resuelva al punto de entrada de su ingress.
  • Un certificado TLS válido para ese nombre de host.
  • Secrets de extracción del registro de Kubernetes cuando su registro requiera autenticación.
  • Cada Secret de la aplicación que aparece en Alias de Secret.
  • Un nombre de base de datos lógico distinto para cada alias de base de datos. El migrador de cada servicio crea su base de datos en la primera ejecución.
  • Nodos etiquetados para los workers de TechCore.

​
Preparar el clúster

​
Configurar ArgoCD

Instala ArgoCD y habilita ApplicationSet Progressive Syncs. ArgoCD también necesita una conexión a un repositorio OCI desde el que pueda extraer los charts de componentes de Vantage del registro de destino. Registra el registro de destino como un repositorio Helm OCI siguiendo la documentación de repositorios privados de ArgoCD. Mantén las credenciales del registro en tu sistema de gestión de secretos existente, en lugar de colocarlas directamente en un manifiesto de Application de ArgoCD.

​
Configure la malla de servicios

Vantage requiere mTLS entre sus cargas de trabajo. Instale y administre una malla de servicios compatible y, a continuación, habilite la inyección del mesh para $install_namespace antes de instalar Vantage. Por ejemplo, con Linkerd:
Confirme que a los pods de prueba recién creados en el namespace se les inyecte el sidecar de la mesh antes de continuar. Si usa otra mesh, siga su procedimiento de inyección en el namespace o en la carga de trabajo.

​
Configurar los nodos worker de TechCore

Las cargas de trabajo de los workers de TechCore seleccionan nodos con la siguiente etiqueta:
Sin al menos un nodo coincidente, los pods de TechCore permanecen en Pending. Para el aislamiento de training-worker y la base de referencia de dimensionamiento, consulte requisitos de los nodos de Kubernetes.

​
Configurar el almacenamiento persistente

Cree o seleccione una StorageClass antes de instalar Vantage. La implementación de almacenamiento debe cumplir sus requisitos de producción en cuanto a disponibilidad, durabilidad, capacidad, expansión, copia de seguridad y recuperación. Inclúyala en los valores de Vantage:
El nombre de StorageClass es independiente de la distribución de Kubernetes. No copie la clase de almacenamiento local de un clúster de desarrollo a producción sin evaluar las características de pérdida de datos y conmutación por error.

​
Preparar las bases de datos

Vantage es compatible con SQL Server y PostgreSQL. Configure el proveedor exactamente como se muestra; el valor distingue entre mayúsculas y minúsculas:
Los valores válidos son SqlServer y PostgreSQL. Un valor como Postgresql o PostgreSql puede fallar en tiempo de ejecución porque no coincide con el nombre del proveedor de datos de la aplicación. Cada servicio de Vantage debe usar una base de datos lógica distinta. Los servicios ejecutan sus propias migraciones, y hacer que varios servicios apunten a una misma base de datos provoca conflictos en su estado de migración. Use el inventario de bases de datos en Alias de bases de datos para planificar los nombres de las bases de datos y las cadenas de conexión. No necesita crear las bases de datos manualmente: el migrador de cada servicio crea su base de datos en la primera ejecución.
La generación de informes está disponible solo con SQL Server. Al usar PostgreSQL, deje vantage.reportingEnabled establecido en false.
Las cadenas de conexión de PostgreSQL deben estar en una sola línea, sin caracteres de nueva línea al principio, al final ni en medio.

​
Preparar secretos de Kubernetes

El proveedor de secretos de Kubernetes lee recursos Secret nativos de Kubernetes en $install_namespace. Vantage no se conecta directamente a Vault ni a ningún otro almacén externo de secretos. Si usa External Secret Operator, un controlador CSI u otra herramienta de sincronización, configúrelo para que cree los secretos de Kubernetes necesarios antes de instalar Vantage. Seleccione el proveedor de Kubernetes:
De forma predeterminada, Vantage usa sus nombres de Secret documentados. Use objects para asociar un alias con un Secret diferente:
Los dos pares de claves de autenticación firman los tokens de la aplicación. Son independientes del certificado que termina las conexiones HTTPS públicas en el controlador de ingress. Consulte Alias de certificados para conocer las claves y los formatos requeridos. Cuando varios servicios consuman la clave genérica Database__ConnectionString, cree un Secret independiente para cada servicio y asigne cada alias de base de datos mediante vantage.secrets.kubernetes.objects. Su sistema de gestión de secretos puede generar estos Secret a partir de una plantilla común de cadena de conexión, pero cada cadena de conexión resultante debe especificar una base de datos distinta.
El operador valida la configuración de los secretos durante la comprobación previa. Los charts vantage-operator y vantage-selfhosted correspondientes conceden al operador acceso de lectura a los Secret mediante un ClusterRole asociado solo en el namespace de la release de Vantage. Si personaliza el namespace del operador o la ServiceAccount del controlador, asegúrese de que los valores operator correspondientes en el chart de Vantage coincidan con esa instalación. Una restricción resourceNames personalizada debe incluir cada Secret al que haga referencia el proveedor de Kubernetes.

​
Configurar el acceso al registro

El acceso al registro tiene tres consumidores independientes: Cree secrets del registro en el namespace donde se ejecuta cada consumidor. No incluya contraseñas del registro en texto sin formato en su archivo de valores. Para la migración de OCI, haga referencia a los secrets de credenciales de origen y de destino:
Añade el Secret de extracción del registro de destino a imagePullSecrets de la ServiceAccount indicada por vantage.serviceAccountName, la ServiceAccount predeterminada de las cargas de trabajo de Vantage.
Si un pod de un componente se ejecuta con otra ServiceAccount, esa ServiceAccount también necesita acceso de extracción al registro. Comprueba spec.serviceAccountName del pod antes de cambiar la ServiceAccount default del namespace.

​
Configurar el autoescalado y las métricas

El soporte de KEDA es opcional, pero se recomienda. Use KEDA 2.17.3: KEDA 2.18 y las versiones posteriores eliminaron un campo del escalador que usan los charts actuales de carga de trabajo de Vantage y no pueden crear los HPA necesarios. Algunos recursos ScaledObject de Vantage consultan Prometheus en esta dirección fija:
Antes de habilitar KEDA:
  1. Instale KEDA 2.17.3.
  2. Instale Prometheus Operator y una instancia de Prometheus en el namespace observability.
  3. Confirme que el Service asociado se llame prometheus-operated y exponga el puerto 9090.
  4. Configure Prometheus para que descubra el ServiceMonitor de Vantage.
Habilite KEDA en el recurso Vantage y habilite el ServiceMonitor del chart mediante la sección independiente observability de nivel superior:
observability es una clave de nivel superior; no la anide dentro de vantage. Para las estrategias de activación, la verificación y la planificación de capacidad, consulte Escalado automático con KEDA. Para la configuración de scraping específica de la mesh, consulte Monitorización con Prometheus.

​
Configurar ingress y TLS

El ingress integrado del chart es para Istio. Si usa Traefik u otro controlador de ingress, desactívelo:
La configuración de ingress debe:
  • Terminar HTTPS para vantage.dnsRecord con un certificado de confianza.
  • Enrutar las rutas de Vantage UI, API, autenticación, help, SCIM, acortador de URL, workspace, verificación y Try Any Skill a sus Services correspondientes.
  • Aplicar las reescrituras de /api/vN/ a /publicapi/vN/, /api/, SCIM y heartbeat que usa Vantage.
  • Hacer coincidir las rutas más específicas antes de la ruta comodín de la UI.
  • Reenviar el host y el esquema originales, incluido X-Forwarded-Proto: https cuando TLS termina en el controlador de ingress.
Traefik implementa estos requisitos con un IngressRoute y resources de Middleware ordenados. Trate el manifiesto de rutas como una configuración versionada de Vantage: parametrice el nombre de host, el namespace, el Secret del certificado y los nombres de Service generados para su release, en lugar de copiar valores de otro entorno.

​
Contrato de enrutamiento

Resuelva los nombres de Kubernetes Service generados en $install_namespace y luego implemente estas rutas en el orden indicado. Las rutas con regex y las exactas deben tener prioridad sobre las rutas por prefijo y las rutas comodín. El chart de ingress integrado de Istio también bloquea /api/status y /api/status/config, que exponen información interna de estado que los clientes no necesitan. Se recomienda bloquear estas rutas, pero no es obligatorio para ejecutar Vantage. Si su controlador de ingress no puede devolver una respuesta de denegación directa, puede enrutar estas rutas a un backend de denegación dedicado antes de la regla general de /api.

​
Protocolo HTTPS reenviado

Cuando la terminación de TLS se realiza en un controlador de ingress y la conexión con el backend es HTTP, los servicios de autenticación de Vantage deben respetar X-Forwarded-Proto. Asegúrese de que la siguiente variable de entorno esté presente en los contenedores de la aplicación para auth-identity, auth-adminapi2, api-gateway y api-registry:
Si los charts de la carga de trabajo actual no permiten una anulación mediante variable de entorno, use su mecanismo estándar de mutación de admisión, como Kyverno o un webhook de mutación equivalente. Aplique la mutación antes de crear los pods de Vantage. De lo contrario, el documento de descubrimiento de OIDC puede anunciar endpoints http:// y fallará el inicio de sesión en el navegador.

​
Instalar el operador

Instale una instancia del operador en el clúster:
Si el registro del operador requiere un pull secret, agrega esta opción al comando antes de --wait:

​
Instalar Vantage

Cree un archivo de valores que combine la configuración preparada anteriormente. Este ejemplo abreviado muestra los valores específicos de una implementación self-managed; agregue los mapeos completos de Secret y las credenciales del registro para su entorno:
Instale el chart vantage-selfhosted correspondiente:
Después de que el operador cree los servicios de la carga de trabajo, aplique la configuración de su controlador de ingress y compruebe que el certificado TLS esté listo.

​
Supervisar la instalación

Espere a que el recurso personalizado muestre Ready:
A continuación, verifique las aplicaciones y las cargas de trabajo de ArgoCD generadas. No se guíe solo por Ready:
Si la migración de OCI está habilitada, supervísela por separado:
La instalación de la skill se ejecuta en un trabajo independiente y puede continuar después de que Vantage indique Ready:
Por último, confirma que:
  • Cada aplicación de ArgoCD generada esté Synced y Healthy.
  • Los pods de Vantage estén en ejecución y con la inyección de mesh aplicada.
  • Prometheus informe los objetivos de Vantage /metrics-text como UP.
  • Los recursos ScaledObject de KEDA estén Ready y que los valores de las métricas de HPA no sean <unknown>.
  • El documento de descubrimiento de OIDC y las redirecciones del navegador usen URL con https://.
  • Vantage esté disponible en https://$your_vantage_hostname.

​
Qué sigue

Secrets

Alias de Secrets de Kubernetes, pares de claves de autenticación y cadenas de conexión de bases de datos.

Monitorización

Configure Prometheus para extraer métricas de Vantage a través de la malla de servicios.

Solución de problemas

Diagnostique fallos del operador, la base de datos, el registro, el ingress y el escalado automático.

Actualización

Actualice conjuntamente el operador y los charts de Vantage.