> ## 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.

# Arquitectura

> Cómo el operador de Kubernetes de Vantage, el recurso personalizado de Vantage y ArgoCD funcionan juntos para instalar, configurar y actualizar Vantage 3.0 autoalojado.

Vantage 3.0 autoalojado se basa en tres componentes: un operador de Kubernetes, un único recurso personalizado visible para el usuario (`Vantage`) y ArgoCD. Se aplica un objeto `Vantage` que describe la instalación deseada; el operador reconcilia el estado de la instalación para que coincida con el recurso y delega en ArgoCD la sincronización de cada componente. Esta página explica conceptualmente cómo encajan estos elementos. Para obtener detalles a nivel de campo, consulte la [referencia de la API](/es/vantage/self-hosted/v3.0/api-reference).

<div id="why-this-pattern">
  ## Por qué este patrón
</div>

Vantage 2.7 autoalojado se ejecutaba con playbooks de Ansible proporcionados por ABBYY y scripts de Azure CLI que instalaban tanto la aplicación como la infraestructura de soporte de una sola vez. Ese modelo no es compatible con la versión 3.0. El operador de 3.0 separa las responsabilidades:

* **Infraestructura**: usted la aprovisiona fuera del alcance del operador. ABBYY no proporciona automatización del aprovisionamiento para 3.0.
* **Aplicación**: descrita de forma declarativa en el recurso `Vantage`. El operador se encarga de la resolución de dependencias de los componentes de Vantage Core, la migración de artefactos y la reconciliación mediante ArgoCD.

El software de terceros del que depende Vantage, como ArgoCD, su service mesh y su controlador de ingress, su integración de secretos y su pila de monitorización, queda fuera de ambos ámbitos: debe instalarlo usted mismo antes de instalar Vantage.

El resultado: las actualizaciones se realizan instalando nuevas versiones correspondientes de los Helm charts `vantage-operator` y `vantage-selfhosted`.

<div id="the-vantage-custom-resource">
  ## El recurso personalizado `Vantage`
</div>

La CRD está registrada en `vantage.abbyy.com/v1alpha1`. Un recurso mínimo se ve así (a modo ilustrativo; consulte la [referencia de la API](/es/vantage/self-hosted/v3.0/api-reference) para consultar la especificación completa):

```yaml theme={null}
apiVersion: vantage.abbyy.com/v1alpha1
kind: Vantage
metadata:
  name: vantage
  namespace: vantage
spec:
  dnsRecord: vantage.example.com
  mailFrom: noreply@example.com
  platformAdminEmail: admin@example.com
  vantageVersion: "3.0.x"
  secrets:
    azure:
      keyVaultName: mykeyvault
      tenantId: 00000000-...
      clientId: 00000000-... # ID de cliente de la UAMI con acceso de lectura a Key Vault
      identityMode: workloadIdentity # workloadIdentity (predeterminado) | podIdentity | vmManagedIdentity
  smtp:
    host: smtp.example.com
    port: 587
  workloads:
    configMap: vantage-workloads
    metadataTemplateKey: metadata
    secretsKey: secrets
    workloadsKey: workloads
```

`spec.secrets` es obligatorio y se debe especificar exactamente un proveedor (`azure` o `kubernetes`). `spec.smtp` es opcional; omítalo para usar el proveedor de correo predeterminado de SendGrid (proporcione una `sendgridApiKey` mediante su proveedor de secretos). Consulte [Secretos y Key Vault](/es/vantage/self-hosted/v3.0/secrets-and-keyvault) para ver los proveedores admitidos.

En la práctica, la mayoría de estos valores se configuran mediante el Helm chart `vantage-selfhosted`. Consulte [Azure](/es/vantage/self-hosted/v3.0/providers/azure) o [Kubernetes autogestionado](/es/vantage/self-hosted/v3.0/providers/self-managed).

<div id="key-concepts">
  ## Conceptos clave
</div>

<div id="workloads-configmap">
  ### ConfigMap de cargas de trabajo
</div>

`spec.workloads` indica al operador el `ConfigMap` que contiene el manifiesto de charts e imágenes que componen una versión de Vantage. El operador lee este manifiesto, ejecuta la migración de OCI para copiar los artefactos a su registro y luego genera manifiestos `Application` de ArgoCD para cada componente. ABBYY compila y publica el ConfigMap como parte de cada lanzamiento de Vantage.

<div id="secrets-and-certificates">
  ### Secretos y certificados
</div>

El operador no almacena secretos directamente. Se admiten dos proveedores de secretos (Azure Key Vault mediante el controlador Secrets Store CSI y recursos `Secret` de Kubernetes ya existentes), y solo se configura uno por instalación. Consulte [Secretos y Key Vault](/es/vantage/self-hosted/v3.0/secrets-and-keyvault) para ver los proveedores admitidos, los modos de identidad y el inventario completo de alias.

<div id="oci-migration">
  ### Migración de OCI
</div>

`spec.ociMigration` declara un trabajo de una sola ejecución que copia artefactos desde uno o varios registros de origen configurados a su registro de destino antes de la instalación. Una vez completada la migración, todas las extracciones posteriores de componentes se realizan desde su propio registro. ArgoCD extrae los charts de los componentes de ese registro mediante una conexión de repositorio que usted mismo configura. La autenticación del destino admite sin autenticación, autenticación básica o Azure Workload Identity con Azure RBAC. Las cargas de trabajo también necesitan acceso de extracción mediante Secrets de extracción de imágenes de Kubernetes o, en Azure, `AcrPull` concedido a la identidad administrada de AKS. Consulte [acceso de extracción de imágenes de Azure](/es/vantage/self-hosted/v3.0/providers/azure#image-pull-access) o [acceso al registro autogestionado](/es/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access).

<div id="skill-installation">
  ### Instalación de skills
</div>

Los skills se instalan mediante un trabajo de Kubernetes independiente en el namespace de instalación, no mediante una de las aplicaciones de ArgoCD generadas por el operador, por lo que ArgoCD no muestra el progreso de la instalación de skills. El recurso `Vantage` puede indicar `Ready` mientras el trabajo sigue ejecutándose, y Vantage se puede usar mientras tanto. Los comandos de monitorización están en [Ciclo de vida](/es/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately).

<div id="runtime-contract">
  ## Contrato del Runtime
</div>

El contrato del Runtime del operador (cómo procesa el recurso `Vantage`, qué condiciones vuelve a publicar y cómo forzar un reintento) se documenta por separado de esta visión general conceptual. Consulte [Lifecycle](/es/vantage/self-hosted/v3.0/lifecycle).

<div id="whats-next">
  ## Qué sigue
</div>

<CardGroup cols={2}>
  <Card title="Referencia de la API" icon="code" href="/es/vantage/self-hosted/v3.0/api-reference">
    Referencia campo por campo de cada propiedad de spec y status.
  </Card>

  <Card title="Ciclo de vida" icon="arrows-rotate" href="/es/vantage/self-hosted/v3.0/lifecycle">
    Fases de reconciliación, condiciones de estado y cómo forzar un reintento.
  </Card>

  <Card title="Valores del Helm chart" icon="screwdriver-wrench" href="/es/vantage/self-hosted/v3.0/helm-chart">
    Referencia de todos los valores de Helm que aceptan los charts del operador y de Vantage.
  </Card>

  <Card title="Solución de problemas" icon="stethoscope" href="/es/vantage/self-hosted/v3.0/troubleshooting">
    Diagnóstico de problemas comunes del operador, ArgoCD, secrets, base de datos, ingress y mesh.
  </Card>
</CardGroup>