Cilium Kubernetes: 7 Pasos para Networking eBPF Avanzado 2025

Cilium Kubernetes es la solución de networking y seguridad más avanzada basada en eBPF que está revolucionando la forma en que gestionamos redes en entornos cloud-native. En esta guía completa, aprenderás a instalar Cilium en 7 pasos, configurar políticas de seguridad avanzadas, implementar observabilidad con Hubble, y optimizar el rendimiento de tu clúster. Descubre por qué más de 23,000 desarrolladores confían en esta tecnología para reemplazar kube-proxy y mejorar el networking de Kubernetes.

¿Qué es Cilium Kubernetes?

Cilium Kubernetes es una plataforma de networking, seguridad y observabilidad diseñada específicamente para entornos cloud-native que utiliza la tecnología eBPF (extended Berkeley Packet Filter) para proporcionar capacidades avanzadas directamente en el kernel de Linux. A diferencia de CNI tradicionales como Calico o Flannel que dependen de iptables, Cilium opera a nivel de kernel, lo que resulta en un rendimiento superior y menor latencia.

La tecnología eBPF permite a Cilium Kubernetes inspeccionar, filtrar y redirigir tráfico de red sin necesidad de módulos del kernel o cambios en el código de la aplicación. Esto proporciona visibilidad completa del tráfico L3-L7, aplicación de políticas de seguridad granulares, y balanceo de carga distribuido de alto rendimiento.

Con más de 23,000 estrellas en GitHub y adoptado por empresas como Google, AWS, Adobe y Datadog, Cilium se ha consolidado como el CNI de nueva generación para Kubernetes. El proyecto es parte de la Cloud Native Computing Foundation (CNCF) y cuenta con un ecosistema robusto que incluye Hubble para observabilidad y Tetragon para seguridad en tiempo de ejecución.

Características Principales de Cilium Kubernetes

Cilium Kubernetes ofrece un conjunto único de características que lo diferencian de otros CNI:

• Networking basado en eBPF: Rendimiento superior al operar directamente en el kernel de Linux sin overhead de espacio de usuario
• Reemplazo de kube-proxy: Balanceo de carga distribuido con mejor rendimiento y menor consumo de recursos
• Políticas de seguridad L3-L7: Control de tráfico a nivel de HTTP, gRPC, Kafka y DNS con identity-based security
• Observabilidad integrada con Hubble: Visibilidad en tiempo real de flujos de red, métricas y mapas de dependencias de servicios
• Multi-cluster con ClusterMesh: Conectividad y políticas de seguridad unificadas entre múltiples clústeres Kubernetes
• Service Mesh sin sidecars: Capacidades de service mesh implementadas en el kernel, sin la complejidad de Envoy proxies
• Aceleración con XDP: eXpress Data Path para procesamiento de paquetes ultra-rápido en la tarjeta de red
• Cifrado transparente: Encriptación automática de tráfico entre nodos usando WireGuard o IPsec

Arquitectura de Cilium Kubernetes: Componentes Clave

La arquitectura de Cilium Kubernetes se compone de varios componentes que trabajan conjuntamente para proporcionar networking, seguridad y observabilidad:

Cilium Agent: Se ejecuta como DaemonSet en cada nodo del clúster. Es responsable de cargar los programas eBPF en el kernel, gestionar las políticas de red y seguridad, y proporcionar la API local de Hubble. El agente interactúa directamente con el kernel de Linux para configurar el dataplane.

Cilium Operator: Componente de control centralizado que se ejecuta como Deployment. Gestiona tareas que requieren una vista global del clúster, como la gestión de identidades, garbage collection de endpoints, y sincronización con el API server de Kubernetes.

Hubble Server: Integrado en cada Cilium Agent, recopila eventos de eBPF y los expone vía gRPC API. Proporciona visibilidad profunda de todos los flujos de red, incluyendo información de identidad, protocolos de capa 7, y veredictos de políticas de seguridad.

Hubble Relay: Actúa como agregador de datos de Hubble de todos los nodos, proporcionando una API unificada para consultar flujos de red a nivel de clúster. Esencial para la interfaz web de Hubble UI y para herramientas de observabilidad.

Programas eBPF: Código compilado que se ejecuta en el kernel de Linux, interceptando paquetes en diversos puntos (XDP, TC, sockets). Estos programas implementan el forwarding de paquetes, enforcement de políticas, load balancing y telemetría sin salir del kernel.

Requisitos Previos para Instalar Cilium Kubernetes

Antes de instalar Cilium Kubernetes, asegúrate de cumplir con los siguientes requisitos:

• Clúster Kubernetes: Versión 1.24 o superior (recomendado 1.28+)
• kubectl: Cliente de línea de comandos configurado y autenticado
• Helm: Versión 3.x instalado para despliegue de charts
• Kernel Linux: Versión 4.19 o superior (recomendado 5.10+ para funcionalidades completas de eBPF)
• CNI: Si ya tienes un CNI instalado (Calico, Flannel), deberás desinstalarlo primero
• CPU: Mínimo 2 vCPUs por nodo (recomendado 4+ para producción)
• Memoria RAM: Mínimo 2 GB por nodo (recomendado 4-8 GB)
• Conectividad de red: Puertos 4240/TCP (health checks), 4244/TCP (Hubble server), 4245/TCP (Hubble Relay)

Para verificar la compatibilidad de tu kernel con eBPF, puedes ejecutar:

uname -r
# Debe mostrar versión >= 4.19

# Verificar soporte de eBPF
cat /proc/sys/net/core/bpf_jit_enable
# Debe devolver 1 (habilitado)

Paso 1: Instalar Cilium Kubernetes con Helm

La forma más recomendada de instalar Cilium Kubernetes es mediante Helm chart oficial. Primero, añade el repositorio de Cilium:

helm repo add cilium https://helm.cilium.io/
helm repo update

Ahora instala Cilium en el namespace kube-system con configuración optimizada:

helm install cilium cilium/cilium \
  --version 1.18.4 \
  --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=<API_SERVER_PORT> \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set prometheus.enabled=true \
  --set operator.prometheus.enabled=true

Parámetros importantes:

• kubeProxyReplacement=strict: Reemplaza completamente kube-proxy con eBPF para mejor rendimiento
• k8sServiceHost/Port: IP y puerto del API server de Kubernetes (necesario cuando reemplazas kube-proxy)
• hubble.relay.enabled: Habilita Hubble Relay para observabilidad a nivel de clúster
• hubble.ui.enabled: Despliega la interfaz web de Hubble para visualización
• prometheus.enabled: Exporta métricas de Cilium a Prometheus

Puedes obtener la IP del API server con:

kubectl cluster-info | grep 'Kubernetes control plane'
# Extrae la IP y puerto de la URL mostrada

Paso 2: Verificar Estado de Cilium Kubernetes

Después de instalar Cilium Kubernetes, verifica que todos los componentes estén ejecutándose correctamente:

# Verificar pods de Cilium
kubectl get pods -n kube-system -l k8s-app=cilium

# Deberías ver:
# NAME           READY   STATUS    RESTARTS   AGE
# cilium-xxxxx   1/1     Running   0          2m
# cilium-yyyyy   1/1     Running   0          2m

# Verificar Cilium Operator
kubectl get pods -n kube-system -l name=cilium-operator

# Verificar Hubble Relay
kubectl get pods -n kube-system -l k8s-app=hubble-relay

Para una verificación más completa, instala el CLI de Cilium:

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

# Ejecutar test de conectividad
cilium status
cilium connectivity test

El comando cilium connectivity test desplegará pods de prueba y verificará conectividad L3/L4/L7, políticas de red, y funcionalidad de Service.

Paso 3: Configurar Políticas de Seguridad con Cilium Kubernetes

Una de las ventajas principales de Cilium Kubernetes es su capacidad de aplicar políticas de seguridad a nivel L3-L7. Vamos a crear una política que permita tráfico HTTP solo a un endpoint específico:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-access
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
  - toEndpoints:
    - matchLabels:
        app: backend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"
        - method: "POST"
          path: "/api/v1/data"

Esta política permite que los pods con label app=frontend solo puedan hacer peticiones GET a paths que coincidan con /api/v1/.* y POST a /api/v1/data hacia el backend en el puerto 8080. Aplica la política con:

kubectl apply -f cilium-network-policy.yaml

# Verificar políticas activas
kubectl get ciliumnetworkpolicies -A

Para políticas DNS-aware que controlen resolución de nombres:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-external-dns
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: web
  egress:
  - toFQDNs:
    - matchPattern: "*.example.com"
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP

Paso 4: Habilitar Observabilidad con Hubble

Hubble es la plataforma de observabilidad integrada en Cilium Kubernetes. Para acceder a Hubble UI y visualizar los flujos de red en tiempo real:

# Instalar Hubble CLI
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
sudo tar xzvfC hubble-linux-amd64.tar.gz /usr/local/bin
rm hubble-linux-amd64.tar.gz

# Port-forward a Hubble Relay
kubectl port-forward -n kube-system svc/hubble-relay 4245:80 &

# Observar flujos en tiempo real
hubble observe --follow

# Filtrar flujos por namespace
hubble observe --namespace default

# Ver estadísticas de tráfico
hubble status

Para acceder a Hubble UI (interfaz web):

kubectl port-forward -n kube-system svc/hubble-ui 12000:80

# Abre tu navegador en: http://localhost:12000

Hubble UI te mostrará un mapa visual de dependencias de servicios, flujos de red en tiempo real, y análisis de tráfico L7 incluyendo HTTP, gRPC, DNS y Kafka. Puedes filtrar por namespace, labels, veredictos de políticas, y más. Similar a herramientas de monitorización como las que encontrarás en Prometheus Kubernetes, Hubble proporciona insights críticos para debugging y optimización.

Paso 5: Integrar Cilium Kubernetes con Prometheus y Grafana

Para monitorización avanzada, integra Cilium Kubernetes con Prometheus y visualiza métricas en Grafana:

# Las métricas de Cilium están disponibles automáticamente si habilitaste prometheus.enabled=true

# Verificar ServiceMonitor de Cilium
kubectl get servicemonitor -n kube-system

# Las métricas están expuestas en:
# - cilium-agent: :9962/metrics
# - cilium-operator: :9963/metrics
# - hubble: :9965/metrics

Si ya tienes Prometheus instalado con Prometheus Operator, Cilium será descubierto automáticamente. Importa los dashboards oficiales de Grafana para Cilium:

• Dashboard ID 16611: Cilium v1.12+ Metrics
• Dashboard ID 16613: Hubble Metrics
• Dashboard ID 16612: Cilium Operator Metrics

Métricas clave que monitorizar:

• cilium_endpoint_count: Número de endpoints gestionados
• cilium_policy_enforcement_duration_seconds: Latencia de enforcement de políticas
• cilium_drop_count_total: Paquetes descartados por razón (útil para debugging)
• hubble_flows_processed_total: Flujos procesados por Hubble
• cilium_bpf_map_pressure: Presión en mapas eBPF (importante para escalabilidad)

Paso 6: Configurar ClusterMesh para Multi-Cluster

ClusterMesh permite conectar múltiples clústeres Kubernetes con Cilium Kubernetes para service discovery y políticas unificadas. Primero, habilita ClusterMesh en ambos clústeres:

# En el clúster 1
cilium clustermesh enable --service-type LoadBalancer

# En el clúster 2
cilium clustermesh enable --service-type LoadBalancer

# Conectar clúster 1 con clúster 2
cilium clustermesh connect --destination-context cluster2-context

# Verificar estado
cilium clustermesh status

Una vez conectados, los servicios de un clúster son accesibles desde el otro automáticamente. Para exponer un servicio globalmente:

apiVersion: v1
kind: Service
metadata:
  name: global-service
  annotations:
    io.cilium/global-service: "true"
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

Este servicio estará disponible en todos los clústeres conectados con balanceo de carga automático entre regiones. Esto es particularmente útil para arquitecturas multi-cloud similares a las que puedes implementar con Crossplane Kubernetes para gestión de infraestructura.

Paso 7: Optimizar Rendimiento de Cilium Kubernetes

Para maximizar el rendimiento de Cilium Kubernetes en producción:

1. Habilitar aceleración XDP (si tu NIC lo soporta):

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set loadBalancer.acceleration=native

2. Optimizar tamaño de mapas eBPF para clústeres grandes:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set bpf.mapDynamicSizeRatio=0.0025 \
  --set bpf.ctTcpMax=524288 \
  --set bpf.ctAnyMax=262144 \
  --set bpf.natMax=524288

3. Habilitar cifrado transparente con WireGuard:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

4. Configurar Bandwidth Manager para limitación de ancho de banda:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set bandwidthManager.enabled=true

5. Ajustar CPU limits según tu carga:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set resources.limits.cpu=2000m \
  --set resources.limits.memory=2Gi \
  --set operator.resources.limits.cpu=500m

Cilium Kubernetes vs Calico: Comparativa Técnica

A la hora de elegir entre Cilium Kubernetes y Calico, considera estos factores:

Rendimiento: Cilium supera a Calico en benchmarks de throughput y latencia gracias a eBPF. En pruebas de CNI Benchmark, Cilium logra hasta 25% menos latencia y 20% más throughput que Calico con iptables. Calico con eBPF dataplane reduce esta brecha, pero Cilium mantiene ventaja en escenarios L7.

Compatibilidad de kernel: Calico funciona en kernels más antiguos (3.10+) mientras que Cilium requiere 4.19+ (5.10+ recomendado). Para infraestructura legacy, Calico puede ser más apropiado.

Observabilidad: Hubble de Cilium proporciona visibilidad L7 nativa sin necesidad de service mesh adicional. Calico requiere integraciones externas como Istio para funcionalidad similar.

Políticas de seguridad: Ambos soportan NetworkPolicies estándar de Kubernetes. Cilium añade CiliumNetworkPolicy con filtrado HTTP/gRPC/Kafka y identity-based security. Calico ofrece GlobalNetworkPolicy para políticas cluster-wide.

Madurez y ecosistema: Calico tiene más años en producción y mayor adopción empresarial. Cilium está creciendo rápidamente y es el CNI por defecto en Google GKE Dataplane V2 y AWS EKS Anywhere.

Curva de aprendizaje: Calico es más familiar para equipos con experiencia en networking tradicional. Cilium requiere entender conceptos de eBPF pero ofrece mayor flexibilidad a largo plazo.

Casos de Uso Avanzados de Cilium Kubernetes

Cilium Kubernetes brilla en escenarios complejos que otros CNI no pueden resolver eficientemente:

Service Mesh sin sidecars: Implementa funcionalidades de service mesh (mTLS, circuit breaking, retries) directamente en el kernel sin overhead de Envoy proxies. Esto reduce consumo de CPU en 30-50% comparado con Istio tradicional.

Egress Gateway: Fuerza que todo el tráfico saliente de ciertos pods pase por nodos específicos con IPs estáticas, cumpliendo requisitos de whitelisting de firewalls externos:

apiVersion: cilium.io/v2
kind: CiliumEgressGatewayPolicy
metadata:
  name: egress-gateway
spec:
  selectors:
  - podSelector:
      matchLabels:
        app: backend
  destinationCIDRs:
  - 0.0.0.0/0
  egressGateway:
    nodeSelector:
      matchLabels:
        egress-node: "true"

Load Balancing IPAM: Asignación automática de IPs para servicios LoadBalancer sin necesidad de MetalLB o cloud provider:

apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: external-pool
spec:
  cidrs:
  - cidr: 192.168.10.0/24

BGP Control Plane: Anuncia rutas de pods y servicios a routers externos vía BGP, ideal para bare-metal y on-premise. Esto complementa bien estrategias de GitOps que puedes implementar con ArgoCD Kubernetes.

Troubleshooting: Problemas Comunes en Cilium Kubernetes

Problema 1: Pods sin conectividad después de instalar Cilium

Causa: El CNI anterior no fue removido completamente o hay conflictos de configuración.

Solución:

# Verificar que no haya otros CNI
kubectl get pods -n kube-system | grep -E 'calico|flannel|weave'

# Eliminar configuración CNI anterior
sudo rm -rf /etc/cni/net.d/*
sudo systemctl restart kubelet

# Reiniciar pods de Cilium
kubectl rollout restart daemonset/cilium -n kube-system

Problema 2: «BPF filesystem not mounted»

Causa: El filesystem BPF no está montado en los nodos.

Solución:

# En cada nodo, ejecutar:
sudo mount bpffs -t bpf /sys/fs/bpf

# Hacerlo persistente en /etc/fstab:
echo 'bpffs /sys/fs/bpf bpf defaults 0 0' | sudo tee -a /etc/fstab

Problema 3: Alto consumo de memoria en Cilium Agent

Causa: Mapas eBPF con tamaño insuficiente causando presión de memoria.

Solución:

# Verificar presión de mapas eBPF
kubectl exec -n kube-system cilium-xxxxx -- cilium bpf metrics list

# Ajustar tamaños según necesidad (ver Paso 7)

Problema 4: Políticas de red no se aplican

Solución:

# Verificar logs de Cilium Agent
kubectl logs -n kube-system -l k8s-app=cilium --tail=100 | grep -i policy

# Verificar identidades de endpoints
kubectl exec -n kube-system cilium-xxxxx -- cilium endpoint list

# Observar flujos descartados con Hubble
hubble observe --verdict DROPPED

Problema 5: Hubble UI no muestra flujos

Solución:

# Verificar que Hubble esté habilitado
kubectl get daemonset -n kube-system cilium -o yaml | grep -A5 hubble

# Verificar conectividad a Hubble Relay
kubectl exec -n kube-system cilium-xxxxx -- hubble status

# Reiniciar Hubble Relay
kubectl rollout restart deployment/hubble-relay -n kube-system

Seguridad y Best Practices en Cilium Kubernetes

Para despliegues seguros y confiables de Cilium Kubernetes:

Implementa política de denegación por defecto:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: default
spec:
  endpointSelector: {}
  ingress:
  - {}
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  endpointSelector: {}
  egress:
  - {}

Habilita audit mode para validar políticas antes de enforcement:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set policyAuditMode=true

Usa Tetragon para runtime security (detección de amenazas a nivel de kernel):

helm install tetragon cilium/tetragon -n kube-system
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f

Implementa Network Policies granulares por microservicio, no solo por namespace. Define políticas específicas para cada componente de tu aplicación.

Monitoriza eventos de seguridad con Hubble y Falco para detectar comportamientos anómalos. Integra alertas en tu stack de observabilidad junto con herramientas como OpenCost Kubernetes para correlacionar eventos de seguridad con costos.

Actualiza regularmente: Cilium publica releases frecuentemente con mejoras de seguridad y rendimiento. Mantén tu versión actualizada siguiendo el release cycle oficial.

Migración desde Calico/Flannel a Cilium Kubernetes

Si ya tienes un clúster con otro CNI y quieres migrar a Cilium Kubernetes, sigue este proceso seguro:

Paso 1: Backup de configuraciones críticas

kubectl get networkpolicies -A -o yaml > networkpolicies-backup.yaml
kubectl get pods -A -o yaml > pods-backup.yaml

Paso 2: Desinstalar CNI anterior (ejemplo con Calico)

kubectl delete -f https://docs.projectcalico.org/manifests/calico.yaml
kubectl delete daemonset -n kube-system calico-node
kubectl delete deployment -n kube-system calico-kube-controllers

Paso 3: Limpiar configuración CNI en nodos

# En cada nodo worker:
sudo rm -rf /etc/cni/net.d/*
sudo rm -rf /var/lib/cni/*
sudo systemctl restart kubelet

Paso 4: Instalar Cilium (ver Paso 1)

Paso 5: Convertir NetworkPolicies de Calico a CiliumNetworkPolicy si usas características específicas de Calico no soportadas por NetworkPolicy estándar. Usa la herramienta calicoctl convert o convierte manualmente.

Paso 6: Verificar conectividad con cilium connectivity test y recrear pods gradualmente para que obtengan IPs de Cilium.

Para migraciones sin downtime, considera estrategias de clúster dual con herramientas como Velero Kubernetes para backup y migración de workloads.

Conclusión

Cilium Kubernetes representa el futuro del networking en entornos cloud-native gracias a su arquitectura basada en eBPF que proporciona rendimiento superior, seguridad avanzada y observabilidad profunda sin comprometer la simplicidad operacional.

En esta guía has aprendido a instalar Cilium en 7 pasos, configurar políticas de seguridad L3-L7, implementar observabilidad con Hubble, optimizar rendimiento, y resolver problemas comunes. La integración con Prometheus y Grafana te permite monitorizar métricas críticas, mientras que ClusterMesh habilita arquitecturas multi-cluster resilientes.

La adopción de Cilium Kubernetes está creciendo exponencialmente en 2025, siendo el CNI por defecto en GKE Dataplane V2 y soportado nativamente en AWS, Azure y plataformas on-premise. Su comunidad activa de más de 23,000 desarrolladores y respaldo de la CNCF garantizan evolución continua y soporte empresarial.

Ya sea que estés construyendo una nueva infraestructura cloud-native o migrando desde CNI legacy, Cilium ofrece las herramientas necesarias para networking moderno, seguro y observable. Combínalo con herramientas como External Secrets Operator Kubernetes para gestión segura de secretos y Devtron Kubernetes para despliegues automatizados, y tendrás una plataforma DevOps completa y robusta.

El próximo paso es experimentar con características avanzadas como Service Mesh sin sidecars, Egress Gateway, y Tetragon para runtime security. La inversión en aprender eBPF y Cilium se traducirá en aplicaciones más rápidas, seguras y observables que posicionarán tu infraestructura para los desafíos del futuro.

FAQ sobre Cilium Kubernetes

¿Cilium Kubernetes consume más recursos que otros CNI?

No, Cilium Kubernetes con kube-proxy replacement consume menos recursos CPU y memoria que CNI tradicionales. El overhead de eBPF es mínimo comparado con iptables que escala O(n) con el número de servicios. En clústeres con 100+ servicios, Cilium puede reducir CPU usage del dataplane en 40-60%. La memoria base por nodo es de ~200-300MB, similar a Calico.

¿Puedo usar Cilium en clusters Kubernetes on-premise o bare-metal?

Sí, Cilium Kubernetes funciona perfectamente en bare-metal, on-premise y edge environments. No tiene dependencias de cloud providers. Para bare-metal, puedes usar BGP Control Plane para anunciar rutas a routers físicos, y LB IPAM para asignar IPs a servicios LoadBalancer sin necesidad de MetalLB. Cilium es una excelente elección para K3s, MicroK8s y distribuciones on-premise.

¿Cómo actualizo Cilium Kubernetes a una nueva versión?

Actualiza Cilium Kubernetes usando Helm de forma segura:

helm repo update
helm upgrade cilium cilium/cilium --version 1.18.4 --namespace kube-system --reuse-values

Cilium soporta actualizaciones rolling sin downtime. Verifica release notes para breaking changes. Para updates mayores (ej: 1.14 a 1.16), actualiza versión por versión (1.14 → 1.15 → 1.16) para evitar incompatibilidades. Siempre prueba en entorno staging primero.

¿Cilium Kubernetes soporta IPv6 y dual-stack?

Sí, Cilium Kubernetes tiene soporte completo para IPv6-only y dual-stack (IPv4 + IPv6). Habilita dual-stack al instalar:

helm install cilium cilium/cilium --namespace kube-system \
  --set ipv6.enabled=true \
  --set ipv4.enabled=true \
  --set enableIPv6Masquerade=true

Todas las características incluyendo políticas de red, Hubble, y ClusterMesh funcionan en dual-stack.

¿Cilium es compatible con service mesh como Istio o Linkerd?

Cilium Kubernetes puede funcionar como CNI mientras usas Istio/Linkerd como service mesh. Sin embargo, Cilium ofrece funcionalidades de service mesh nativas (mTLS, L7 load balancing, retries) sin necesidad de sidecars, reduciendo complejidad y overhead. Para la mayoría de casos, Cilium Service Mesh elimina la necesidad de Istio/Linkerd. Si requieres características muy específicas de Istio (por ejemplo, WebAssembly filters), puedes usar ambos conjuntamente.