> ## 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. # Kubernetes autogestionado > Implemente Vantage 3.0 autoalojado en una infraestructura de Kubernetes que usted aprovisiona y opera. 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
| Aspecto | Requisito de Vantage | Implementación de ejemplo | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Kubernetes | Una versión compatible de Kubernetes con DNS, red y volúmenes persistentes en funcionamiento. | Kubernetes administrado por usted. | | Orquestación de la implementación | ArgoCD con ApplicationSet Progressive Syncs habilitado. | ArgoCD 3.4.3. | | Malla de servicios | mTLS entre cargas de trabajo en el namespace de Vantage. | Linkerd. | | ingress | Un ingress HTTPS que implemente la ruta y el contrato de reescritura de Vantage y conserve el esquema original de la solicitud. | Traefik con cert-manager. | | Secrets | Recursos `Secret` nativos de Kubernetes en el namespace de Vantage. | External Secrets Operator que materializa Secrets desde HashiCorp Vault. | | Base de datos | SQL Server o PostgreSQL, con una base de datos lógica independiente para cada servicio de Vantage. | PostgreSQL. | | Caché | Redis. | Redis 7.4. | | Correo | SendGrid de forma predeterminada o un servidor SMTP. | SendGrid. | | Almacenamiento | Una `StorageClass` de Kubernetes preexistente adecuada para sus requisitos de disponibilidad y durabilidad. | Una clase de almacenamiento persistente proporcionada por el cliente. | | Registros | Un registro de origen suministrado para los artifacts de Vantage y un registro de destino administrado por usted. | Cualquier registro privado compatible con OCI. | | Escalado automático y métricas | KEDA más Prometheus cuando la compatibilidad con KEDA está habilitada. | KEDA 2.17.3 y Prometheus Operator. | Para conocer las versiones de componentes compatibles y probadas, consulte [Compatibilidad](/es/vantage/self-hosted/v3.0/compatibility). Para ver el inventario completo de la infraestructura y la referencia base de dimensionamiento, consulte [Requisitos previos](/es/vantage/self-hosted/v3.0/prerequisites).
## Antes de comenzar
Tenga listos los siguientes valores y recursos: | Variable | Descripción | | -------------------------------------------------------- | ------------------------------------------------------------------------------- | | `$operator_namespace` | Namespace para el operador de Vantage. | | `$install_namespace` | Namespace para las cargas de trabajo de Vantage. | | `$operator_version` | Versión del chart `vantage-operator`. Use `0.70.13` para esta guía. | | `$selfhosted_version` | Versión del chart `vantage-selfhosted`. Use `0.70.13` para esta guía. | | `$charts_uri` | URI de OCI que ABBYY proporciona para el chart del operador de Vantage. | | `$chart_uri` | URI de OCI que ABBYY proporciona para el chart `vantage-selfhosted`. | | `$release_name` | Nombre de la release de Helm para Vantage. | | `$your_vantage_hostname` | Nombre de host DNS para Vantage. | | `$your_mailfrom` | Dirección del remitente para el correo saliente. | | `$your_platformadmin_email` | Correo electrónico inicial del administrador de la plataforma. | | `$your_oci_host` | Registro OCI de destino que usted administra. | | `$abbyy_oci_source_host`, `$abbyy_oci_source_repository` | Registro y repositorio de origen proporcionados para los artefactos de Vantage. | 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](/es/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases). * 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](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-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](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/). 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: ```bash theme={null} kubectl create namespace $install_namespace --dry-run=client -o yaml | kubectl apply -f - kubectl label namespace $install_namespace linkerd.io/inject=enabled --overwrite ``` 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: ```bash theme={null} kubectl label node k8s.abbyy.com/techcore=true ``` 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](/es/vantage/self-hosted/v3.0/prerequisites#kubernetes-node-requirements).
### 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: ```yaml theme={null} vantage: storage: custom: storageClass: size: 300Gi ``` 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: ```yaml theme={null} vantage: databaseProvider: PostgreSQL ``` 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](/es/vantage/self-hosted/v3.0/secrets-and-keyvault#databases) 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: ```yaml theme={null} vantage: secrets: kubernetes: {} ``` De forma predeterminada, Vantage usa sus nombres de Secret documentados. Use `objects` para asociar un alias con un Secret diferente: ```yaml theme={null} vantage: secrets: kubernetes: objects: authSigningTlsCrt: secretName: vantage-auth-signing authSigningTlsKey: secretName: vantage-auth-signing authDeactivatedTlsCrt: secretName: vantage-auth-deactivated authDeactivatedTlsKey: secretName: vantage-auth-deactivated subscriptionDatabaseConnectionString: secretName: vantage-db-subscriptions ``` 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](/es/vantage/self-hosted/v3.0/secrets-and-keyvault#certificate-aliases) 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: | Consumer | Required access | | ------------------------------------- | ------------------------------------------------------------------------------------------------ | | Vantage operator | Extraer la imagen del operador. Configure `manager.imagePullSecrets` cuando sea necesario. | | trabajo de migración de OCI | Extraer la imagen del trabajo, leer del registro de origen y escribir en el registro de destino. | | cargas de trabajo de Vantage y ArgoCD | Extraer imágenes de cargas de trabajo y charts de componentes del registro de destino. | 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: ```yaml theme={null} vantage: ociMigration: enabled: true serviceAccountName: imagePullSecrets: - name: sources: - host: repository: credentialsRef: name: destination: host: credentialsRef: name: ``` 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: ```text theme={null} http://prometheus-operated.observability.svc.cluster.local:9090 ``` 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: ```yaml theme={null} vantage: keda: enabled: true observability: prometheus: namespace: observability serviceMonitor: create: true ``` `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](/es/vantage/self-hosted/v3.0/performance/autoscaling). Para la configuración de scraping específica de la mesh, consulte [Monitorización con Prometheus](/es/vantage/self-hosted/v3.0/monitoring/prometheus).
## Configurar ingress y TLS
El ingress integrado del chart es para Istio. Si usa Traefik u otro controlador de ingress, desactívelo: ```yaml theme={null} ingress: enabled: false ``` 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. | Ruta pública | Componente de Vantage | Reescritura o comportamiento | | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------- | ------------------------------------------------------------------------------------ | | `^/api/v[0-9]+(/\|$)` | puerta de enlace de API | Reescriba `/api/vN/...` a `/publicapi/vN/...`. | | `^/verification/(markup\|manualreview)//notifications` | Verification | Sin reescritura. | | `^/workspace/(v1/files\|skilloperations/notifications\|projects//notifications\|skills//notifications\|catalogoperations/notifications)` | Workspace | Sin reescritura. | | `/api/heartbeat/scenarios` | Heartbeat | Reescriba a `/api/scenarios`. | | Exacta `/try-any-skill` | Try Any Skill | Redirija permanentemente a `/try-any-skill/`. | | `/try-any-skill/` | Try Any Skill | Sin reescritura. | | `/ad/` y `/ss/` | frontend de AD | Sin reescritura; use el puerto de Service expuesto por la carga de trabajo generada. | | `/auth2` | identidad de Auth | Sin reescritura. | | `/help` | Documentación | Sin reescritura. | | `/scim/` | adaptador SCIM | Elimine el prefijo `/scim`. | | `/surl` | acortador de URL | Sin reescritura. | | `/api` y `/api/` | puerta de enlace de API | Elimine el prefijo `/api`. | | `/` | frontend de Vantage | Ruta comodín; evalúela al final. | 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`: ```text theme={null} ASPNETCORE_FORWARDEDHEADERS_ENABLED=true ``` 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: ```bash theme={null} helm upgrade --install vantage-operator $charts_uri/vantage-operator \ --version 0.70.13 \ --namespace $operator_namespace \ --create-namespace \ --wait ``` Si el registro del operador requiere un pull secret, agrega esta opción al comando antes de `--wait`: ```bash theme={null} --set "manager.imagePullSecrets[0].name=" ```
## 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: ```yaml theme={null} operator: namespace: ingress: enabled: false vantage: dnsRecord: mailFrom: platformAdminEmail: serviceAccountName: databaseProvider: PostgreSQL reportingEnabled: false updatePolicy: manual: {} secrets: # Agregue un mapeo de objects cuando los nombres de sus Secret difieran de los predeterminados. kubernetes: {} storage: custom: storageClass: size: 300Gi keda: enabled: true ociMigration: enabled: true serviceAccountName: imagePullSecrets: - name: sources: - host: repository: credentialsRef: name: destination: host: credentialsRef: name: observability: prometheus: namespace: observability serviceMonitor: create: true ``` Instale el chart `vantage-selfhosted` correspondiente: ```bash theme={null} helm upgrade --install $release_name $chart_uri/vantage-selfhosted \ --version 0.70.13 \ --namespace $install_namespace \ --create-namespace \ --values values-self-managed.yaml \ --wait ``` 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`: ```bash theme={null} kubectl -n $install_namespace wait \ --for=condition=Ready vantages.vantage.abbyy.com/$release_name \ --timeout=30m ``` A continuación, verifique las aplicaciones y las cargas de trabajo de ArgoCD generadas. No se guíe solo por `Ready`: ```bash theme={null} argocd app list -l vantage.abbyy.com/managed-by=vantage-operator kubectl -n $install_namespace get pods kubectl -n $install_namespace get scaledobjects,hpa ``` Si la migración de OCI está habilitada, supervísela por separado: ```bash theme={null} kubectl -n $install_namespace wait --for=create job/$release_name-oci-migration --timeout=2m kubectl -n $install_namespace wait --for=condition=Complete job/$release_name-oci-migration --timeout=20m ``` La instalación de la skill se ejecuta en un trabajo independiente y puede continuar después de que Vantage indique `Ready`: ```bash theme={null} kubectl -n $install_namespace wait --for=create job/$install_namespace-skill-installer-job kubectl -n $install_namespace wait --for=condition=Complete job/$install_namespace-skill-installer-job ``` 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 ``. * 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
Alias de Secrets de Kubernetes, pares de claves de autenticación y cadenas de conexión de bases de datos. Configure Prometheus para extraer métricas de Vantage a través de la malla de servicios. Diagnostique fallos del operador, la base de datos, el registro, el ingress y el escalado automático. Actualice conjuntamente el operador y los charts de Vantage.