Wetopi RKE2 Network & Hosting Architecture¶
Memoria ejecutiva y técnica para la migración desde Docker Swarm¶
Fecha: 28 de agosto de 2026
Estado: Diseño base consolidado
Ámbito: Red, ingress, egress, hosting WordPress y transición desde Docker Swarm hacia RKE2 sobre Proxmox + Ceph.
Índice¶
- Resumen ejecutivo
- Contexto actual de Wetopi
- Objetivos del nuevo diseño
- Principios de arquitectura
- Decisión de plataforma: RKE2
- Arquitectura global objetivo
- Control plane RKE2
- Workers y dominios de infraestructura
- Cilium como CNI base
- Hubble como observabilidad de red
- Ingress WAN: conservar IPVS + VRRP + DSR
- Edge nodes RKE2
- Proxy HTTP/TLS y Gateway API
- Sustitución de Consul, Registrator y consul-template
- Modelo inicial de WordPress workloads
- Egress: diseño simple de NAT Gateways
- Asignación de clientes a gateways de salida
- Rotación y cambio de IPs de salida
- Separación de reputación de IPs
- Ingress IP dedicada por cliente
- Integración con OVH vRack
- Proxmox y agregación de ancho de banda
- Storage: Ceph
- Observabilidad y seguridad de red
- Suricata y WAF futuros
- Qué NO vamos a desplegar inicialmente
- Modelo de alta disponibilidad
- Mantenimiento y draining de edge nodes
- Modelo de namespaces y roles de nodos
- Flujos de tráfico de ejemplo
- Migración progresiva desde Docker Swarm
- Fases de implementación
- Decisiones consolidadas
- Riesgos principales y mitigaciones
- Evolución futura
- Arquitectura objetivo resumida
1. Resumen ejecutivo¶
Wetopi es un Managed WordPress Hosting ejecutado sobre un cloud privado basado en Proxmox + Ceph, con Docker Swarm como scheduler actual y del orden de 700 contenedores.
La arquitectura WAN existente tiene dos propiedades valiosas que se preservarán inicialmente:
- balanceo L3/L4 mediante IPVS;
- VIPs con VRRP/Keepalived;
- Direct Server Return (DSR);
- proxies WAN repartidos entre varios hosts Proxmox.
DSR no solo proporciona eficiencia y HA: permite que las respuestas salgan directamente por distintos nodos WAN y, por tanto, aprovechar la capacidad de salida de múltiples hosts físicos de OVH sin hacer retornar todo el tráfico por un único balanceador.
La nueva plataforma se construirá sobre:
- RKE2;
- Cilium;
- Hubble;
- Kubernetes Services;
- EndpointSlices;
- Gateway API;
- edge proxies Kubernetes-native;
- Ceph mediante CSI.
No se intentará transformar toda la red a la vez.
La primera generación conservará IPVS + VRRP + DSR en la capa WAN y sustituirá, detrás de ella:
- Docker Swarm;
- Registrator;
- Consul como service registry de websites;
- consul-template;
- generación dinámica de nginx.conf.
El egress también se mantendrá deliberadamente simple.
Se desplegarán varios NAT Gateways Ubuntu con IP interna estable y una IP pública asociada:
Diferentes clientes, sites o clases de workload podrán usar gateways distintos.
Esto permite:
- aislar reputación;
- separar crawlers/agentes de customers;
- rotar WAN IPs;
- mover clientes entre gateways;
- ofrecer IP de salida dedicada;
- mantener una solución fácil de operar.
Cilium se adopta como foundation de networking y observabilidad, pero no se requiere utilizar desde el primer día BGP, Egress Gateway avanzado, CRDs propios o automatización compleja.
La filosofía es:
construir una base moderna, observable y extensible sin sobrecomplicar la primera versión.
2. Contexto actual de Wetopi¶
La plataforma actual se ejecuta sobre:
El workload principal son websites WordPress.
Cada website se representa aproximadamente mediante un wepod, que contiene actualmente:
La entrada WAN actual es aproximadamente:
Internet
↓
Public VIP
↓
VRRP / Keepalived
↓
IPVS directors
↓
DSR
↓
WAN Nginx proxies
↓
Docker workloads
El descubrimiento y configuración se realiza mediante:
Este modelo ha sido funcional, pero introduce piezas que Kubernetes puede sustituir de forma nativa.
3. Objetivos del nuevo diseño¶
La nueva red debe:
- Migrar Docker Swarm a RKE2.
- Mantener Proxmox + Ceph.
- Preservar IPVS/DSR inicialmente.
- Preservar la agregación distribuida de egress.
- Eliminar Registrator.
- Eliminar Consul como registry de websites.
- Eliminar consul-template del path HTTP.
- Utilizar Service + EndpointSlice.
- Adoptar Gateway API.
- Utilizar un CNI moderno.
- Observar tráfico por workload.
- Poder separar clientes por egress gateway.
- Poder cambiar fácilmente una IP de salida.
- Permitir IP dedicada de salida.
- Permitir ingress dedicado en el futuro.
- Dejar preparada la red para WAF/IDS.
- Mantener simplicidad operacional.
- Permitir migración progresiva.
- No añadir service mesh sin necesidad.
- No depender de BGP para el bootstrap.
4. Principios de arquitectura¶
4.1 Conservar lo que resuelve un problema real¶
IPVS + VRRP + DSR seguirá siendo inicialmente la capa L3/L4 WAN.
4.2 Kubernetes sustituye el service discovery artesanal¶
Kubernetes ya proporciona:
- Services;
- EndpointSlices;
- DNS;
- readiness;
- labels;
- selectors.
No se recreará Consul dentro de Kubernetes para registrar websites.
4.3 Capas separadas¶
L3/L4 WAN -> IPVS / DSR
HTTP/TLS -> Gateway / proxy
Cluster networking -> Cilium
Flow visibility -> Hubble
Deep IDS futuro -> Suricata
HTTP security -> WAF futuro
4.4 Egress simple¶
Primera versión:
4.5 Evolución progresiva¶
La base debe permitir añadir capacidades avanzadas después, no obligar a desplegarlas ya.
5. Decisión de plataforma: RKE2¶
Se selecciona RKE2 como distribución Kubernetes principal.
Razones:
- Kubernetes conformante;
- control plane cercano a upstream;
- etcd embebido;
- static pods;
- containerd;
- HA sencilla;
- soporte sólido de CNI;
- lifecycle más fácil que kubeadm;
- adecuada para plataforma productiva de largo plazo.
Rancher UI no es requisito.
6. Arquitectura global objetivo¶
INTERNET
│
┌───────────┴───────────┐
│ │
VIP A VIP B
│ │
IPVS IPVS
│ │
DSR DSR
│ │
┌───────▼────────┐ ┌──────▼─────────┐
│ RKE2 EDGE A │ │ RKE2 EDGE B │
│ proxy HTTP/TLS │ │ proxy HTTP/TLS │
└───────┬────────┘ └──────┬─────────┘
│ │
└──────────┬────────────┘
│
Gateway API
│
Service / EndpointSlice
│
Pods
│
Ceph
EGRESS:
Pods / Sites / Agents
│
▼
internal gateway selection
│
┌──────┼────────┐
▼ ▼ ▼
.100 .101 .102
GW A GW B GW C
│ │ │
WAN A WAN B WAN C
│ │ │
└──── Internet ─┘
7. Control plane RKE2¶
Baseline:
Modelo:
Los control planes deben quedar separados de los workloads de customers.
Se prioriza:
- NVMe;
- baja latencia;
- backups de etcd;
- restore probado;
- endpoint API estable.
8. Workers y dominios de infraestructura¶
Se definirán roles explícitos:
wetopi.io/role=edge
wetopi.io/role=hosting
wetopi.io/role=agents
wetopi.io/role=database
wetopi.io/role=infra
Además, cuando sea útil:
El host Proxmox no es solo un failure domain: también puede ser un bandwidth domain.
9. Cilium como CNI base¶
Se selecciona Cilium como CNI.
Objetivos iniciales:
- red de pods;
- NetworkPolicy;
- observabilidad;
- Hubble;
- integración con Kubernetes;
- base futura para capacidades avanzadas.
No es requisito inicial:
- sustituir IPVS;
- BGP WAN;
- gestionar todas las IPs públicas;
- controlar todo egress mediante CRDs.
10. Hubble como observabilidad de red¶
Hubble será la primera capa de visibilidad de flows.
Permitirá responder preguntas como:
- qué pod abrió una conexión;
- qué site está haciendo egress;
- qué namespace habla con qué destino;
- qué tráfico fue bloqueado;
- qué workload está aumentando conexiones.
El objetivo a medio plazo es correlacionar:
11. Ingress WAN: conservar IPVS + VRRP + DSR¶
Se conserva el patrón:
Por qué¶
Con DSR:
La respuesta no vuelve por el director.
Esto preserva la capacidad de salida distribuida entre hosts físicos OVH.
12. Edge nodes RKE2¶
Los antiguos WAN proxies pasarán progresivamente a edge workers RKE2.
Ejemplo:
Cada edge VM debe estar distribuida deliberadamente entre hosts Proxmox distintos.
Labels ejemplo:
Taint recomendado:
13. Proxy HTTP/TLS y Gateway API¶
El edge seguirá terminando TLS.
Candidatos:
- Traefik;
- Envoy.
La arquitectura no debe depender todavía de la elección final.
Responsabilidades:
- TLS;
- routing HTTP;
- forwarding de IP real;
- headers;
- métricas;
- readiness;
- futura integración WAF.
Routing:
14. Sustitución de Consul, Registrator y consul-template¶
ANTES:
NUEVO:
Consul puede seguir existiendo para otros usos si hubiera necesidad, pero deja de ser necesario como service registry del hosting web.
15. Modelo inicial de WordPress workloads¶
No se recomienda refactorizar simultáneamente todo el wepod.
Primera migración:
manteniendo inicialmente:
cuando sea práctico.
La separación posterior de database/frontend debe tratarse como proyecto independiente.
16. Egress: diseño simple de NAT Gateways¶
Primera versión:
gw100
LAN: 192.168.88.100
WAN: PUBLIC_IP_A
gw101
LAN: 192.168.88.101
WAN: PUBLIC_IP_B
gw102
LAN: 192.168.88.102
WAN: PUBLIC_IP_C
Cada gateway será una VM Ubuntu sencilla.
Funciones:
- routing;
- forwarding;
- SNAT/MASQUERADE;
- logging;
- health;
- métricas básicas.
No necesita initially un controller Kubernetes.
17. Asignación de clientes a gateways de salida¶
Modelo:
Ejemplo:
site-1001 -> 192.168.88.100
site-1002 -> 192.168.88.100
site-2001 -> 192.168.88.101
crawler -> 192.168.88.102
La implementación puede empezar con routing/policy routing y evolucionar después.
Lo importante es que sea:
- determinista;
- observable;
- fácil de cambiar.
18. Rotación y cambio de IPs de salida¶
Caso 1:
Caso 2:
Los workloads no deben necesitar conocer la WAN IP.
Solo la política/ruta de salida.
19. Separación de reputación de IPs¶
Desde el principio se recomienda separar:
Ejemplo:
192.168.88.100
-> shared hosting
-> 51.x.x.10
192.168.88.101
-> premium/dedicated pool
-> 51.x.x.11
192.168.88.102
-> agents/crawlers
-> 51.x.x.12
Los crawlers no deben compartir IP con customer hosting.
20. Ingress IP dedicada por cliente¶
No es prioridad inicial.
El sistema debe permitir en el futuro:
No requiere rediseñar el backend Kubernetes.
21. Integración con OVH vRack¶
vRack seguirá siendo la red privada base.
El diseño inicial no depende de BGP.
Los bloques Additional IP podrán utilizarse para:
- VIPs;
- IPs de NATGW;
- futuras IPs dedicadas.
BGP Service de OVH podrá evaluarse cuando sea suficientemente maduro para producción.
22. Proxmox y agregación de ancho de banda¶
La distribución de edge nodes debe respetar la topología física.
Ejemplo:
Evitar:
cuando el objetivo es sumar failure/bandwidth domains.
23. Storage: Ceph¶
Ceph seguirá siendo el storage principal.
RKE2 consumirá storage mediante CSI.
Objetivos:
- PVC nativo;
- StorageClasses;
- snapshots donde sea útil;
- evitar dependencias de Docker volumes específicos.
24. Observabilidad y seguridad de red¶
Primera capa:
Más adelante:
Todos podrán converger en la plataforma de observabilidad.
25. Suricata y WAF futuros¶
No son requisito de bootstrap.
Suricata¶
Útil para:
- IDS;
- scans;
- anomalías;
- C2;
- DNS;
- metadata de protocolos.
Posibles puntos:
- edge;
- egress gateway;
- TAP/mirror.
WAF¶
Debe operar después de TLS termination para ver HTTP.
26. Qué NO vamos a desplegar inicialmente¶
No se considera necesario de salida:
- Istio;
- service mesh global;
- BGP WAN;
- Cilium BGP externo;
- controlador propio de egress;
- IP reputation controller;
- IPAM público dinámico;
- Suricata inline global;
- WAF sofisticado distribuido;
- CRDs propios para toda la red.
La ausencia de estas piezas es deliberada.
27. Modelo de alta disponibilidad¶
Control plane¶
Ingress¶
Egress¶
Varios gateways:
La HA de una IP dedicada concreta podrá implementarse cuando exista necesidad.
No es necesario resolver desde el primer día todos los casos premium.
28. Mantenimiento y draining de edge nodes¶
Procedimiento recomendado:
1. sacar edge de IPVS
2. dejar de enviar nuevas conexiones
3. esperar conexiones existentes
4. kubectl drain
5. mantenimiento
6. kubectl uncordon
7. validar proxy
8. reinsertar en IPVS
Después podrá automatizarse.
29. Modelo de namespaces y roles de nodos¶
Namespaces orientativos:
Roles de nodo:
Se utilizarán:
- labels;
- taints;
- affinity;
- topology spread.
30. Flujos de tráfico de ejemplo¶
Entrada HTTP¶
Respuesta:
Salida shared¶
Salida premium¶
Crawler¶
Rotación¶
pasa a:
sin mover el workload.
31. Migración progresiva desde Docker Swarm¶
No big-bang.
Durante la transición:
pueden coexistir.
Migración:
de forma progresiva.
Idealmente la VIP pública permanece y el routing decide el backend.
32. Fases de implementación¶
Fase 0 — Inventario¶
Documentar:
- VIPs;
- IPVS;
- VRRP;
- VLANs;
- vRack;
- Proxmox;
- WAN bandwidth domains;
- NATGW;
- Ceph.
Fase 1 — RKE2¶
- 3 control planes;
- workers;
- embedded etcd;
- API VIP;
- GitOps;
- Ceph CSI.
Fase 2 — Cilium/Hubble¶
- Cilium;
- Hubble;
- primeras NetworkPolicies;
- flow visibility.
Fase 3 — Edge¶
- edge workers;
- proxy DaemonSet;
- DSR;
- health checks;
- integración con IPVS.
Fase 4 — Gateway API¶
- Gateway;
- HTTPRoute;
- Services;
- EndpointSlices.
Fase 5 — Primeros sites¶
Validar:
- TLS;
- IP cliente;
- headers;
- storage;
- health;
- performance;
- egress.
Fase 6 — NATGW simples¶
Desplegar:
con WAN IPs separadas.
Fase 7 — Migración masiva¶
Mover progresivamente el grueso de los workloads.
Fase 8 — Observabilidad avanzada¶
Enriquecimiento de flows y dashboards.
Fase 9 — Seguridad avanzada opcional¶
- Suricata;
- WAF;
- egress automation;
- IP reputation;
- dedicated IP automation.
33. Decisiones consolidadas¶
NET-001¶
RKE2 será la distribución Kubernetes.
NET-002¶
Cilium será el CNI inicial.
NET-003¶
Hubble será la base de network observability.
NET-004¶
IPVS + VRRP + DSR se mantienen inicialmente.
NET-005¶
Los edge nodes seguirán repartidos por hosts físicos Proxmox.
NET-006¶
Registrator deja de ser necesario.
NET-007¶
Consul deja de ser el registry de websites.
NET-008¶
consul-template deja de generar la configuración HTTP de RKE2.
NET-009¶
Gateway API será la abstracción de routing HTTP.
NET-010¶
Traefik o Envoy actuarán como proxy edge.
NET-011¶
El egress inicial usará NATGW Ubuntu simples.
NET-012¶
Cada NATGW tendrá una IP interna estable.
Ejemplo:
NET-013¶
La WAN IP asociada a un gateway debe ser fácil de cambiar.
NET-014¶
Agents/crawlers no compartirán IP de salida con customers.
NET-015¶
Se podrá asignar un cliente a un gateway específico.
NET-016¶
No se desplegará Istio inicialmente.
NET-017¶
El bootstrap no dependerá de BGP.
NET-018¶
No se construirá inicialmente un egress control plane complejo si gateways estáticos resuelven el problema.
34. Riesgos principales y mitigaciones¶
Cambio simultáneo excesivo¶
Mitigación:
- migración por capas;
- conservar IPVS;
- conservar inicialmente wepod.
Pérdida accidental de DSR¶
Mitigación:
- edge nodes dedicados;
- pruebas explícitas de dataplane.
Mala distribución física¶
Mitigación:
- labels de Proxmox host;
- anti-affinity;
- topology awareness.
NATGW como punto de fallo¶
Mitigación:
- varios gateways;
- reasignación sencilla;
- HA premium cuando se requiera.
Reputación compartida¶
Mitigación:
- separar pools desde el principio.
Overengineering¶
Mitigación:
- no desplegar capacidades avanzadas sin necesidad operacional concreta.
35. Evolución futura¶
Una vez estable la base se podrá evaluar:
Cilium Egress Gateway¶
Para seleccionar egress por labels de Kubernetes.
Egress pools¶
Reputation monitoring¶
Medición y rotación de IPs.
Suricata¶
IDS/IPS de red.
WAF¶
Inspección HTTP tras TLS.
BGP¶
Cuando OVH ofrezca una opción madura y productiva.
Eliminación de IPVS¶
Solo si una alternativa BGP/ECMP conserva:
- HA;
- DSR/equivalente;
- capacidad;
- simplicidad.
WordPressSite CRD¶
En una fase posterior cada website podría representarse como:
y generar automáticamente:
- workload;
- Service;
- HTTPRoute;
- PVC;
- monitoring;
- policies.
No es requisito de la primera migración.
36. Arquitectura objetivo resumida¶
OVH / vRack
│
Proxmox + Ceph
│
RKE2
│
┌──────────────┼──────────────┐
│ │ │
Control Plane Edge Hosting
│ │ │
│ Cilium │
│ Hubble │
│ │ │
│ Gateway API │
│ │ │
└──────────────┼──────────────┘
│
Websites
INGRESS:
EGRESS:
Workload
↓
selected internal GW
├── 192.168.88.100 -> WAN IP A
├── 192.168.88.101 -> WAN IP B
└── 192.168.88.102 -> WAN IP C
↓
Internet
OBSERVABILITY:
FUTURO:
Conclusión¶
El diseño inicial de la nueva Wetopi debe optimizar robustez, visibilidad y capacidad de evolución, no complejidad.
La base acordada es:
RKE2
+
Cilium/Hubble
+
IPVS/VRRP/DSR existente
+
Gateway API
+
edge proxies Kubernetes-native
+
Services/EndpointSlices
+
NATGW Ubuntu simples
Este modelo conserva las propiedades valiosas de la plataforma actual:
- DSR;
- retorno directo;
- capacidad WAN distribuida;
- IPs movibles;
- separación de egress;
y elimina progresivamente las piezas que Kubernetes puede resolver mejor:
- Docker Swarm;
- Registrator;
- Consul como service registry web;
- consul-template;
- regeneración de nginx.conf.
Sobre esta foundation se podrán añadir más adelante Cilium Egress Gateway, Suricata, WAF, reputación automática, BGP e IPs dedicadas gestionadas sin condicionar ni complicar el primer despliegue.