¡Espero que hayas disfrutado el artículo sobre eBPF en la Parte 1! Ahora vamos a analizar Cilium como una solución popular de eBPF para K8s y a ver cómo se relaciona con Dataplane V2.
Cilium 🐝 es una tecnología "de moda" impulsada por eBPF. Suele ser lo primero que se menciona cuando sale el tema de eBPF, sobre todo en el contexto de K8s. Cilium es, básicamente, software de código abierto que actúa como plugin CNI para Kubernetes. Ofrece capacidades de red, observabilidad y seguridad basadas en eBPF, con escala y rendimiento óptimos para los equipos de plataforma que operan entornos Kubernetes en la nube y on-premise.
Gracias al Extended Berkeley Packet Filter (eBPF), Cilium suma a K8s un buen número de funcionalidades interesantes. Veámoslas más de cerca.
Políticas de red 🕸
Aplicar el principio de mínimo privilegio en la comunicación entre pods de K8s es una buena práctica. Las Network Policies básicas de K8s (que operan en L3/L4) cumplen bien su función, pero puedes ir más allá con las Cilium Network Policies (que operan en L3-L7).
Esto resulta muy útil en el mundo de K8s y los microservicios, ya que examinar y controlar el tráfico de red mediante metadatos (por ejemplo, IPs y puertos) aporta poco valor. Las IPs y los puertos cambian todo el tiempo a medida que los servicios se crean y se destruyen. Con Cilium también puedes controlar el tráfico con metadatos de Pod, HTTP, gRPC, Kafka, DNS y más.
Por ejemplo, puedes definir reglas HTTP que permitan que una llamada de API específica se haga desde un pod determinado según la ruta, los headers y los métodos de la solicitud. Otro ejemplo es definir reglas DNS basadas en FQDN, de modo que solo se permitan las consultas hacia un dominio específico. Eso nos permite definir políticas de seguridad mucho más útiles y aplicables a casos de uso reales.
Conectividad multi-cluster 🔗
Mediante un cluster mesh, Cilium permite que los pods de K8s se comuniquen y se descubran entre distintos clusters de K8s. Entre los casos de uso están la alta disponibilidad y el multi-cloud (conectar clusters de K8s entre proveedores de nube).
Balanceo de carga ⚖️
Cilium reemplaza kube-proxy por BPF. kube-proxy usa iptables, que está siendo reemplazado por BPF. Este cambio mejora el rendimiento de forma drástica.
Funcionalidades adicionales
- Cifrado transparente entre pods. Soporte para IPsec/Wireguard
- Mayor rendimiento de red
- Alta escalabilidad de la infraestructura
- Visibilidad enriquecida de los flujos de tráfico, no solo por IPs y puertos, sino también por protocolos L7. Échale un vistazo a este blog sobre una sesión interesante de depuración de DNS
- Monitoreo y mejor visibilidad de los errores de red entre tus microservicios. Cilium ofrece métricas compatibles con Prometheus
Unas palabras sobre las alternativas. Hay otros plugins CNI competentes en el mercado. Aquí va una comparativa (quizá algo subjetiva). Calico también incorporó recientemente un Dataplane basado en eBPF.
Dataplane V2 ✈
Google Cloud Platform mantiene a GKE (Google Kubernetes Engine) al día integrando Cilium en su propio mecanismo, Dataplane V2. Pero ¿es Dataplane V2 realmente un Cilium administrado por Google para GKE? Nos encantan los servicios administrados, ¿verdad? Esto amerita una revisión a fondo.
Al revisar la documentación de Google sobre los conceptos de Dataplane V2, no se encuentra ninguna mención ni referencia al proyecto Cilium (al momento de escribir este artículo). Sin embargo, en el post oficial y en parte de la documentación sí aparecen algunas referencias menores.
El control plane de Dataplane V2 se despliega como un DaemonSet de K8s llamado anetd. Un rápido kubectl describe daemonsets.apps -n kube-system anetd revela que utiliza la imagen gke.gcr.io/cilium/cilium:v1.9.4-gke.17.
Entonces, ¿es realmente Cilium? Ejecutemos kubectl exec -n kube-system -ti ds/anetd — cilium version. Este es el resultado:
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
¡Sí! Efectivamente es Cilium 1.9.4. Sin embargo, al compararlo con la imagen oficial de Cilium v1.9.4, obtenemos un resultado ligeramente distinto:
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
Ahora comparemos las imágenes Docker gke.gcr.io/cilium/cilium:v1.9.4-gke.17 y quay.io/cilium/cilium:v1.9.4 con una herramienta como Dive. Parece haber algunos cambios en las capas, pero me cuesta determinar si existe alguna diferencia lógica importante entre ellas en lo que respecta a las funcionalidades de Cilium.
También vale la pena mencionar que en este post se afirma que Google se sumó al proyecto y aportó varias funcionalidades importantes a Cilium. Creo que eso refleja cierto grado de compromiso.
Entonces, ¿Dataplane V2 = Cilium administrado?
Hasta ahora, no puedo concluir si Dataplane V2 es un Cilium administrado para GKE. Y sin esa confirmación oficial, podemos decir que, al menos como producto, Dataplane V2 ≠ Cilium. Parece que Cilium se usa por debajo, entre bambalinas. La documentación de Google sencillamente no lo menciona ni te remite a la de Cilium. Es una oferta totalmente distinta.
Por las pruebas que hice, algunas funcionalidades de Cilium parecen funcionar en Dataplane V2. Sin embargo, no hay soporte oficial de Google. Ni hace falta decir que las funcionalidades "no documentadas" de Cilium en Dataplane V2 podrían funcionar hoy, pero romperse de forma inesperada en cualquier momento. Por eso, lo mejor es no aventurarse en territorio desconocido. Sigue la documentación oficial para ir sobre seguro.
¿Cilium vanilla o Dataplane V2? 🤔
Aquí va una comparativa de funcionalidades:
Las funcionalidades comunes a Cilium y Dataplane V2 hoy son:
- K8s Network Policies (no CiliumNetworkPolicy, aunque por ahora Dataplane V2 no parece rechazarlas),
- Reemplazo de
kube-proxypor eBPF, - Network Policy Logging. En realidad no es una funcionalidad de Cilium, pero está basada en él. Te permite monitorear los resultados de las coincidencias con tus políticas de red.
Mi opinión 💭
Siempre intento optar por la solución más simple posible. Si encima es administrada, ¡mejor todavía! Ahorra tiempo valioso a todas las partes involucradas. Dataplane V2 parece una solución administrada más simple y fácil si lo único que necesitas es aprovechar las K8s Network Policies, un reemplazo de kube-proxy con eBPF para ganar rendimiento y escala, y el logging fácil de usar de los resultados de las políticas de red.
Eso sí, asegúrate de conocer sus limitaciones. Si necesitas las funcionalidades adicionales de Cilium, como Hubble, las Cilium L7 Network Policies, Cluster Mesh, o si trabajas en un entorno self-hosted o con otro proveedor de nube, lo más probable es que prefieras irte por Cilium vanilla.
Dataplane V2: los pros 👍
- Para empezar, es fácil de instalar. Solo agrega el flag
—enable-dataplane-v2al crear un nuevo cluster de GKE congcloud container clusters create. - Está basado en el proyecto open-source Cilium.
- Dataplane V2 es la base del Network Policy Logging en GKE. Se trata de una funcionalidad muy útil que genera logs cuando una conexión es permitida o denegada por una política de red.
- El plugin
anted, que forma parte de Dataplane V2 (basado en Cilium), está administrado por Google y actualmente se encuentra en GA (General Availability). Esto significa que está listo para workloads de producción, con actualizaciones y soporte continuos. - Es razonable suponer que Google sumará más integraciones con funcionalidades nativas de GKE, y quizá también con funcionalidades nativas de Cilium. Eso vuelve la elección más atractiva si piensas en el largo plazo.
Dataplane V2: los contras 👎
- Hasta el momento no he encontrado la manera de usar Hubble con Dataplane V2. Hubble es una excelente herramienta de observabilidad de Cilium que aporta una visibilidad muy útil aprovechando el eBPF de Cilium. Puedes seguirle el rastro aquí.
- Oficialmente, Dataplane V2 no es una solución de Cilium administrada. Esto significa que no puedes confiar en ciertas funcionalidades de Cilium que hoy te funcionan con Dataplane V2. Podrías encontrarte con fallas en el futuro.
- Solo puedes habilitarlo en un cluster de GKE recién creado. Es decir, no puedes usarlo en tus clusters de GKE existentes.
- Hay otras limitaciones que conviene tener en cuenta.
Cómo empezar 🏃🏽♀️
Para empezar con Cilium en K8s, haz clic aquí.
Para empezar con Dataplane V2 en GKE, haz clic aquí.
Pro Tip: cuando estés escribiendo o planificando tus manifiestos de K8s/Cilium Network Policy, usa el Cilium Editor para una experiencia entretenida y segura.
El futuro de eBPF
Por revolucionaria que sea esta tecnología, me atrevo a predecir que seguiremos viendo muchas más soluciones y desarrollos interesantes basados en eBPF.
Una de esas áreas con potencial de impacto es el mundo del service mesh. La mayoría de las soluciones de service mesh actuales (por ejemplo, Istio o Linkerd) dependen de proxies sidecar adjuntos a tus pods. Eso afecta al rendimiento, agrega complejidad e introduce puntos de falla adicionales. eBPF tiene el potencial de ofrecer capacidades de service mesh reemplazando los proxies sidecar por lógica eBPF, lo que podría hacer que el service mesh sea accesible para más casos de uso.
¡Mantente atento!
¡Gracias por leer! Para seguir conectado, síguenos en el DoiT Engineering Blog, en el canal de DoiT en LinkedIn y en el canal de DoiT en Twitter. Para explorar oportunidades profesionales, visita https://careers.doit-intl.com.