KONFIDENTZIALTASUN-AKORDIOPEAN
Kubernetesekin modernizazioa Europako aseguru-etxe batean
6 ekoizpen-ingurune Kubernetes hibridora (on-premise + AWS EKS) migratu dira faseka, GitOps eta behagarritasunarekin, % 99,9ko erabilgarritasunari eutsiz.
Sektorea
Aseguruak · Nazioarteko aseguru-etxea (Europa)
Stack teknologikoa
Kubernetes, RKE2, Rancher Fleet, AWS EKS, GitOps, Prometheus, Grafana, Loki
Proiektuaren esparrua
- · RKE2 + Rancher on-premise hedapena eta AWS EKSrako hedapena
- · GitOps hartzea Rancher Fleetekin inguruneen arteko promoziorako
- · Behagarritasun osoa Prometheus, Grafana eta Lokirekin
- · Migrazio progresiboa azken bezeroari zerbitzua eten gabe
Eragin neurgarria
- · % 99,9 erabilgarritasuna migrazio osoan zehar
- · 6 ingurune migratuta kontrolatutako faseka
- · Azken arkitektura hibridoa (on-premise RKE2 + AWS EKS)
Contexto
Una aseguradora internacional con operaciones en Europa necesitaba migrar el core de sus aplicaciones a una plataforma de contenedores sin detener el servicio a sus asegurados. Seis entornos productivos, cada uno con sus dependencias, debían pasar de una infraestructura tradicional a Kubernetes híbrido: RKE2 con Rancher on-premise y extensión a AWS EKS.
La restricción principal no era técnica sino operativa: la migración debía convivir con la actividad diaria (emisión, siniestros, cierres) manteniendo la disponibilidad de los servicios durante toda la transición.
El reto
El punto de partida combinaba tres limitaciones habituales en el sector:
- Despliegues manuales y poco trazables entre entornos, con riesgo de desviaciones de configuración entre desarrollo, preproducción y producción.
- Ausencia de una capa de observabilidad común: cada entorno se supervisaba con herramientas distintas.
- Necesidad de escalar en la nube sin perder el control de los sistemas críticos que debían permanecer on-premise.
Enfoque por fases
Aplicamos el mismo método por fases que usamos en banca para plataformas Kubernetes híbridas, adaptado al calendario operativo de la aseguradora.
-
01
Análisis y diseño
Inventario de workloads, definición de la arquitectura híbrida y dimensionamiento de los seis entornos.
-
02
Despliegue on-premise
RKE2 y Rancher como base de orquestación, validando primero los servicios menos críticos.
-
03
Extensión a AWS EKS
Clústeres en AWS integrados con la plataforma on-premise mediante conectividad híbrida y una única consola de gestión.
-
04
GitOps con Rancher Fleet
Promoción declarativa entre entornos: cada cambio versionado, revisado y reproducible.
-
05
Observabilidad
Prometheus, Grafana y Loki para métricas, alertas y logs centralizados de todos los entornos.
-
06
Migración progresiva
Entorno a entorno, con validación funcional y ventana de reversión en cada fase, sin interrupción del servicio al cliente final.
Arquitectura y estrategia
La arquitectura final es híbrida: RKE2 on-premise para los sistemas que deben permanecer en el CPD de la aseguradora y AWS EKS para las cargas que se benefician de la elasticidad de la nube, orquestadas desde una única consola. GitOps con Rancher Fleet gobierna la promoción entre entornos y la capa de observabilidad es común a todos ellos.
Resultados medibles
Resultados al cierre de la migración:
| Indicador | Antes | Después |
|---|---|---|
| Disponibilidad durante la migración | Objetivo de continuidad | 99,9 % |
| Entornos productivos migrados | Infraestructura tradicional | 6, en fases controladas |
| Arquitectura | Silos on-premise | Híbrida: RKE2 on-premise + AWS EKS |
| Promoción entre entornos | Manual | GitOps declarativo (Rancher Fleet) |
Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.
Lecciones aplicables
- Migrar entorno a entorno, empezando por los menos críticos, reduce el riesgo y genera confianza para las fases siguientes.
- Una consola única para on-premise y cloud evita duplicar equipos y procedimientos.
- GitOps convierte cada despliegue en evidencia auditable, algo que el supervisor valora tanto como el equipo de operaciones.
Marco regulatorio
El uso de nube pública en una aseguradora europea se gobierna como externalización de un servicio crítico.
- DORA (Art. 28): riesgo de tercero tecnológico, reversibilidad y observabilidad de la plataforma híbrida.
- Solvencia II: continuidad de los procesos que alimentan el reporte al supervisor durante toda la migración.
Preguntas frecuentes
¿Qué stack se utilizó?
Kubernetes con RKE2 y Rancher on-premise, AWS EKS, GitOps con Rancher Fleet y observabilidad con Prometheus, Grafana y Loki.
¿Se interrumpió el servicio a los asegurados?
No. La migración se hizo entorno a entorno con validación funcional y ventana de reversión, manteniendo un 99,9 % de disponibilidad.
¿Por qué mantener parte on-premise?
Porque determinados sistemas debían permanecer en el CPD de la aseguradora por control y por exigencias de externalización. La plataforma híbrida permite escalar en AWS sin renunciar a ese control.
¿Puedo conocer la aseguradora y las cifras completas?
El caso está anonimizado por acuerdo de confidencialidad. El detalle de arquitectura y las cifras completas se comparten previa firma de NDA.
Contenido relacionado
Última actualización: 2026-09-12
Zifra eta arkitektura osoak NDA sinatu ondoren partekatzen dira.
Eskatu xehetasunak NDApean →