Descripción general de Cloud Native¶
KanjiIQ está diseñado siguiendo principios cloud-native, haciéndolo portable a cualquier plataforma compatible con Kubernetes. La aplicación usa APIs estándar de Kubernetes sin extensiones propietarias de proveedores de nube.
Alineación con la aplicación de 12 factores¶
| Factor | Implementación en KanjiIQ |
|---|---|
| I. Base de código | Repositorio Git único (Forgejo) rastreado con control de versiones |
| II. Dependencias | Declaradas explícitamente en pubspec.yaml (Dart) y requirements-docs.txt (Python) |
| III. Configuración | Variables de entorno inyectadas mediante Kubernetes Secrets y ConfigMaps |
| IV. Servicios de respaldo | PostgreSQL accesible vía DATABASE_URL — intercambiable sin cambios de código |
| V. Compilar, lanzar, ejecutar | Compilaciones Docker multi-etapa -> imágenes etiquetadas -> rolling updates de Kubernetes |
| VI. Procesos | Contenedores de aplicación sin estado; el estado reside en PostgreSQL |
| VII. Asignación de puertos | Servicios autocontenidos: frontend en :80, backend en :8080 |
| VIII. Concurrencia | Escalado horizontal mediante réplicas de Kubernetes |
| IX. Desechabilidad | Arranque rápido, cierre elegante, sondas de salud |
| X. Paridad desarrollo/producción | El namespace de staging refleja los manifiestos de producción |
| XI. Logs | Stdout/stderr (Kubernetes captura al sistema de archivos del nodo) |
| XII. Procesos de administración | Las migraciones de base de datos se ejecutan como comandos puntuales |
¿Qué hace a KanjiIQ cloud-native?¶
Solo APIs estándar de Kubernetes¶
Todos los recursos usan los grupos de API estándar apps/v1, v1 y networking.k8s.io/v1:
Deployment(no servicios gestionados específicos de la nube)Service(ClusterIP — funciona en todas partes)Ingress(API de red estándar)PersistentVolumeClaim(solicitud de almacenamiento agnóstica de la nube)Secret(gestión de configuración estándar)
Los únicos CRDs no estándar son los Middlewares de Traefik — que pueden reemplazarse por funciones equivalentes del controlador de ingress en cualquier plataforma.
Todo contenerizado¶
Cada componente tiene un Dockerfile listo para producción:
| Componente | Dockerfile | Imagen base |
|---|---|---|
| Frontend | Dockerfile.frontend |
nginx:alpine |
| Backend | Dockerfile.backend |
dart:stable |
| Documentación | Dockerfile.docs |
nginx:alpine |
Todas las imágenes:
- Usan compilaciones multi-etapa (imágenes de producción pequeñas)
- Se ejecutan como non-root (UID 1000)
- Incluyen health checks
- Se publican en un registro de contenedores (portable a cualquier registro)
Infraestructura como código¶
El 100% de la infraestructura está definida en YAML bajo control de versiones:
k8s/
├── 00-namespace.yaml
├── 01-secrets.yaml (template)
├── 02-postgres-pvc.yaml
├── 03-postgres-deployment.yaml
├── 05-deployment.yaml
├── 06-service.yaml
├── 07-ingress.yaml
├── 08-security-middlewares.yaml
└── ...
Recrear todo el entorno desde cero solo requiere:
Evaluación de portabilidad¶
| Componente | Portabilidad | Notas |
|---|---|---|
| Deployments de aplicación | Totalmente portable | Manifiestos k8s estándar |
| Services | Totalmente portable | ClusterIP funciona en todas partes |
| Ingress | Mayormente portable | Puede necesitar cambio de clase de ingress |
| PVC | Totalmente portable | Los proveedores de nube auto-aprovisionan almacenamiento |
| Secrets | Totalmente portable | Misma API en todas las nubes |
| Middlewares de Traefik | Requiere adaptación | Reemplazar con alternativas cloud-native |
| Imágenes de contenedores | Totalmente portable | Publicar en cualquier registro OCI |
| CI/CD | Requiere adaptación | Forgejo Actions -> GitHub Actions / Cloud Build |
Consulta Portabilidad para guías detalladas de migración a AWS y GCP.