Portabilidad en la nube¶

Los manifiestos de Kubernetes de KanjiIQ son aproximadamente 90% portables entre proveedores de nube. Esta página detalla la ruta de migración a AWS y GCP, destacando lo que permanece igual y lo que necesita cambiar.

Lo que permanece igual (en todas partes)¶

Estos recursos funcionan de forma idéntica en cualquier clúster de Kubernetes compatible con CNCF:

Deployments: Specs de pod, definiciones de contenedores, límites de recursos, sondas de salud
Services: Servicios ClusterIP, mapeo de puertos, selectores
Secrets: Secrets opacos con stringData
PersistentVolumeClaims: Solicitudes de almacenamiento (los proveedores de nube gestionan el resto)
Namespaces: Límites de aislamiento
Imágenes Docker: Compatibles con OCI, se ejecutan en cualquier runtime de contenedores

Migración a AWS (EKS)¶

Mapeo de arquitectura¶

graph TB
    subgraph Current["Current: Hetzner k3s"]
        A1[k3s] --> A2[Traefik]
        A1 --> A3[PostgreSQL on k8s]
        A1 --> A4[Forgejo Registry]
        A1 --> A5[cert-manager]
    end

    subgraph AWS["Target: AWS EKS"]
        B1[EKS] --> B2[ALB Ingress Controller<br/>or Traefik]
        B1 --> B3[RDS PostgreSQL]
        B1 --> B4[ECR]
        B1 --> B5[ACM<br/>or cert-manager]
    end

    Current -.->|Migration| AWS

Componente por componente¶

Actual	Equivalente en AWS	Cambio requerido
k3s	EKS	Aprovisionamiento del clúster (eksctl/Terraform)
Traefik	ALB Ingress Controller o mantener Traefik	Cambio de anotaciones del Ingress
PostgreSQL en k8s	RDS	Actualizar el secret `DATABASE_URL`; eliminar manifiestos PG
Forgejo Registry	ECR	Actualizar URLs de imágenes en Deployments; actualizar CI/CD
cert-manager	ACM	Reemplazar anotaciones de cert-manager con ARN de ACM
Forgejo Actions	GitHub Actions o CodePipeline	Reescribir archivos de flujo de trabajo
PV local	EBS (gp3)	PVC funciona tal cual; EKS auto-aprovisiona EBS

Cambios en manifiestos¶

Ingress (si se cambia a ALB):

# Before (Traefik)
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
spec:
  ingressClassName: traefik

# After (AWS ALB)
metadata:
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
spec:
  ingressClassName: alb

Base de datos (cambio a RDS):

# Update the secret with RDS endpoint
stringData:
  database-url: "postgresql://user:[email protected]:5432/jlpt_flashcard"

Luego eliminar 02-postgres-pvc.yaml y 03-postgres-deployment.yaml — RDS se encarga de todo.

Esfuerzo estimado¶

Configuración del clúster: 1-2 días (EKS + red)
Adaptación de manifiestos: 1 día (ingress, secrets, URLs de imágenes)
Reescritura de CI/CD: 1 día (GitHub Actions o CodePipeline)
Migración de datos: 1 día (pg_dump -> importación a RDS)
Cambio de DNS: 1 hora
Total: ~4-5 días

Migración a GCP (GKE)¶

Mapeo de componentes¶

Actual	Equivalente en GCP	Cambio requerido
k3s	GKE	Aprovisionamiento del clúster (gcloud/Terraform)
Traefik	GKE Ingress o mantener Traefik	Cambio de anotaciones del Ingress
PostgreSQL en k8s	Cloud SQL	Actualizar `DATABASE_URL`; eliminar manifiestos PG
Forgejo Registry	Artifact Registry	Actualizar URLs de imágenes
cert-manager	Certificados gestionados por Google o mantener cert-manager	Cambio de anotaciones
Forgejo Actions	Cloud Build o GitHub Actions	Reescribir pipelines
PV local	Persistent Disk	PVC funciona tal cual

Cambios en manifiestos¶

Ingress (GKE nativo):

metadata:
  annotations:
    networking.gke.io/managed-certificates: kanjiiq-cert
spec:
  ingressClassName: gce

Esfuerzo estimado¶

Configuración del clúster: 1-2 días
Adaptación de manifiestos: 1 día
Reescritura de CI/CD: 1 día
Migración de datos: 1 día
Total: ~4-5 días

Estrategia multi-nube¶

Para organizaciones que requieren despliegue multi-nube:

Mantener portable¶

Mantener Traefik en lugar de ingress cloud-native (funciona de forma idéntica en EKS, GKE, AKS)
Mantener cert-manager en lugar de ACM/Google certs (TLS agnóstico de la nube)
Mantener PostgreSQL en k8s si se quiere evitar dependencia de proveedor (contrapartida: mayor carga operativa)
Usar un registro agnóstico de la nube como Harbor (autoalojado, funciona con cualquier k8s)

Aceptar servicios de la nube¶

Para operaciones simplificadas, adoptar servicios gestionados por nube:

Base de datos: RDS (AWS) / Cloud SQL (GCP) — significativamente menos carga operativa
Registro: ECR (AWS) / Artifact Registry (GCP) — integración estrecha con IAM
TLS: ACM (AWS) / Managed Certs (GCP) — certificados sin mantenimiento

La elección correcta depende de si se prioriza la portabilidad (mantener agnóstico de la nube) o la simplicidad operativa (usar servicios gestionados).