AWS S3 como almacenamiento de objetos
En entornos cloud o cuando se dispone de buckets en AWS S3, el kit puede configurarse para usar S3 directamente en lugar de SeaweedFS.
Para activar el modo AWS S3, modifica el fichero de values:
global:
cdnProxy:
mode: aws_s3
bucket: "anjana-prod-cdn"
aws_s3:
region: "eu-central-1"
anjana-persistences:
seaweedfs:
enabled: false
Las credenciales de acceso a S3 (persistences.s3.access_key y persistences.s3.secret_key) deben estar presentes en el bundle anjana-secrets. Más detalles sobre la configuración pueden encontrarse en Avanzado k8s, apartado Buckets en AWS S3.
RECOMENDADO: el uso de buckets en AWS S3 para entornos de producción cloud. En entornos con IRSA (EKS), las credenciales de S3 se gestionan automáticamente mediante el IAM Role asignado.
SeaweedFS como almacenamiento local
Para entornos on-premise o de laboratorio, el kit incluye SeaweedFS como solución S3-compatible en cluster.
Para activar SeaweedFS, modifica el fichero de values:
global:
cdnProxy:
mode: seaweedfs
seaweedfs:
endpoint: "https://seaweedfs:8333"
anjana-persistences:
enabled: true
seaweedfs:
enabled: true
storage:
type: pvc # hostPath | pvc | emptyDir
claimName: seaweedfs-data
Tras el primer despliegue, crea los buckets necesarios (ver Avanzado k8s, apartado SeaweedFS - Gestión de buckets).
NOTA: Las persistencias dentro de Kubernetes NO soportan HA por naturaleza. ✅RECOMENDADO: usar persistencias cloud (S3, RDS) en producción.
PostgreSQL RDS como sustituto de PostgreSQL
La conexión a un RDS no requiere prácticamente diferencias en la configuración, dado que la cadena de conexión es compatible directamente.
Para usar RDS, deshabilita el StatefulSet de PostgreSQL en cluster y apunta al RDS en el bundle de credenciales:
anjana-persistences:
postgresql:
enabled: false
# En horus.env (antes de ejecutar anjana horus update)
persistences.bbdd.url=my-rds.eu-central-1.rds.amazonaws.com:5432/anjana
persistences.bbdd.user=anjana
persistences.bbdd.pass=<contraseña>
Más detalles pueden encontrarse en Avanzado k8s, apartado PostgreSQL en RDS.
Despliegue de entorno HA
Para el despliegue en modo High Availability de Anjana, se realiza un despliegue normal siguiendo los 3 pasos del Manual de despliegue. Una vez el entorno está completamente operativo, se escalan los microservicios deseados:
kubectl scale deployment/portuno --replicas=2 -n anjana-data
kubectl scale deployment/kerno --replicas=2 -n anjana-data
kubectl scale deployment/minerva --replicas=2 -n anjana-data
# ... otros servicios según el SLA requerido
Para verificar que los pods HA han quedado distribuidos en nodos distintos:
kubectl get pods -n anjana-data -o wide
IMPORTANTE: Esperar a que el entorno esté completamente operativo antes de aplicar el escalado. Los microservicios dependen de Horus para su configuración; escalar antes de que estén listos puede provocar reinicios consecutivos.
NOTA: El microservicio Horus ya se encuentra escalado a 2 réplicas por defecto (StatefulSet). Dada la naturaleza del Config Server, es ✅RECOMENDADO dejarlo siempre en esa configuración.
Para que el escalado persista entre upgrades de Helm, ajusta el campo replicas de cada servicio en el listado anjana-core.core de tu fichero de values override. Consulta el fichero charts/anjana-core/values.yaml del kit para ver la estructura completa de cada entrada.
Para verificar el estado tras el escalado:
kubectl get pods -n anjana-data
Despliegue cloud completo (EKS + IRSA + AWS Secrets Manager)
En entornos EKS con AWS Secrets Manager, el kit puede configurarse para que Horus lea la configuración directamente de AWS SM mediante IRSA, sin necesidad de crear anjana-secrets manualmente.
Configura el fichero de values para el modo cloud:
global:
horus:
aws:
region: "eu-central-1"
prefix: "/secret/prod"
serviceAccountName: "horus-prod-sm-sa"
iamRoleArn: "arn:aws:iam::<AccountID>:role/<RoleName>"
config:
cloud: true
secrets_backend:
aws_secrets_manager:
enabled: true
config_server:
aws_secrets_manager:
enabled: true
anjana-persistences:
enabled: false # usar RDS, DocumentDB, ElastiCache, Amazon MQ
En este modo, el config-init-job no se renderiza (la configuración viene de AWS SM), y las persistencias son servicios gestionados externos al cluster.
Activación de un conector (plugin)
Para conectar Anjana con una fuente de datos externa (por ejemplo una base de datos vía JDBC), activa el conector correspondiente en el fichero de values y aplica el upgrade:
anjana-plugins:
enabled: true
global:
version:
plugins:
tp-jdbc: "5.2.0"
Marca además enabled: true en la entrada del conector en charts/anjana-plugins/values.yaml y ejecuta:
helm upgrade anjana-platform . -f values-<env>.yaml -n anjana-data --wait
La lista completa de los 18 conectores disponibles y las opciones de configuración standalone están en Avanzado k8s, apartado Activación de plugins (conectores).