Laboratorio Práctico Cilium Cluster Mesh

Esta guía resume los conceptos arquitectónicos, comandos operativos y mejores prácticas del "Día 2" para establecer y mantener un entorno multi-clúster con Cilium usando kind.

1. Arquitectura y Requisitos Previos 🏗️

Para que dos o más clústeres formen un Cluster Mesh exitoso, la red subyacente debe estar correctamente planificada.

Sin Superposición de Red (Non-overlapping CIDRs): Es el requisito más crítico. Los rangos de direcciones IP de Pods y Servicios no deben solaparse.
Ejemplo Cluster 1 (Por defecto en kind): podSubnet: 10.244.0.0/16, serviceSubnet: 10.96.0.0/16
Ejemplo Cluster 2: podSubnet: 10.245.0.0/16, serviceSubnet: 10.97.0.0/16
Identidad Única del Clúster: Al instalar Cilium (vía Helm o CLI), cada clúster debe identificarse de manera inequívoca pasando estos dos parámetros:
--set cluster.id=<número>: (Ej. 1 y 2). Vital para evitar colisiones en las identidades de seguridad de los pods (Cilium Security Identities).
--set cluster.name=<nombre>: (Ej. cluster1 y cluster2). Fundamental para el ruteo, métricas y aplicación de políticas de red (CiliumNetworkPolicies) específicas por clúster.

# Instalación de Cilium en los clusters
cilium install --set cluster.name=kind-cluster-01 --set cluster.id=1 --context kind-cluster-01
cilium install --set cluster.name=kind-cluster-02 --set cluster.id=2 --context kind-cluster-02

Otros requisitos importantes

Matching data path mode across clusters: Los cluster deben tener configurado el mismo modo de enrutamiento de dadtos. Para verificar el modo configurado usar el siguiente comando:

$ kubectl --context kind-cluster-01 exec -n kube-system ds/cilium -- cilium status | grep Routing
Routing:                 Network: Tunnel [vxlan]

2. Habilitación y Conexión (Operaciones CLI) 🔗

Una vez instalados los agentes independientes, usamos la CLI de Cilium para tejer la malla.

Habilitar Cluster Mesh en entornos locales (kind):
```
cilium clustermesh enable --context kind-cluster-01 --service-type NodePort
```
- ¿Por qué NodePort? kind no cuenta con un proveedor nativo para entregar IPs externas (como requiere LoadBalancer), dejando el servicio en estado <pending>. Tampoco podemos usar ClusterIP porque asigna una IP estrictamente interna que el otro clúster no puede enrutar. NodePort expone la API directamente en la IP del contenedor de Docker (nodo), permitiendo la comunicación local.

Conectar los Clústeres:

cilium clustermesh connect --context kind-cluster-01 --destination-context kind-cluster-02

Nota: Es fundamental usar los nombres exactos de los contextos definidos en tu archivo kubeconfig (verificables con kubectl config get-contexts).
Verificar el Estado:
```
cilium clustermesh status --context kind-cluster-01
```
(Este es el comando con el que íbamos a cerrar la fase de arquitectura, sirve para validar que los nodos se ven entre sí).

3. Seguridad y Confianza: El secreto `cilium-ca` 🔐

El secreto cilium-ca (ubicado en kube-system) contiene la Autoridad Certificadora Raíz (Root CA). Es el corazón criptográfico de Cilium.

¿Para qué se utiliza?

Raíz de Confianza (Root of Trust): Al compartir la misma CA, los agentes de diferentes clústeres confían en las identidades de los pods remotos.
Hubble (Observabilidad): Asegura con TLS la telemetría enviada desde los nodos hacia Hubble Relay.
Encriptación Transparente: Firma los certificados utilizados por IPsec o WireGuard para encriptar el tráfico entre nodos.

4. Operaciones del Día 2: Rotación de Certificados "Zero Downtime" 🔄

Borrar y reemplazar abruptamente el secreto cilium-ca en producción genera una caída de red (outage) y pérdida de observabilidad, ya que rompe las validaciones TLS existentes.

Para rotar un certificado próximo a expirar sin afectar el tráfico, se utiliza un proceso de Rotación Gradual:

Generación: Se crea la nueva CA.
Fase de Confianza (Trust Phase): Se actualiza el secreto cilium-ca para que contenga un CA Bundle (ambos certificados apilados en formato PEM: el antiguo y el nuevo).
Hot-reload: Los agentes de Cilium detectan el cambio en el secreto mediante un "watch" a la API de Kubernetes y actualizan su almacén de confianza en memoria al instante, sin necesidad de reiniciarse.
Fase de Emisión (Issuance Phase): Se reinician progresivamente los pods de Cilium (kubectl rollout restart ds/cilium). Al levantar, emiten nuevos certificados de hoja firmados por la nueva CA. Como toda la red ya confía en ambas CAs (gracias al paso 2), los pods reiniciados y los no reiniciados se comunican sin cortes.
Fase de Limpieza (Prune Phase): Una vez actualizado todo el clúster, se edita el secreto por última vez para eliminar la CA antigua.