Soy Òscar Mas y hoy os quiero enseñar uno de los CNIs (Container Network Interface) más famosos de Kubernetes: Cilium.
Introducción al CNI
Pero como siempre, antes de empezar a explicar Cilium, debemos tener claro qué es un CNI. El CNI, en resumen, es el sistema de networking que utiliza Kubernetes para gestionar internamente las comunicaciones de los pods entre los nodos del clúster y más cosas. Gracias a este sistema de networking, podemos hacer que los pods se comuniquen entre ellos. Podríamos crear reglas para bloquear tráfico entre diferentes Namespaces y un montón de cosas más...
De CNIs hay muchos, como se puede ver en la documentación oficial de Kubernetes, pero nosotros hemos escogido Cillium en este caso.
CNIs por defecto en diferentes distribuciones
Mucha gente cree erróneamente que cuando desplegamos un sistema de Kubernetes, es obligatorio utilizar el CNI que nos entrega por defecto la herramienta que usamos para instalar Kubernetes.
Ejemplos comunes:
- Si trabajamos con KubeSpray, el sistema por defecto que nos instalará será Calico. Pero si no nos gusta Calico como CNI y quisiéramos instalar Cilium, no habría ningún problema.
- Si trabajamos con K3s, el sistema por defecto que nos instalará será Flannel. Pero si no nos gusta Flannel como CNI y quisiéramos instalar Cilium, no habría ningún problema.
Una vez hayamos escogido el CNI con el cual nos sentimos más cómodos (que en nuestro caso es Cilium), debemos explicar las ventajas que nos da.
Ventajas principales de Cilium
- Basado en eBPF
- Eliminan el Kube-Proxy (eliminamos el famoso "doble salto")
- Gateway API
- Egress gateway
- LB IPAM (LoadBalancer IP Address Management)
- Cluster Mesh
- External workloads
- Hubble
- Transparent Encryption (WireGuard / IPSec)
- y un sinfín de etc...
Basado en eBPF
Antes de empezar a trabajar con eBPF, debemos hacer una pequeña aclaración de qué es eBPF: es un sistema que, en lugar de utilizar herramientas tipo IPTables o UFW (las cuales son herramientas de Netfilter), permite gestionar el tráfico de red. eBPF actúa como una máquina virtual dentro del Kernel, que nos permite gestionar el tráfico.
El gran problema es que, tal como funciona IPTables, cuantos más pods agregamos a nuestro sistema, más complicado es escalar. En contraposición, eBPF, al ser más directo (recordad que está dentro del Kernel), simplifica mucho la gestión.
Ventajas de eBPF
Como podéis entender este sistema tiene muchas ventajas respecto a su predecesor (el model Legacy):
- Reducción de las latencias
- Utiliza menos ciclos de CPU para gestionar el tráfico de red
- Como no utiliza NATs, preserva la IP del cliente
- Y un sinfín de cosas más...
Eliminan el Kube-Proxy
Como consecuencia de utilizar eBPF, es necesario deshabilitar el sistema kube-proxy que utiliza Kubernetes para enrutar y balancear todo el tráfico que le llega. Ya que kube-proxy usa IPTables, y eBPF elimina la necesidad de IPTables.
Gateway API
Una de las primeras cosas que debemos conocer del Gateway API es:
- No confundir con API Gateway (son cosas diferentes)
- Su funcionalidad es igual que la del Ingress
El problema es que cuando trabajamos con los Ingress, muchas veces son demasiado simples y necesitamos más funcionalidades de las que nos puede dar; de aquí nació el Gateway API, y su funcionalidad es sustituir con el tiempo el Ingress tradicional. Esta funcionalidad no es nueva, salió en el año 2023.
Para que veáis la gran diferencia, este es el esquema conceptual de un Ingress:
Este es el esquema conceptual de un Gateway API:
En el segundo esquema (Gateway API), podemos observar que algunas de las partes pueden delegarse a determinados departamentos de nuestra empresa. Hasta ahora, con el Ingress tradicional, esto se podía hacer, pero era muy complicado de gestionar y mantener.
Ventajas del Gateway API
Pero en definitiva, las grandes ventajas son:
- Soporta protocolos de capa 4 (TCP/UDP) y capa 7 (HTTP/HTTPS)
- Mayor flexibilidad de enrutamiento, incluyendo la posibilidad de enrutar por "headers"
- Separación de responsabilidades por roles, lo que permite a varios equipos interactuar de manera segura
- Posibilidad de enrutar por HTTPRoute o TCPRoute, los cuales nos dan mayor flexibilidad en el momento de encaminar el tráfico a nuestros servicios
Como nota importante, existen herramientas para migrar nuestro Ingress a un sistema de Gateway API, como la que proporciona Cilium.
Egress Gateway
Esta funcionalidad de Cilium nos permite enrutar el tráfico de determinados pods por un nodo con una IP que hemos designado. Me explico:
Hoy en día, si un pod que está dentro del clúster de Kubernetes debe atravesar un Firewall que está fuera del clúster, el equipo de seguridad que gestiona el Firewall nos preguntará cuál es la IP de origen de esa petición. Respecto a esta pregunta, nosotros les diremos que el tráfico que les llegará a su Firewall puede ser cualquiera de las IPs de los workers de Kubernetes. Ya que, en función de dónde esté el pod, el tráfico saldrá por el worker en el que se encuentre.
Con el Egress Gateway, podemos utilizar uno o varios nodos con una IP específica; de esta forma, si el equipo de seguridad nos hace la misma pregunta, les indicaremos la IP que se ha especificado en el Egress Gateway.
LB IPAM
LB IPAM (LoadBalancer IP Address Management) es una funcionalidad que nos puede entregar IPs en el momento de levantar un servicio del tipo LoadBalancer. Este tipo de funcionalidad es entregada habitualmente por el servicio Cloud, pero si usamos Cilium On-Premise, esta funcionalidad es muy útil. Para hacer una similitud, LB IPAM sería el sustituto de MetalLB.
Cluster Mesh
Esta funcionalidad que nos aporta Cilium llamada Cluster Mesh no debe confundirse con otra funcionalidad llamada Service Mesh, que no tiene nada que ver y está fuera del alcance de este post.
Continuando con la idea de Cluster Mesh, esta funcionalidad nos permite unificar varios clústers y permitir que un servicio pueda acceder a varios pods repartidos entre diferentes clústers.
También podríamos hacer que, si unos pods de nuestro clúster fallan por cualquier motivo, el tráfico se enrute hacia otro clúster, haciendo lo que se denomina técnicamente un FailOver.
External workloads
A veces podemos encontrarnos con la necesidad de gestionar equipos que están fuera del clúster de Kubernetes como si estuvieran dentro de nuestro clúster y poder aprovechar toda la potencia que nos da Cilium para gestionarlos. Con esta funcionalidad ganamos:
- Visibilidad a nivel de networking
- Poder aplicar network policies
- Hacer balanceo de tráfico
Hubble
Hubble es un sistema para monitorizar el tráfico que hay entre los diferentes pods. Gracias a este monitoreo, podemos ver por qué el tráfico entre varios pods se bloquea. Tenemos dos opciones para verlo:
Vía GUI:
O vía consola:
Esta funcionalidad que nos permite tener visibilidad (Hubble) es totalmente gratuita. No como otros CNIs, que esta funcionalidad solo está disponible en la versión Enterprise.
Transparent Encryption
Esta funcionalidad puede sorprendernos un poco, y la duda es: ¿por qué queremos encriptar el tráfico? La respuesta tiene mucha lógica cuando trabajamos en la nube.
¿Quién nos asegura que los paquetes que van desde uno de nuestros pods, que está ubicado en un worker de Kubernetes, al ir hacia otro pod ubicado en otro nodo de Kubernetes, no hay nadie que esté robando (sniffando) la información que transita entre los pods?
Con la funcionalidad de Transparent Encryption, lo que hacemos es encriptar todo el tráfico que sale de nuestro nodo de Kubernetes hacia los otros nodos. Para hacer esto tenemos dos tipos de encriptación que podemos escoger:
- IPSec
- WireGuard
Si debéis utilizar esta característica de Cilium, os aconsejamos usar WireGuard por estos motivos:
- Al estar integrado en el Kernel, tiene un mejor rendimiento
- Cada nodo crea automáticamente sus propias claves de encriptación y las distribuye mediante una anotación del CRD de Cilium a los otros nodos
Y un sinfín más de etc...
Espero que os haya sido de ayuda. Soy consciente de que no he mencionado todas las funcionalidades que nos puede dar Cilium, pero creo que estas son las más interesantes.
