Guía Avanzada: Kubernetes Bare Metal con Cilium y eBPF 2025

El ecosistema de contenedores ha madurado hasta el punto en que Kubernetes se ha convertido en el estándar de facto para la orquestación. Sin embargo, durante años, el despliegue de clusters sobre Kubernetes bare metal se consideraba una tarea compleja, reservada para entornos cloud donde los balanceadores de carga y las redes definidas por software (SDN) ya venían resueltos. Esto ha cambiado drásticamente.

La llegada de Cilium eBPF ha revolucionado las redes Kubernetes avanzadas, ofreciendo un rendimiento a nivel de kernel que los proxies tradicionales (como kube-proxy con iptables) simplemente no pueden igualar. Para 2025, cualquier arquitecto de infraestructura que busque optimización servidores y máxima eficiencia debe considerar seriamente esta combinación.

En este artículo, exploraremos en detalle cómo desplegar un clúster de Kubernetes sobre hardware físico (bare metal) utilizando Cilium con eBPF, cubriendo desde la planificación del hardware hasta la configuración de redes avanzadas, políticas de seguridad y monitorización.

¿Por qué Bare Metal con Cilium y eBPF?

Antes de sumergirnos en el despliegue, es crucial entender por qué esta combinación es tan poderosa para el despliegue clusters 2025.

El problema de las redes tradicionales en Bare Metal

En entornos cloud, el hipervisor abstrae la red. En bare metal, el administrador es responsable de todo el stack de red. Usar soluciones como Flannel (VXLAN) o Calico (con iptables) funciona, pero introduce latencia y limita la escalabilidad. El uso de iptables para el NAT y el balanceo de carga se vuelve un cuello de botella a medida que el clúster crece.

eBPF: El nuevo plano de control del kernel

eBPF (Extended Berkeley Packet Filter) permite ejecutar programas sandboxeados dentro del kernel de Linux sin necesidad de modificar el código fuente del kernel ni cargar módulos. Cilium aprovecha esto para:

Reemplazar kube-proxy completamente: Cilium puede manejar el balanceo de carga de servicios (ClusterIP, NodePort, LoadBalancer) mediante programas eBPF, eliminando la necesidad de iptables.
Redes de alto rendimiento: Ofrece conectividad de pod a pod con encapsulación (VXLAN/Geneve) o modo nativo de capa 2/3, con una latencia mínima.
Seguridad a nivel de kernel: Las políticas de red se aplican directamente en el kernel, permitiendo inspeccionar tráfico con un overhead casi nulo.

[INFO] Si estás migrando desde un cloud a on-premise, Cilium es la herramienta que te permitirá mantener la misma agilidad operativa sin depender de soluciones propietarias.

Planificación del Hardware y Sistema Operativo

Un clúster bare metal exitoso comienza con un hardware bien dimensionado. Para un clúster de producción en 2025, considera:

Requisitos mínimos por nodo

CPU: x86_64 o ARM64 (con soporte para eBPF). Al menos 4 cores para el plano de control, 8+ para workers.
RAM: 16 GB para control-plane, 32 GB+ para workers (dependiendo de la carga).
Almacenamiento: NVMe SSD para etcd y almacenamiento de estado.
Red: Interfaces de 10 Gbps o superiores. eBPF se beneficia enormemente de NICs modernas.

Sistema Operativo

Elige una distribución Linux moderna con kernel 5.10 o superior (recomendado 6.x para mejores características de eBPF). Las opciones más sólidas son:

Ubuntu 24.04 LTS (kernel 6.8+)
Debian 12 (kernel 6.1+)
Flatcar Container Linux (optimizado para contenedores)

[WARNING] Evita kernels antiguos (como RHEL 8 con kernel 4.18) sin habilitar los módulos de eBPF adecuados. Cilium requiere CONFIG_DEBUG_INFO_BTF=y para funcionar al máximo rendimiento.

Instalación del Clúster Kubernetes

Para este tutorial, asumiremos que tienes 3 nodos (1 control-plane, 2 workers) con acceso SSH y conectividad de red entre ellos.

Paso 1: Preparar los nodos

En cada nodo, ejecuta:

# Habilitar módulos del kernel necesarios para eBPF
cat <<EOF | sudo tee /etc/modules-load.d/cilium.conf
br_netfilter
overlay
EOF

sudo modprobe br_netfilter
sudo modprobe overlay

# Configurar sysctl para redes
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

Paso 2: Instalar kubeadm, kubelet y kubectl

Sigue las instrucciones oficiales para tu distribución. Aquí un ejemplo para Ubuntu:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Paso 3: Inicializar el Plano de Control

En el nodo control-plane, inicializa el clúster. Importante: no uses el plugin de red por defecto (Flannel). Usaremos Cilium más tarde.

sudo kubeadm init --pod-network-cidr=10.0.0.0/16 --service-cidr=10.96.0.0/12

Copia el archivo de configuración de kubeconfig:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Une los nodos worker usando el token generado por kubeadm init.

Despliegue de Cilium con eBPF

Ahora viene la parte clave: instalar Cilium como plugin de red y reemplazar kube-proxy.

Paso 1: Descargar e instalar Cilium CLI

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz

Paso 2: Instalar Cilium en el clúster

Ejecuta el siguiente comando. La opción --set kubeProxyReplacement=true es la que elimina la dependencia de kube-proxy.

cilium install \
  --set kubeProxyReplacement=true \
  --set ipam.mode=cluster-pool \
  --set ipam.operator.clusterPoolIPv4PodCIDRList="10.0.0.0/16" \
  --set ipam.operator.clusterPoolIPv4MaskSize=24 \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set securityContext.capabilities.ciliumAgent=["CHOWN","KILL","NET_ADMIN","NET_RAW","IPC_LOCK","SYS_ADMIN","SYS_RESOURCE","DAC_OVERRIDE","FOWNER","SETGID","SETUID"]

[TIP] La opción encryption.enabled=true con WireGuard es ideal para entornos bare metal donde el tráfico entre nodos no está cifrado por defecto. Añade seguridad sin el overhead de IPsec.

Paso 3: Verificar la instalación

cilium status --wait

Deberías ver algo como:

    /¯¯\
 /¯¯\__/¯¯\    Cilium:         OK
 \__/¯¯\__/    Operator:       OK
 /¯¯\__/¯¯\    Envoy Daemon:   OK
 \__/¯¯\__/    Hubble Relay:   OK
    \__/       ClusterMesh:    disabled

Además, verifica que kube-proxy ya no está corriendo:

kubectl get pods -n kube-system | grep kube-proxy
# No debería mostrar nada

Configuración de Redes Avanzadas

Con Cilium instalado, puedes explotar características que van mucho más allá de la conectividad básica.

Balanceo de Carga con eBPF

Cilium reemplaza kube-proxy con un balanceador de carga implementado en eBPF. Esto significa que los servicios ClusterIP se resuelven en el kernel sin pasar por iptables. Para exponer servicios en bare metal, puedes usar la función LoadBalancer IP Pool.

Crear un pool de IPs públicas (por ejemplo, 192.168.1.200-192.168.1.210):

cat <<EOF | kubectl apply -f -
apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
  name: "public-pool"
spec:
  blocks:
  - cidr: "192.168.1.200/28"
EOF

Crear un servicio con tipo LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx

Cilium asignará automáticamente una IP del pool al servicio.

Políticas de Red a nivel de Kernel

Las NetworkPolicies de Kubernetes se vuelven extremadamente eficientes con Cilium. Puedes aplicar políticas L3/L4 y L7 (con Envoy) sin perder rendimiento.

Ejemplo de política L4:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-http-from-frontend"
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

[WARNING] Las políticas de Cilium se aplican en el kernel. Si bloqueas accidentalmente el tráfico de nodos a pods, podrías perder la conectividad con el clúster. Siempre prueba con políticas de tipo Egress primero.

Optimización del Rendimiento y Monitorización

Ajustes para Máximo Rendimiento

Deshabilitar GRO/LRO: Para cargas de trabajo intensivas en red, deshabilitar Generic Receive Offload puede mejorar la latencia.

sudo ethtool -K eth0 gro off lro off

Aislar CPUs: Usa isolcpus en el kernel para dedicar cores exclusivos a las aplicaciones, evitando que el kernel interrumpa los procesos críticos.
Ajustar el mapa eBPF: Aumenta el límite de mapas eBPF para manejar más conexiones simultáneas.

sudo sysctl -w net.core.bpf_jit_enable=1
sudo sysctl -w net.core.bpf_jit_harden=0

Monitorización con Hubble

Cilium incluye Hubble, una plataforma de observabilidad que te permite ver el tráfico de red en tiempo real.

cilium hubble enable
cilium hubble port-forward&
hubble observe --from-pod default/nginx-xxx --to-pod default/backend-yyy

Esto te mostrará cada paquete, su origen, destino, protocolo y latencia. Es una herramienta invaluable para la optimización servidores en producción.

Casos de Uso Reales para 2025

La combinación de Kubernetes bare metal con Cilium eBPF es ideal para:

Telecomunicaciones: Baja latencia para aplicaciones 5G y edge computing.
Fintech: Cumplimiento de normativas que exigen control total sobre el hardware.
HPC (High Performance Computing): Redes de alto rendimiento para cargas de trabajo de IA/ML.
Gaming: Servidores de juego donde cada milisegundo cuenta.

Conclusión

Desplegar Kubernetes bare metal con Cilium eBPF no es solo una tendencia; es una necesidad para quienes buscan el máximo rendimiento y control. Las redes Kubernetes avanzadas que ofrece eBPF permiten eliminar cuellos de botella históricos, mientras que la seguridad a nivel de kernel protege el clúster sin sacrificar velocidad.

Para 2025, esta arquitectura se ha vuelto no solo viable, sino recomendada. El ecosistema de Cilium ha madurado, con herramientas como Hubble para observabilidad y una integración profunda con el kernel de Linux. Si estás planeando un despliegue clusters 2025, no lo pienses dos veces: bare metal + Cilium + eBPF es el camino.

[INFO] ¿Te ha sido útil este artículo? Comparte tu experiencia o dudas en los comentarios. La comunidad de SysAdmins crece cuando compartimos conocimiento.