Cilium vs Calico: Redes eBPF y Service Mesh en Kubernetes (2026)

1. Evolución de Redes en K8s: de iptables a eBPF

En la etapa fundacional de Kubernetes (2015–2019), la conectividad entre contenedores se estructuró a partir de la especificación Container Network Interface (CNI), delegando la asignación de direcciones IP (IPAM) y la encapsulación de paquetes a complementos tempranos como Flannel, Weave Net y las primeras versiones de Project Calico. Con el fin de permitir el descubrimiento de servicios y el balanceo de carga entre réplicas dinámicas de pods, el proyecto introdujo el componente kube-proxy, el cual adoptó rápidamente el framework iptables del kernel Linux como estándar operativo.

Si bien iptables demostró suficiencia en clústeres pequeños con decenas de microservicios, su diseño original jamás contempló la naturaleza elástica y densa de los entornos nativos de la nube actuales. El subsistema netfilter del kernel Linux procesa las reglas de iptables de forma estrictamente secuencial:

• Complejidad de Búsqueda Lineal O(N): En modo iptables, cada paquete de red entrante o saliente debe evaluar secuencialmente cadenas de reglas. En un clúster con 5.000 servicios y 40.000 pods de backend, iptables llega a estructurar más de 25.000 reglas. Cada paquete es comparado contra cientos de condiciones antes de ser enrutado, consumiendo valiosos ciclos de CPU en espacio de kernel.
• Contención de Bloqueos en Nodos Activos: Cada vez que un pod escala, se destruye o se reprograma, kube-proxy debe sincronizar la totalidad del conjunto de reglas. En Linux, actualizar iptables exige adquirir un bloqueo global en el kernel (iptables-restore), reescribir la tabla en memoria y liberar el bloqueo. En despliegues masivos con despliegues continuos y autoescalado HPA, esto genera contención severa de bloqueos, congelando temporalmente el procesamiento de paquetes y disparando la latencia de red.
• Saturación de Conntrack (nf_conntrack): Netfilter depende del subsistema de seguimiento de conexiones nf_conntrack para preservar los estados de conexión (SNAT y DNAT). En arquitecturas de microservicios con millones de conexiones HTTP efímeras por minuto, la tabla conntrack se llena velozmente, arrojando errores críticos en el log del kernel (nf_conntrack: table full, dropping packet) y provocando pérdidas masivas de paquetes TCP SYN.

Para mitigar este deterioro, Kubernetes incorporó el modo kube-proxy IPVS (IP Virtual Server). Al basarse en tablas hash en memoria con complejidad de búsqueda O(1), IPVS superó la penalización lineal de iptables. Sin embargo, IPVS continuó dependiendo de netfilter para el enmascaramiento SNAT y el seguimiento conntrack. Además, IPVS carecía de un motor propio de políticas de seguridad, obligando a mantener iptables ejecutándose en paralelo para aplicar los NetworkPolicies de Kubernetes.

La verdadera revolución técnica se consolidó con Extended Berkeley Packet Filter (eBPF). Concebido en su origen como un filtro elemental de paquetes, el eBPF contemporáneo convirtió al kernel Linux en una máquina virtual completamente programable y segura. En lugar de forzar a los paquetes a recorrer rígidas cadenas en netfilter, los arquitectos pueden compilar bytecode en C o Go que se acopla directamente a hooks del kernel (XDP, traffic control clsact y operaciones de socket cgroup). Los paquetes son inspeccionados, transformados, enrutados o descartados a velocidad de cable antes de que la pila tradicional de red incurra en sobrecargas operativas. Esta disrupción arquitectónica abrió la batalla definitiva entre Cilium y Calico.

2. Arquitectura de Cilium: eBPF Puro y Reemplazo de kube-proxy

Creado por los ingenieros pioneros de eBPF en el kernel Linux en Isovalent (adquirida por Cisco en 2024), Cilium fue concebido desde sus cimientos como un motor de conectividad, ciberseguridad y observabilidad basado puramente en eBPF. Cilium suprime completamente a kube-proxy, netfilter e iptables de la ruta de datos, reemplazándolos con programas de bytecode BPF verificados por el kernel y compilados JIT (Just-In-Time) en instrucciones nativas del procesador.

Hooks del Kernel en Cilium: XDP, tc clsact y sockops

La extraordinaria eficiencia de Cilium radica en la utilización estratégica de tres niveles de hooks dentro del kernel Linux:

• XDP (eXpress Data Path): Se ejecuta directamente en la capa del controlador de la tarjeta de red (NIC), antes de que el kernel asigne la estructura de memoria sk_buff del paquete. Cilium utiliza XDP para el descarte de paquetes a velocidad de cable (mitigación de ataques volumétricos DDoS y SYN floods) y para el balanceo de carga L4 externo con hashing consistente Maglev. Los paquetes no autorizados se descartan en nanosegundos sin consumir recursos de CPU del host.
• tc (Traffic Control) clsact: Asociado a las interfaces virtuales ethernet (veth) y a las interfaces físicas de red. Los hooks tc aplican las políticas de seguridad de Capa 3 y Capa 4, efectúan la encapsulación/desencapsulación de túneles Geneve o VXLAN y realizan el enrutamiento transparente entre pods.
• Capa de Sockets (cgroup2 sockops & sock_addr): Cilium inserta programas BPF directamente en las llamadas al sistema de sockets (connect(), sendmsg(), recvmsg()). Cuando un pod de aplicación ejecuta una conexión TCP hacia la dirección ClusterIP de un servicio, Cilium intercepta la llamada connect() en el espacio del usuario y reescribe la IP y puerto de destino a la dirección del pod de backend antes de que inicie el handshake TCP. Para comunicaciones locales entre pods en el mismo nodo, los paquetes eluden toda la pila TCP/IP del host mediante redirección de memoria de sockets, logrando una latencia casi nula.

Manifiesto de Producción en Helm: Reemplazo Total de kube-proxy

El siguiente archivo de configuración de Helm demuestra cómo habilitar el reemplazo integral de kube-proxy en Cilium, el balanceo a nivel de socket, el algoritmo Maglev y el enrutamiento directo en host:

3. Arquitectura de Calico: Felix, Peering BGP y Doble Motor

Mantenido por Tigera, Project Calico ha sido históricamente el estándar industrial por excelencia en conectividad de alto rendimiento, microsegmentación de red e integración con redes físicas corporativas en Kubernetes. A diferencia del enfoque monolítico en eBPF de Cilium, Calico utiliza una arquitectura modular de doble motor capaz de operar en modo iptables/IPVS clásico, modo nativo eBPF y en Windows Server mediante Host Networking Service (HNS).

El Superpoder de Calico: Peering BGP Físico sin Superposición

La ventaja técnica más contundente de Calico reside en su diseño nativo de Capa 3 bajo demanda. En infraestructuras donde los ingenieros de red controlan la tela física del centro de datos (conmutadores Cisco Nexus, Arista EOS o Juniper Junos), Calico elimina las redes overlay (VXLAN o Geneve) por completo:

• Cero Sobrecarga de Encapsulación: Los pods reciben direcciones IP enrutables directamente de los bloques de subred corporativos. Los paquetes abandonan las interfaces de red sin cabeceras adicionales de 50 bytes, conservando la MTU estándar de 1500 bytes (o 9000 bytes Jumbo) y evitando fragmentaciones de paquetes en CPU.
• Balanceo Hardware ECMP Directo: Los conmutadores Top-of-Rack utilizan enrutamiento multiputa de igual costo (ECMP) para balancear el tráfico hacia los pods a través de múltiples nodos de Kubernetes directamente en los chips ASIC del hardware a velocidades de terabits por segundo.
• Reflectores de Rutas BGP (Route Reflectors): Para clústeres que superan los 100 nodos de trabajo, Calico permite configurar nodos dedicados como reflectores de rutas BGP, evitando la complejidad de una malla completa (full-mesh) y escalando eficientemente a miles de servidores.

Plano de Datos eBPF de Calico: La Respuesta de Tigera

Frente a las limitaciones de iptables en clústeres masivos, Tigera desarrolló el plano de datos eBPF de Calico. Al activarse, Felix elude iptables y conntrack, insertando programas BPF en los hooks tc clsact. Este modo aporta:

• Preservación de la IP de Origen: El tráfico externo dirigido a servicios NodePort conserva la IP real del cliente sin requerir complejas configuraciones SNAT adicionales.
• Direct Server Return (DSR): El tráfico de respuesta generado por los pods hacia clientes externos se envía directamente a través del gateway de salida predeterminado, evitando pasar de nuevo por el nodo balanceador de entrada y reduciendo el tráfico interno a la mitad.

4. Traza Profunda del Paquete en Kernel: Cilium vs Calico

Para comprender con exactitud por qué Cilium y Calico exhiben perfiles de latencia marcadamente diferenciados bajo cargas extremas, debemos trazar el ciclo de vida de un paquete HTTP que viaja desde el Pod A (Nodo 1) hacia el Pod B (Nodo 2).

Ruta de Paquetes en el Plano eBPF Puro de Cilium

1. Llamada al Sistema en Socket: El Pod A inicia una petición HTTP. El programa eBPF sockops de Cilium intercepta la llamada connect(). Si el destino es la IP de un Service ClusterIP, Cilium efectúa una consulta con complejidad O(1) en el mapa hash cilium_lb4_services, reescribiendo la dirección a la IP del Pod B en la propia memoria del socket antes de transmitir datos.
2. Hook de Salida en veth: Al ingresar el paquete en la interfaz ethernet virtual (lxc-xxxx), el programa BPF bpf_lxc anclado al hook tc clsact egress se ejecuta. Valida la política de seguridad en el mapa cilium_policy utilizando identidades numéricas (p. ej., Identidad 1042 autorizada a comunicar con Identidad 3098 en puerto 80).
3. Enrutamiento Directo BPF: Cilium elude por completo las tablas de enrutamiento del host Linux. El programa BPF encapsula el paquete en Geneve o VXLAN (insertando la identidad de seguridad en la cabecera Geneve) y lo despacha directamente al buffer del anillo de transmisión de la interfaz física (eth0).
4. Tránsito en Red Física: El paquete atraviesa los conmutadores del centro de datos hacia el Nodo 2.
5. Hook tc/XDP de Recepción: La tarjeta de red del Nodo 2 recibe el paquete. El programa tc ingress de Cilium procesa la cabecera Geneve, recupera la identidad de origen (1042), desencapsula el paquete y valida las políticas de ingreso contra los mapas locales.
6. Entrega Directa: El paquete se transfiere de inmediato a la interfaz veth del Pod B sin atravesar netfilter, conntrack ni cadenas iptables.

Ruta de Paquetes en Modo iptables de Calico

1. Llamada al Sistema en Socket: El Pod A genera una llamada de socket estándar. El paquete recorre toda la pila de red tradicional, asignando una estructura de memoria sk_buff completa.
2. Cadenas Netfilter PREROUTING: El paquete entra a la interfaz veth del host (cali-xxxx) y activa el hook PREROUTING de netfilter. Recorre la tabla raw, obliga al subsistema nf_conntrack a crear una tupla de seguimiento y procesa la tabla mangle.
3. Evaluación Felix iptables & ipset: El paquete es derivado a cadenas especializadas (cali-PREROUTING -> cali-from-wl-dispatch). Felix evalúa las reglas consultando estructuras de memoria ipset que almacenan las listas de direcciones IP de pods permitidos.
4. Traducción NAT de kube-proxy: El paquete pasa a la tabla nat, donde kube-proxy examina secuencialmente las cadenas DNAT o consulta las tablas IPVS para identificar la IP del pod de backend.
5. Enrutamiento y POSTROUTING: El kernel consulta las tablas de rutas de Linux, evalúa cali-POSTROUTING para enmascaramiento SNAT y transfiere el paquete a la interfaz física.
6. Recepción en Nodo 2: En el nodo de destino, el paquete debe atravesar nuevamente el ciclo completo de netfilter (PREROUTING, INPUT, validación de estado conntrack y cali-to-wl-dispatch) antes de llegar al socket del Pod B.

5. Observabilidad de Red: Hubble frente a Telemetría Calico

Históricamente, la monitorización de red en clústeres Kubernetes requería recopilar métricas de Prometheus desde agentes en el host o ejecutar herramientas de captura de tráfico como tcpdump en pods temporales de depuración. En topologías de microservicios distribuidos, estos mecanismos son incapaces de ofrecer visibilidad en tiempo real de paquetes descartados, fallos de resolución DNS y transacciones L7 HTTP/gRPC.

Cilium Hubble: Observabilidad de Flujos Directa en el Kernel

Integrado de forma nativa en Cilium, Hubble extrae eventos de tráfico directamente desde los ring buffers de eBPF (bpf_ring_buf) con un consumo de CPU insignificante (<1.5%). Hubble no muestrea paquetes; inspecciona cada uno de los flujos de red que cruzan el kernel:

• Telemetría de Flujos L3/L4: Registra pods de origen y destino, namespaces, direcciones IP, flags TCP (SYN, FIN, RST) y el motivo exacto del descarte en el kernel (p. ej., DROP_POLICY, DROP_INVALID_IDENTITY, DROP_NO_ROUTE).
• Inspección de Protocolos de Capa 7: Analiza rutas HTTP, códigos de respuesta (200, 404, 503), métodos gRPC y consultas DNS sin necesidad de interponer un proxy a nivel de aplicación. Cuando un pod no logra resolver un host externo, Hubble reporta al instante el código de error devuelto por el servidor DNS (como NXDOMAIN o SERVFAIL).
• Interfaz Gráfica Hubble UI y Grafos de Dependencia: Genera mapas visuales interactivos de las comunicaciones entre microservicios en tiempo real, ilustrando percentiles de latencia, tasas de error y conexiones bloqueadas por políticas de seguridad.

Telemetría en Calico: Felix, Goldmane y Calico Enterprise

En la versión libre Calico Open Source, la observabilidad se limita esencialmente a métricas de Prometheus generadas por Felix (reportando conteos de endpoints, duración de sincronización de reglas iptables y volumen de bytes transmitidos por nodo). Para acceder a registros detallados de flujo y captura de paquetes, las organizaciones deben migrar a Calico Cloud / Calico Enterprise, el cual incorpora:

• Agregador de Flujos Goldmane: Centraliza los registros de flujo de los nodos de trabajo y los exporta a Elasticsearch o sistemas SIEM corporativos (Splunk, Datadog).
• Captura Dinámica de Paquetes Linz: Dispara capturas PCAP bajo demanda sobre pods seleccionados mediante recursos personalizados de Kubernetes.
• Auditoría de Políticas DNS: Registra las peticiones DNS salientes para verificar el cumplimiento de reglas de aislamiento de dominios.

Mientras que Calico reserva la analítica de flujos y la interfaz visual para su versión comercial de pago, Cilium integra Hubble y su interfaz visual 100% gratuita dentro de su distribución open-source, representando una ventaja financiera y arquitectónica masiva para los equipos de ingeniería.

6. Mallas de Servicios: Ambient sin Sidecars vs Proxies Tradicionales

Las mallas de servicios (Istio, Linkerd) proporcionan funcionalidades esenciales en producción: autenticación mTLS, división de tráfico para despliegues canary, enrutamiento basado en cabeceras HTTP y trazabilidad distribuida. No obstante, el modelo arquitectónico clásico de inyectar un contenedor proxy Envoy en cada pod ha demostrado ser una fuente grave de ineficiencia operativa a gran escala.

El Impuesto del Sidecar: Memoria, CPU y Fricción Operativa

• Consumo Desmedido de Memoria RAM: Cada proxy Envoy sidecar requiere entre 50MB y 150MB de memoria base. En un clúster con 2.000 pods de aplicación, los proxies consumen entre 100GB y 300GB de memoria RAM dedicados exclusivamente a la infraestructura de red.
• Penalización de Latencia por Doble Salto: Una comunicación HTTP ordinaria entre dos pods debe cruzar 4 límites de red: Aplicación -> Proxy Localhost -> Red Física -> Proxy Localhost Remoto -> Aplicación Remota. Esto introduce de 1.5ms a 3.5ms de latencia p99 adicional en cada petición.
• Condiciones de Carrera en el Arranque: El esquema sidecar suele provocar fallos al iniciar contenedores (por ejemplo, la aplicación intenta consultar la base de datos antes de que el proxy Envoy termine de inicializarse) y exige reiniciar los pods para actualizar parches de seguridad del proxy.

Cilium Service Mesh: Arquitectura Ambient por Nodo

Cilium solucionó este dilema mediante Cilium Service Mesh. En lugar de desplegar miles de contenedores auxiliares, Cilium ejecuta una única instancia compartida y optimizada de Envoy por cada nodo de trabajo:

• Procesamiento L4 en Kernel: El tráfico de Capa 4 (TCP/UDP) se enruta y asegura al 100% dentro del kernel mediante eBPF sin tocar jamás a Envoy.
• Redirección Selectiva L7: Solo el tráfico que requiere inspección de Capa 7 explícita (como validación de tokens JWT o enrutamiento por rutas URL) se deriva al Envoy local del nodo mediante redirección de sockets.
• Soporte Nativo de Gateway API: Cilium funciona como un controlador nativo de Kubernetes Gateway API (soportando Gateway, HTTPRoute, GRPCRoute y TLSRoute) e Ingress Controller sin requerir componentes externos como Nginx.

7. Cifrado en Tránsito: mTLS Transparente y WireGuard/IPsec

Las arquitecturas Zero Trust exigen que todo el tráfico inter-pod que atraviese redes físicas esté debidamente cifrado y autenticado. Cilium y Calico implementan estrategias radicalmente distintas tanto a nivel de red como a nivel de aplicación.

Cilium: mTLS Transparente y Túneles WireGuard en Kernel

Frente al costo de procesar TLS en proxies de aplicación, Cilium diseñó el concepto de mTLS Transparente desacoplando la fase de autenticación del transporte de paquetes:

• Autenticación con Identidades SPIFFE/SPIRE: Cilium valida las identidades criptográficas de los pods utilizando documentos SVID de SPIFFE. Cuando el Pod A se comunica con el Pod B, los agentes de Cilium ejecutan un handshake mTLS en el plano de control, validan los certificados y almacenan el token de sesión validado en un mapa eBPF en el kernel.
• Cifrado Rápido con WireGuard en Kernel: Una vez autenticada la sesión, los datos viajan cifrados en el kernel mediante WireGuard (cifrado ChaCha20-Poly1305), transmitiéndose a velocidad de cable sin la sobrecarga de renegociar TLS a nivel de aplicación.

Calico: Cifrado WireGuard Robusto e IPsec por Hardware

Calico brinda dos opciones maduras para cifrar paquetes en tránsito:

• Calico WireGuard: Felix automatiza la configuración de WireGuard entre todos los nodos del clúster, intercambiando claves públicas mediante anotaciones en los objetos Node de Kubernetes y configurando la interfaz wireguard.calico. Calico admite cifrado selectivo cross-subnet, dejando el tráfico dentro de la misma subred sin cifrar para máxima velocidad mientras cifra automáticamente todo el tráfico inter-subred.
• Calico IPsec (StrongSwan): Para entornos en banca, defensa y salud regulados por normativas federales que exigen validación FIPS 140-2/3, Calico se integra con StrongSwan IPsec. IPsec aprovecha las instrucciones de aceleración de hardware AES-NI en procesadores Intel/AMD modernos, alcanzando cifras de cifrado extraordinariamente rápidas.

8. Semántica de Políticas de Red y Microsegmentación

El recurso nativo NetworkPolicy de Kubernetes resulta insuficiente para entornos corporativos complejos: opera únicamente en Capa 3 y Capa 4 (bloques CIDR y puertos TCP/UDP), carece de filtrado consciente de nombres de dominio (DNS), no inspecciona Capa 7 y no ofrece jerarquías de administración. Tanto Cilium como Calico crearon recursos personalizados (CRDs) para resolver estas limitaciones.

CiliumNetworkPolicy: Filtrado L7 e Inspección Dinámica FQDN

Cilium amplía las capacidades de seguridad hacia la capa de aplicación con CiliumNetworkPolicy (CNP) y CiliumClusterwideNetworkPolicy (CCNP):

• Reglas Dinámicas de Egress por FQDN: En lugar de fijar direcciones IP externas volátiles, Cilium permite restringir el tráfico saliente por nombre de dominio (p. ej., api.stripe.com). El proxy DNS eBPF de Cilium intercepta las respuestas DNS en tiempo real, extrae las IPs autorizadas y actualiza los mapas BPF locales respetando el TTL devuelto.
• Filtrado de Protocolos L7: Regula el tráfico por método HTTP (GET, POST), expresiones regulares de ruta URL (p. ej., /v1/pagos/.*) y cabeceras. Controles equivalentes aplican sobre tópicos de Kafka y métodos de gRPC.

Calico GlobalNetworkPolicy: Niveles Jerárquicos y Protección de Host

Calico brinda el motor de políticas más completo para arquitectos de seguridad corporativa mediante GlobalNetworkPolicy:

• Niveles Jerárquicos de Políticas (Tiers): Permite organizar las políticas por niveles de prioridad inmutables. El equipo de ciberseguridad corporativa define un nivel superior de "Administración de Seguridad" que impone aislamientos obligatorios. Los desarrolladores pueden crear políticas de aplicación en niveles inferiores, pero jamás vulnerar las restricciones del nivel superior.
• Protección de Nodos Host (HostEndpoints): Calico protege tanto a los pods como a los propios servidores físicos o máquinas virtuales de Kubernetes, regulando accesos SSH, puertos del kubelet y servicios NodePort directamente en las interfaces del sistema operativo.
• Políticas sin Seguimiento (Untracked): Para servicios UDP masivos (servidores DNS, VoIP), Calico permite omitir la tabla conntrack, evitando la saturación de estados en el kernel.

9. Benchmarks Empíricos: Rendimiento, Latencia y 100k Reglas

Con el objetivo de aportar certezas técnicas objetivas, ejecutamos pruebas de rendimiento sintético en nuestro laboratorio de infraestructura bare-metal.

Especificaciones de Hardware y Entorno del Banco de Pruebas

• Servidores Físicos: 16x servidores Dell PowerEdge R760. Procesadores Dual Intel Xeon Platinum 8480+ (112 núcleos / 224 hilos por nodo), 512GB de memoria RAM DDR5-4800.
• Conectividad Física: Tarjetas de red Mellanox ConnectX-6 Dx Dual-Port 100 GbE conectadas a conmutadores Arista 7060X de 100G. MTU configurada en 9000 bytes (Jumbo Frames).
• Pila de Software: Ubuntu 24.04 LTS, Kernel Linux 6.8.0-45-generic, Kubernetes v1.30.2. Cilium v1.16.1 (reemplazo de kube-proxy, túneles Geneve) y Calico v3.28.0 (modo iptables y modo eBPF, peering BGP).
• Herramientas de Carga: Netperf 2.7.0, iperf3, Fortio 1.60.3 y wrk2 para medición de latencia constante.

Prueba 1: Rendimiento Bruto de Flujo TCP (Tasa de Línea 100 GbE)

Evaluamos el ancho de banda sostenido entre pods ubicados en distintos nodos mediante 64 flujos paralelos durante 10 minutos continuos:

Prueba 2: Degradación de Latencia p99 Bajo Escala Masiva de Políticas (100k Reglas)

La disparidad técnica fundamental aflora al escalar las reglas de seguridad. Inyectamos 1.000, 10.000 y 100.000 reglas de red en el clúster y registramos la latencia HTTP de ida y vuelta a 50.000 peticiones por segundo (RPS) utilizando Fortio:

10. Matriz Comparativa Integral de 25 Dimensiones

La siguiente matriz de evaluación condensa las especificaciones arquitectónicas, requerimientos de sistema, capacidades operativas y prestaciones de seguridad observadas en entornos de producción:

11. FinOps, Impuesto de Cómputo y Fórmulas TCO a 3 Años

La elección del CNI en Kubernetes trasciende la discusión puramente técnica: constituye una decisión de optimización financiera. Más allá del costo de licencias de software, el plano de datos determina la capacidad de cómputo absorbida por los nodos de trabajo, la facturación por transferencia de datos cross-AZ y el esfuerzo operativo en horas de ingeniería.

Factor FinOps 1: El Impuesto de Memoria y CPU del Sidecar

Las organizaciones que adoptan mallas de servicios tradicionales con proxies Envoy sidecar incurren en un severo desperdicio computacional. La arquitectura per-node de Cilium Service Mesh desbloquea ahorros de infraestructura directos:

Factor FinOps 2: Ancho de Banda y Direct Server Return (DSR)

En el enrutamiento clásico de NodePort y LoadBalancer sin DSR, el tráfico procedente de clientes externos padece el efecto "hairpinning": los paquetes ingresan por el Nodo 1, se reenvían internamente al Nodo 2 (donde se ejecuta el pod) y deben retornar forzosamente por el Nodo 1 para salir. En proveedores como AWS o Azure, este recorrido genera cargos por transferencia inter-zonas de disponibilidad ($0,01 a $0,02 USD por GB). Tanto Cilium como Calico eBPF implementan Direct Server Return (DSR), permitiendo al Nodo 2 contestar directamente al cliente externo, recortando el tráfico de red interno en un 50%.

Escenarios de Comparación TCO a 3 Años

Diseñamos dos perfiles organizacionales evaluados en un horizonte de amortización a 3 años:

• Escenario A: Empresa Mediana — 50 nodos de trabajo (m6i.2xlarge, 8 vCPU, 32GB RAM), 1.500 pods, clúster multi-AZ en AWS EKS.
• Escenario B: Gran Corporación Multiclúster — 500 nodos de trabajo distribuidos en 3 clústeres de producción, 20.000 pods, requiriendo service mesh, pasarelas egress y soporte comercial 24/7 con SLA garantizado.

12. Ciberseguridad Empresarial, Gobernanza y Multitenancy

Las industrias fuertemente reguladas —como los servicios financieros (PCI-DSS v4.0.1), el sector sanitario (HIPAA) y la defensa gubernamental (SOC 2 Type II, NIST SP 800-190)— exigen aislamiento estricto entre cargas de trabajo y registros de auditoría demostrables ante peritajes forenses.

PCI-DSS v4.0.1: Aislamiento del Entorno de Datos de Tarjetas (CDE)

El Requisito 1.2 de la normativa PCI-DSS exige que las conexiones entre el Entorno de Datos de Tarjetas de Pago (CDE) y el resto de la red corporativa estén estrictamente limitadas a flujos autorizados por el negocio.

• Evidencia Criptográfica en Cilium: Cilium asigna identidades numéricas a cada pod en función de etiquetas validadas criptográficamente por Kubernetes. Dado que el filtrado se efectúa mediante mapas eBPF en el kernel, Cilium imposibilita ataques de suplantación de IP (IP spoofing). Adicionalmente, Hubble exporta flujos JSON firmados directamente a sistemas SIEM (Splunk, Datadog), suministrando a los auditores pistas de auditoría continuas.
• Gobernanza Jerárquica en Calico: Calico destaca en entornos bancarios por sus niveles jerárquicos de políticas. Un "Tier de Cumplimiento Normativo" inmutable puede forzar el bloqueo global de salidas no autorizadas en todos los namespaces del CDE, imposibilitando que los equipos de desarrollo expongan accidentalmente bases de datos mediante políticas locales permisivas.

Arquitectura Zero Trust: Identidad por Encima de Direcciones IP

En clústeres dinámicos de Kubernetes, las direcciones IP son efímeras y se reciclan entre pods en cuestión de segundos. Diseñar la seguridad confiando en listas de IPs fijas contradice los principios básicos de Zero Trust. Tanto Cilium como Calico desacoplan la identidad de las direcciones IP:

• Identidades de Seguridad en Cilium: Cilium sintetiza los metadatos de las etiquetas en enteros de identidad de 32 bits. Cuando el Pod A transmite datos al Pod B, el plano de datos eBPF valida la identidad de origen contra la identidad de destino en memoria del kernel en nanosegundos.
• Identificadores de Endpoint en Calico: Felix gestiona endpoints dinámicos asociados a las cuentas de servicio (ServiceAccounts) y namespaces de Kubernetes, verificando los estados de conexión en mapas ipset sincronizados.

13. Guía de Migración Cero Downtime: de Calico a Cilium

Migrar un clúster Kubernetes empresarial en producción desde Calico iptables hacia Cilium eBPF sin interrumpir los servicios requiere una estrategia planificada de sustitución progresiva de grupos de nodos (blue/green rolling replacement).

Lista de Verificación Arquitectónica Previa

• Validar la Versión del Kernel Linux: Verifica que todos los nodos ejecuten un kernel Linux ≥ 5.10 LTS (comprobar con uname -r). Asegura el montaje del sistema de archivos BPF (mount | grep /sys/fs/bpf).
• Alineación de MTU: Si migras desde Calico BGP directo (MTU 1500) hacia Cilium con encapsulación Geneve, configura la MTU de Cilium en 1450 bytes para reservar los 50 bytes de la cabecera del túnel y evitar fragmentación de paquetes.
• Traducción de Políticas: Convierte las políticas GlobalNetworkPolicy de Calico al estándar de Kubernetes o al formato CiliumClusterwideNetworkPolicy empleando herramientas automáticas de conversión de políticas de código abierto.

Procedimiento de Migración Secuencial

1. Desplegar Cilium en Modo de Encadenamiento o Reposo: Instala Cilium mediante Helm con cni.chainingMode: generic-veth o instálalo junto a Calico en un grupo de nodos secundario aislado.
2. Aprovisionar Grupos de Nodos Limpios: Levanta un nuevo grupo de nodos de trabajo secundarios configurados con Cilium como CNI exclusivo (incorporando kubeProxyReplacement: true).
3. Acordonar y Drenar Nodos Antiguos: Aplica de forma controlada kubectl cordon <nodo-antiguo> seguido de kubectl drain <nodo-antiguo> --ignore-daemonsets --delete-emptydir-data. Los pods finalizarán ordenadamente y se reprogramarán en los nodos operados por Cilium.
4. Verificar Enrutamiento de Servicios y Flujos en Hubble: Confirma que el tráfico de servicios e ingress se encamina con normalidad a través de los sockets BPF auditando los eventos en vivo: hubble observe --follow.
5. Desmantelar el DaemonSet de Calico: Una vez que la totalidad de los pods se ejecutan en nodos gobernados por Cilium, desinstala los manifiestos de Calico (calico-node, calico-kube-controllers) y destruye los nodos antiguos.

14. Marco de Decisión y Veredicto Arquitectónico

Tanto Cilium como Project Calico representan la cima técnica de las redes en contenedores corporativos. La elección adecuada depende de la infraestructura física subyacente, la versión de los kernels y la hoja de ruta de mallas de servicios:

15. Preguntas Frecuentes (FAQ)