← Volver al índice | Talos OS | Infraestructura

Multi-Cluster Kubernetes — Orquestación, Federación y Plataforma SaaS Reutilizable

Tipo: Investigación técnica exhaustiva Audiencia: Equipo de arquitectura e infraestructura Fecha: 20 marzo 2026

---

1. Visión del problema

La plataforma IEO necesita soportar tres modelos de despliegue:

Modelo	Descripción	Analogía
SaaS	Multi-tenant en cluster compartido	ieo.plataforma.com
SaaS Dedicated	Cluster dedicado por cliente	ieo-murcia.plataforma.com
OnPremise	Cluster en infraestructura del cliente	Instalación local en instituto

[!IMPORTANT] El objetivo final es que diferentes IEO puedan descubrirse y conectarse entre sí, compartiendo datos oceanográficos, similar a cómo nodos de una red federada se interconectan automáticamente.

graph TB
    subgraph CENTRAL["Cluster Central SaaS"]
        HUB["Hub de Control<br/>ArgoCD + Karmada"]
        API["API Gateway<br/>+ Service Mesh"]
    end

    subgraph IEO_MU["IEO Murcia - Dedicated"]
        CP1["Control Plane"]
        W1["Workers"]
    end

    subgraph IEO_VI["IEO Vigo - OnPremise"]
        CP2["Control Plane"]
        W2["Workers"]
    end

    subgraph IEO_BA["IEO Baleares - Dedicated"]
        CP3["Control Plane"]
        W3["Workers"]
    end

    HUB -->|"GitOps sync"| IEO_MU
    HUB -->|"GitOps sync"| IEO_VI
    HUB -->|"GitOps sync"| IEO_BA
    IEO_MU <-->|"Federación datos"| IEO_VI
    IEO_VI <-->|"Federación datos"| IEO_BA
    IEO_MU <-->|"Federación datos"| IEO_BA
    API --> HUB

---

2. Tecnologías de multi-cluster: mapa completo

2.1 Matriz comparativa

Herramienta	Capa	Función principal	Complejidad	Madurez
Cilium ClusterMesh	L3/L4 (eBPF)	Red entre clusters, Pod-to-Pod	Media	⭐⭐⭐⭐⭐
Liqo	Virtual nodes	Offloading de workloads, recursos compartidos	Media	⭐⭐⭐⭐
Submariner	L3 (IPSec)	Túneles red entre clusters	Media	⭐⭐⭐⭐
Skupper	L7 (App)	Service interconnect sin VPN	Baja	⭐⭐⭐⭐
Karmada	Orquestación	Distribución de workloads multi-cluster	Alta	⭐⭐⭐⭐ (CNCF)
Istio	Service Mesh	mTLS, traffic management, observabilidad	Alta	⭐⭐⭐⭐⭐
Linkerd	Service Mesh	mTLS ligero, service mirroring	Media	⭐⭐⭐⭐
ArgoCD	GitOps	Despliegue declarativo multi-cluster	Media	⭐⭐⭐⭐⭐
Dapr	Runtime	Service invocation, pub/sub, state cross-cluster	Baja	⭐⭐⭐⭐

2.2 ¿Cuándo usar cada una?

graph TD
    START["¿Qué necesitas<br/>entre clusters?"] --> NET{"¿Conectividad<br/>de red L3?"}
    NET -->|Sí| CILIUM["Cilium ClusterMesh<br/>o Submariner"]
    NET -->|No| SVC{"¿Compartir<br/>servicios L7?"}
    SVC -->|Sí| SKUPPER["Skupper<br/>sin necesitar VPN"]
    SVC -->|No| WL{"¿Mover workloads<br/>entre clusters?"}
    WL -->|Sí| LIQO["Liqo<br/>virtual nodes"]
    WL -->|No| DEPLOY{"¿Desplegar apps<br/>en paralelo?"}
    DEPLOY -->|Sí| KARMADA["Karmada + ArgoCD<br/>orquestación"]
    DEPLOY -->|No| DAPR["Dapr<br/>runtime distribuido"]

---

3. Análisis detallado por tecnología

3.1 Cilium ClusterMesh (⭐ Recomendado como base de red)

Qué hace: Conecta pods y servicios entre clusters a nivel de red usando eBPF. Los pods de un cluster pueden comunicarse directamente con pods de otro cluster.

Por qué es ideal para Talos: - Talos recomienda Cilium como CNI principal - Reemplaza kube-proxy con eBPF (mejor rendimiento) - ClusterMesh es una extensión natural

Requisitos: - CIDRs de Pod y Service no deben solaparse entre clusters - Conectividad de red entre nodos de ambos clusters - Cada cluster necesita un cluster-id único

# Instalar Cilium en Cluster 1 (MacBook)
cilium install --cluster-name macbook --cluster-id 1
cilium clustermesh enable

# Instalar Cilium en Cluster 2 (Linux)
cilium install --cluster-name linux --cluster-id 2
cilium clustermesh enable

# Conectar los clusters
cilium clustermesh connect --destination-context linux-cluster

Capacidades: | Capacidad | Soportado | |---|---| | Pod-to-Pod cross-cluster | ✅ | | Service discovery global | ✅ | | Network policies cross-cluster | ✅ | | Encriptación transparente | ✅ | | Load balancing global | ✅ | | Failover automático | ✅ |

3.2 Liqo (⭐ Recomendado para compartir recursos)

Qué hace: Hace que un cluster remoto aparezca como un nodo virtual en tu cluster local. Los pods se programan en el nodo virtual y se ejecutan transparentemente en el cluster remoto.

graph LR
    subgraph LOCAL["Cluster MacBook"]
        N1["Nodo real"]
        VN["Nodo virtual<br/>(Liqo)"]
    end
    subgraph REMOTE["Cluster Linux"]
        N2["Nodo real<br/>ejecuta pods offloaded"]
    end
    VN -.->|"offloading<br/>transparente"| N2

Instalación y peering:

# Instalar liqoctl
curl -sL https://get.liqo.io | bash

# Instalar Liqo en ambos clusters
liqoctl install kubeadm --cluster-name macbook
liqoctl install kubeadm --cluster-name linux

# Peer los clusters (desde el MacBook)
liqoctl peer --remote-kubeconfig /path/to/linux-kubeconfig

# Verificar — aparece un nodo virtual
kubectl get nodes
# NAME                    STATUS   ROLES
# macbook-cp-1            Ready    control-plane
# liqo-linux              Ready    agent    <-- nodo virtual

[!WARNING] Liqo tiene soporte parcial para Cilium como CNI. Si se usa Cilium, es necesario mantener kube-proxy habilitado, lo cual puede entrar en conflicto con la configuración óptima de Cilium en Talos (que recomienda deshabilitarlo).

Alternativa: Usar Cilium ClusterMesh para la red y Liqo solo para offloading de workloads (requiere configuración cuidadosa).

3.3 Skupper (⭐ Recomendado para conectar servicios específicos)

Qué hace: Crea una "Virtual Application Network" a nivel de aplicación (L7). No necesita VPN, no necesita privilegios de admin. Ideal para conectar servicios específicos entre clusters.

# Cluster MacBook
skupper init --site-name macbook
skupper token create ~/token.yaml

# Cluster Linux
skupper init --site-name linux
skupper link create ~/token.yaml

# Exponer un servicio del Linux al MacBook
# En el cluster Linux:
skupper expose deployment/mi-api --port 8080

# Desde el MacBook, el servicio está disponible como:
# mi-api:8080 (transparente)

Ventajas para IEO: - No requiere privilegios de cluster admin - Funciona incluso con NAT y firewalls - mTLS automático entre clusters - Perfecto para conectar diferentes IEO que no controlas a nivel de red

3.4 Karmada (Para orquestación avanzada)

Qué hace: Plano de control unificado que distribuye workloads a múltiples clusters usando APIs nativas de Kubernetes.

# PropagationPolicy — distribuir un Deployment a múltiples clusters
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: ieo-api-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: ieo-api
  placement:
    clusterAffinity:
      clusterNames:
        - ieo-murcia
        - ieo-vigo
        - ieo-baleares
  replicaScheduling:
    replicaDivisionPreference: Weighted
    replicaSchedulingType: Divided
    weightPreference:
      staticWeightList:
        - targetCluster:
            clusterNames: ["ieo-murcia"]
          weight: 2
        - targetCluster:
            clusterNames: ["ieo-vigo"]
          weight: 1

3.5 Dapr (⭐ Ya es parte del stack IEO)

Qué hace: Runtime para microservicios que abstrae comunicación, estado y pub/sub. Ya forma parte del stack Quarkus + Dapr del proyecto.

Capacidades multi-cluster nativas: | Capacidad | Cómo funciona | |---|---| | Service invocation | Via name resolution (Consul para multi-cluster) | | Pub/Sub | Broker compartido entre clusters (Redis/Kafka) | | State management | State store externo accesible desde cualquier cluster | | Cross-namespace | app-id.namespace para invocar servicios |

# Configuración Dapr para service invocation cross-cluster
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: consul-nameresolution
spec:
  type: nameresolution.consul
  metadata:
    - name: selfRegister
      value: "true"
    - name: daprPortMetaKey
      value: "DAPR_PORT"
    - name: advancedRegistration
      value: |
        {
          "Datacenter": "ieo-murcia"
        }

[!TIP] Dapr + Consul como name resolution permite que servicios en diferentes clusters se descubran automáticamente sin configuración de red adicional. Esto encaja perfectamente con el modelo de IEO federados.

---

4. Modelos de tenancy para la plataforma

4.1 Los tres modelos del IEO

graph TB
    subgraph SAAS["Modelo SaaS (Multi-tenant)"]
        direction TB
        CS["Cluster Compartido"]
        NS1["Namespace: IEO-Murcia"]
        NS2["Namespace: IEO-Vigo"]
        NS3["Namespace: IEO-Canarias"]
        CS --> NS1
        CS --> NS2
        CS --> NS3
    end

    subgraph DEDICATED["Modelo SaaS Dedicated"]
        direction TB
        C1["Cluster IEO-Murcia"]
        C2["Cluster IEO-Baleares"]
    end

    subgraph ONPREM["Modelo OnPremise"]
        direction TB
        C3["Cluster en servidor<br/>del instituto"]
    end

    HUB["Hub Central<br/>ArgoCD + Karmada"] -->|"gestiona"| SAAS
    HUB -->|"gestiona"| DEDICATED
    HUB -->|"conecta"| ONPREM

4.2 Matriz de aislamiento por modelo

Aspecto	SaaS	SaaS Dedicated	OnPremise
Control Plane	Compartido	Dedicado	Dedicado (local)
Workers	Compartidos (con quotas)	Dedicados	Dedicados (local)
Red	Network Policies (Cilium)	Cluster aislado	Cluster aislado
Datos	Schema-per-tenant	Base de datos dedicada	Base de datos local
Coste	€€ (compartido)	€€€ (dedicado)	€€€€ (infra cliente)
Aislamiento	Lógico (namespace)	Físico (cluster)	Físico (hardware)
Compliance	Estándar	Alto	Máximo

4.3 Implementación con Kubernetes

# Para SaaS multi-tenant: ResourceQuota por namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: ieo-murcia-quota
  namespace: ieo-murcia
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "50"
---
# NetworkPolicy para aislar tenants
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-tenant
  namespace: ieo-murcia
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              tenant: ieo-murcia
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              tenant: ieo-murcia
    - to:  # Permitir DNS
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP

---

5. Federación inter-IEO: el modelo de "conectores"

5.1 Arquitectura de descubrimiento

El modelo de conectores permite que cada IEO (independientemente de su modelo de despliegue) pueda: 1. Registrarse en un directorio federado 2. Descubrir otros IEOs disponibles 3. Establecer conexiones selectivas (no todas con todas) 4. Compartir datos oceanográficos de forma controlada

sequenceDiagram
    participant MU as IEO Murcia
    participant REG as Service Registry<br/>(Consul/etcd)
    participant VI as IEO Vigo

    MU->>REG: Registro: ieo-murcia.oceanografia.api
    VI->>REG: Registro: ieo-vigo.oceanografia.api
    MU->>REG: Descubrir: *.oceanografia.api
    REG-->>MU: [ieo-vigo.oceanografia.api]
    MU->>VI: Establecer peering (mTLS)
    VI-->>MU: Aceptar peering
    MU->>VI: Solicitar datos: GET /especies/zona-murcia
    VI-->>MU: Datos compartidos

5.2 Stack recomendado para conectores

Capa	Tecnología	Función
Descubrimiento	Consul (Dapr name resolution)	Registro y descubrimiento de servicios
Comunicación	Dapr service invocation + mTLS	Invocación segura cross-cluster
Datos	Dapr pub/sub (Kafka/NATS)	Eventos asíncronos entre IEOs
Estado	Dapr state management	Estado compartido federado
Red	Skupper o Cilium ClusterMesh	Conectividad entre clusters
Orquestación	ArgoCD (hub-spoke)	Despliegue unificado

5.3 Conector IEO — diseño conceptual

# Custom Resource: IEOConnector
apiVersion: ieo.csic.es/v1alpha1
kind: IEOConnector
metadata:
  name: connector-vigo
  namespace: ieo-federation
spec:
  remoteIEO:
    name: "IEO Vigo"
    endpoint: "https://api.ieo-vigo.csic.es"
    clusterID: "ieo-vigo-001"
  authentication:
    method: mTLS
    certificateSecret: ieo-vigo-ca-cert
  dataSharing:
    enabled: true
    apis:
      - path: /api/v1/species
        direction: bidirectional
      - path: /api/v1/oceanography
        direction: incoming
      - path: /api/v1/alerts
        direction: outgoing
  connectionPolicy:
    autoConnect: true
    retryInterval: 30s
    healthCheckInterval: 60s

---

6. Topología de desarrollo local: hardware confirmado

6.1 Inventario de hardware real

Máquina	CPU	Cores	RAM	GPU	VRAM	Disco libre
Linux (ASUS ROG)	i9-13900H	20	30 GB	RTX 4070 Max-Q	8 GB	622 GB NVMe
MacBook	(por confirmar)	—	16 GB	—	—	por confirmar

[!IMPORTANT] El Linux tiene GPU NVIDIA RTX 4070 con 8 GB VRAM y NVIDIA Container Toolkit instalado. Esto es clave porque los LLMs pueden ejecutarse en GPU, liberando RAM para Kubernetes.

6.2 Presupuesto de memoria con LLMs

Los LLMs necesitan memoria significativa. Dependiendo del modelo:

Modelo LLM	Tamaño	RAM CPU necesaria	VRAM GPU necesaria	¿Cabe en RTX 4070?
Llama 3 8B (Q4)	~4.5 GB	~2 GB overhead	~5 GB	✅ Sí
Mistral 7B (Q4)	~4 GB	~2 GB overhead	~4.5 GB	✅ Sí
Llama 3 70B (Q4)	~40 GB	~8 GB overhead	No cabe	❌ CPU-only (lento)
Phi-3 Mini 3.8B	~2.3 GB	~1 GB overhead	~2.5 GB	✅ Sí (sobra VRAM)
Varios modelos simultáneos	~10-12 GB	~4-6 GB overhead	~8 GB	⚠️ Justo

[!WARNING] Si se ejecutan varios LLMs 7-8B simultáneamente, la VRAM (8 GB) se satura y el sistema hace swap a RAM CPU. Hay que reservar 6-8 GB de RAM del Linux para overhead de LLMs.

6.3 Escenario A: Linux + MacBook (dos máquinas)

graph TB
    subgraph LNX["Linux 30GB — Cluster Principal + LLMs"]
        subgraph K8S_L["Talos K8s ~14 GB"]
            LCP["Control Plane<br/>4 GB RAM"]
            LW1["Worker 1<br/>4 GB RAM"]
            LW2["Worker 2<br/>4 GB RAM"]
        end
        subgraph AI["Inferencia IA"]
            GPU["RTX 4070<br/>8 GB VRAM"]
            LLM["LLMs via Ollama<br/>~6 GB RAM overhead"]
        end
        REG["Registry :5000"]
        LCNI["Cilium cluster-id: 1"]
    end

    subgraph MAC["MacBook 16GB — Cluster Secundario"]
        subgraph K8S_M["Talos K8s ~8 GB"]
            MCP["Control Plane<br/>4 GB RAM"]
            MW1["Worker 1<br/>4 GB RAM"]
        end
        MCNI["Cilium cluster-id: 2"]
    end

    LNX <-->|"Cilium ClusterMesh<br/>o Skupper via LAN"| MAC
    MAC -->|"pull images"| REG

Distribución de memoria — Escenario A:

Recurso	Linux 30 GB	MacBook 16 GB
SO + Docker	~3 GB	~3 GB
LLMs (CPU overhead)	~6 GB	—
Talos cluster	~14 GB (1 CP + 2 workers)	~8 GB (1 CP + 1 worker)
IDE, navegador, etc.	~4 GB	~3 GB
Libre	~3 GB	~2 GB
Nodos Talos	3	2

¿Por qué el Linux lleva el cluster más grande? - Tiene el doble de RAM (30 vs 16 GB) - Tiene GPU dedicada para LLMs (no consume RAM del cluster) - Tiene 20 cores vs los que tenga el MacBook - El MacBook complementa como cluster secundario para probar multi-cluster

6.4 Escenario B: solo un ordenador (equipo individual)

Para miembros del equipo que trabajan con una sola máquina:

Linux 32 GB (solo):

# Cluster single-node con toda la potencia
talosctl cluster create \
  --provisioner docker \
  --name dev-local \
  --controlplanes 1 \
  --workers 2
# Total K8s: ~12 GB | LLMs: ~6 GB | SO+IDE: ~7 GB | Libre: ~5 GB

MacBook 16 GB (solo):

# Cluster ligero — sin LLMs locales (usar API remota)
talosctl cluster create \
  --provisioner docker \
  --name dev-local \
  --controlplanes 1 \
  --workers 1
# Total K8s: ~8 GB | SO+IDE: ~6 GB | Libre: ~2 GB
# LLMs: usar endpoint remoto (Linux, API cloud, o Ollama en otro nodo)

Tabla resumen por perfil de equipo:

Perfil	RAM	Nodos Talos	LLMs	Estrategia
Linux 32 GB + GPU	30 GB	1 CP + 2 workers	Local (GPU)	Cluster completo + LLMs en GPU
Linux 32 GB sin GPU	30 GB	1 CP + 1 worker	Local (CPU, lento)	Más RAM para K8s
MacBook 16 GB	16 GB	1 CP + 1 worker	Remoto	Cluster ligero, LLMs via API
Cualquiera + Cloud	—	1 CP + 0 workers (single)	Cloud API	Mínimo local, staging en Hetzner

6.5 Escenario C: Cloud (Hetzner)

graph TB
    subgraph DEV["Desarrollo Local"]
        L["Linux 30GB<br/>docker build + test<br/>LLMs locales"]
        M["MacBook 16GB<br/>desarrollo + test"]
    end

    subgraph HETZNER["Hetzner Cloud"]
        subgraph STAGING["Staging ~€18/mes"]
            SCP["CX33 Control Plane<br/>8 GB RAM"]
            SW1["CAX11 Worker<br/>4 GB ARM"]
            SLB["Load Balancer"]
        end
        subgraph GPU_NODE["GPU Cloud (bajo demanda)"]
            GNODE["CCX33 + GPU<br/>para LLMs pesados"]
        end
    end

    L -->|"push images"| GHCR["GitHub Container<br/>Registry"]
    GHCR -->|"pull"| STAGING
    L <-->|LAN| M
    STAGING <-->|"Skupper"| DEV

[!TIP] Para LLMs pesados (70B+) que no caben en la RTX 4070, usar instancias GPU en Hetzner bajo demanda o APIs cloud (OpenAI, Anthropic, Mistral). Para modelos 7-8B, la RTX 4070 local es suficiente y gratuita.

6.6 Comandos para montar el escenario A (Linux + MacBook)

# === EN EL LINUX (cluster principal) ===

# 1. Levantar registry local
docker run -d -p 5000:5000 --restart always --name registry registry:2

# 2. Crear cluster Talos (3 nodos, reservando RAM para LLMs)
talosctl cluster create \
  --provisioner docker \
  --name linux-cluster \
  --controlplanes 1 \
  --workers 2

# 3. Verificar
kubectl --context admin@linux-cluster get nodes

# === EN EL MACBOOK (cluster secundario) ===

# 1. Crear cluster Talos (2 nodos)
talosctl cluster create \
  --provisioner docker \
  --name macbook-cluster \
  --controlplanes 1 \
  --workers 1

# === CONECTAR CON SKUPPER (opción simple) ===

# En Linux:
kubectl --context admin@linux-cluster create namespace federation
skupper --context admin@linux-cluster -n federation init --site-name linux

# Generar token
skupper --context admin@linux-cluster -n federation token create ~/skupper-token.yaml

# Copiar token al MacBook via LAN (scp, airdrop, etc.)

# En MacBook:
kubectl --context admin@macbook-cluster create namespace federation
skupper --context admin@macbook-cluster -n federation init --site-name macbook
skupper --context admin@macbook-cluster -n federation link create ~/skupper-token.yaml

# === VERIFICAR CROSS-CLUSTER ===

# Desplegar servicio en Linux
kubectl --context admin@linux-cluster -n federation \
  create deployment api-test --image=nginx --port=80
skupper --context admin@linux-cluster -n federation \
  expose deployment/api-test --port 80

# Acceder desde MacBook (transparente)
kubectl --context admin@macbook-cluster -n federation \
  run curl --rm -it --image=curlimages/curl -- curl -s api-test:80

---

7. Roadmap para producción

7.1 Fases propuestas

gantt
    title Roadmap Multi-Cluster IEO
    dateFormat YYYY-MM
    section Fase 1 - PoC Local
    Talos en MacBook + Linux          :f1a, 2026-03, 2w
    Cilium ClusterMesh o Skupper      :f1b, after f1a, 1w
    Demo cross-cluster                :f1c, after f1b, 1w
    section Fase 2 - Staging Hetzner
    Cluster Talos en Hetzner          :f2a, after f1c, 2w
    Multi-cluster local-Hetzner       :f2b, after f2a, 2w
    Dapr cross-cluster                :f2c, after f2a, 2w
    section Fase 3 - Plataforma
    Modelo SaaS multi-tenant          :f3a, after f2c, 4w
    Modelo Dedicated                  :f3b, after f3a, 3w
    Conectores IEO federados          :f3c, after f3b, 4w
    section Fase 4 - Producción
    HA y disaster recovery            :f4a, after f3c, 3w
    Monitoring multi-cluster          :f4b, after f3c, 2w
    Documentación operativa           :f4c, after f4b, 2w

7.2 Costes estimados por fase (Hetzner)

Fase	Infraestructura	Coste/mes
PoC Local	MacBook + Linux (ya disponible)	€0
Staging	1× CX33 + 1× CAX11 + LB	~€18
Producción SaaS	3× CX33 (CP HA) + 3× CAX21 + LB	~€58
Producción multi-IEO	N clusters dedicados × ~€22 cada uno	~€22 × N

---

8. Stack recomendado final

Capa	Tecnología	Rol
OS	Talos Linux	Sistema operativo inmutable
CNI	Cilium	Networking + ClusterMesh
Multi-cluster red	Cilium ClusterMesh (clusters controlados) + Skupper (IEOs externos)	Conectividad
Runtime	Dapr	Abstracción de microservicios
Descubrimiento	Consul (via Dapr)	Service registry federado
Orquestación	ArgoCD (hub-spoke)	GitOps multi-cluster
Distribución	Karmada (fase avanzada)	Propagación de workloads
Observabilidad	Grafana + Prometheus + Loki	Monitoreo unificado

[!TIP] Este stack permite evolución gradual: empezar con Skupper (simple) para conectar clusters, añadir Cilium ClusterMesh cuando se controle la red, y usar Karmada cuando se necesite orquestación avanzada.

---

9. Conclusiones

✅ Respuestas a las preguntas planteadas

Pregunta	Respuesta
¿Se pueden conectar clusters entre sí?	Sí, con múltiples opciones: Cilium ClusterMesh (red), Skupper (servicios), Liqo (recursos)
¿Se pueden descubrir automáticamente?	Sí, con Consul como service registry + Dapr name resolution
¿Funciona con Talos OS?	Sí, Cilium es el CNI recomendado para Talos y ClusterMesh funciona nativamente
¿Se puede hacer SaaS + Dedicated + OnPremise?	Sí, usando namespaces con quotas (SaaS), clusters dedicados (Dedicated) y Skupper para OnPremise
¿Puedo probarlo entre MacBook y Linux?	Sí, con Talos en Docker y Skupper o Cilium ClusterMesh entre LAN
¿Encaja con Quarkus + Dapr?	Perfecto, Dapr tiene soporte nativo para cross-cluster con Consul

⚠️ Riesgos a considerar

Riesgo	Mitigación
Complejidad operacional de multi-cluster	Empezar con PoC simple, escalar gradualmente
Latencia cross-cluster en OnPremise	Caché local + patrones async con Dapr pub/sub
Liqo + Cilium (sin kube-proxy) incompatible	Usar Cilium ClusterMesh en vez de Liqo para la red
Seguridad en federación de IEOs	mTLS obligatorio, network policies, RBAC por tenant

---

Documentos relacionados

Nivel	Documento	Descripción
Investigación	Talos OS Kubernetes	Sistema operativo para los clusters
Arquitectura	Arquitectura del sistema	Arquitectura general del proyecto
Arquitectura	Pivote Quarkus + Dapr	Stack aplicativo del proyecto