Saltar a contenido

Servicios Globales

En el Kubernetes tradicional, cuando creas un recurso tipo Service, este actúa como un balanceador de carga interno exclusivamente para los pods que viven dentro de ese mismo clúster. Si el clúster se cae, el servicio deja de responder.

Cilium rompe esta barrera. Un Servicio Global le dice a la red: "No me importa en qué clúster vivan los pods que respaldan a esta aplicación; si un usuario pide acceder a este servicio, reparte el tráfico entre todos los clústeres disponibles en la malla".

Esto te brinda dos superpoderes inmediatos:

  1. Alta Disponibilidad (Disaster Recovery): Si todos los pods de tu frontend en el cluster1 mueren, el tráfico se redirigirá automáticamente a los pods del frontend en el cluster2 sin que el usuario note la caída.
  2. Expansión de Capacidad (Cloud Bursting): Si el cluster1 se queda sin recursos durante un pico de ventas, puedes desplegar más réplicas en el cluster2 y ambos compartirán la carga de trabajo.

La "Receta" de Configuración 📝

Para que Cilium fusione los servicios de diferentes clústeres, se deben cumplir tres reglas estrictas:

  1. El servicio debe llamarse exactamente igual en todos los clústeres.
  2. El servicio debe existir en el mismo Namespace en todos los clústeres.
  3. Debes agregar la siguiente anotación mágica al metadata del servicio: service.cilium.io/global="true"

Si aplicas este YAML en ambos clústeres de tu laboratorio de kind:

apiVersion: v1
kind: Service
metadata:
  name: mi-backend-magico
  namespace: default
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/shared: "false" # Este servicio no será compartido con otros clústers.
    service.cilium.io/affinity: "local" # El servicio preferiblemente redigirá a los pods dentro del mismo clúster. También se puede usar "remote".
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: backend

Inmediatamente, el agente de Cilium detectará la anotación y, a través del túnel VXLAN que configuramos en la Fase 1, unificará los endpoints (las IPs de los pods) de ambos clústeres bajo esa única IP de servicio. Al hacer un curl mi-backend-magico, tus peticiones rebotarán entre los nodos del cluster1 y el cluster2 de forma transparente.