Soc Òscar Mas i avui us vull ensenyar un dels CNIs (Container Network Interface) més famosos de Kubernetes: Cilium.
Introducció al CNI
Però com sempre, abans de començar a explicar Cilium, hem de tenir clar que és un CNI. El CNI en resum, és el sistema de networking que fa servir Kubernetes per gestionar internament les comunicacions dels pods entre els nodes del clúster i més coses. Gràcies a aquest sistema de networking, podem fer que els pods es comuniquin entre ells. Podríem fer regles per bloquejar tràfic entre diferents NameSpaces i un munt més de coses...
De CNIs n'hi ha molts, com es pot veure en la documentació oficial de Kubernetes, però nosaltres hem escollit Cillium en aquest cas.
CNIs per defecte en diferents distribucions
Molta gent, es creu per error que quan despleguem un sistema de Kubernetes, és obligatori fer servir el CNI que ens entrega per defecte l'eina que fem servir per instal·lar Kubernetes.
Exemples comuns:
- Si treballem amb KubeSpray, el sistema per defecte que ens instal·larà, serà Calico. Però si no ens agrades Calico com a CNI, i volguéssim instal·lar Cilium, no hi hauria cap problema.
- Si treballem amb K3s, el sistema per defecte que ens instal·larà, serà Flannel. Però si no ens agrades Flannel com a CNI, i volguéssim instal·lar Cilium, no hi hauria cap problema.
Un cop havent-hi escollit el CNI en el qual ens trobem més còmodes (que en el nostre cas és Cilium), hem d'explicar els avantatges que ens dona.
Avantatges principals de Cilium
- Basat en eBPF
- Eliminen el Kube-Proxy (eliminem el famós "doble salto")
- Gateway API
- Egress gateway
- LB IPAM (LoadBalancer IP Address Management)
- Cluster Mesh
- External workloads
- Hubble
- Transparent Encryption (WireGuard / IPSec)
- i una infinitat d'etc...
Basat en eBPF
Abans de començar a treballar amb eBPF, hem de fer un petit aclariment de què és eBPF: és un sistema que en comptes de fer servir eines tipus IPTables o UFW (les quals són eines de Netfilter), per poder gestionar el tràfic de xarxa. eBPF actua com una màquina virtual dins del Kernel, que ens permet gestionar el tràfic.
El gran problema és que tal com funciona IPTables, com més pods agregem al nostre sistema, és més complicat d'escalar. En contraposició d'eBPF, que al ser més directe (recordeu que està dins del Kernel), simplifica molt la gestió.
Avantatges d’eBPF
Com podreu entendre aquest sistema té molts avantatges en contra del seu predecessor:
- Reducció de les latències
- Fa servir menys cicles de CPU per gestionar el tràfic de xarxa
- Com que no fa servir NAT's, preserva la IP del client
- I un sin fi de coses més...
Eliminen el Kube-Proxy
A conseqüència de fer servir eBPF, és necessari deshabilitar el sistema de kube-proxy que fa servir Kubernetes per encaminar i balancejar tot el tràfic que li arriba. Ja que kube-proxy fa servir IPTables, i eBPF elimina la necessita d'IPTables.
Gateway API
Una de les primeres coses que hem de conèixer del Gateway API és:
- No confondre amb API Gateway (són coses diferents)
- La seva funcionalitat és igual que la del Ingress
El problema és que quan treballem amb els Ingress, molts cops són massa simples i necessitem més funcionalitats de les que ens pot donar, d'aquí va néixer el Gateway API, i la seva funcionalitat és substituir en el temps el Ingress tradicional. Aquesta funcionalitat no és nova, va sortir en l'any 2023.
Perquè veieu la gran diferència, aquest és l'esquema conceptual d'un Ingress:
Aquest és l'esquema conceptual d'un Gateway API:
En el segon esquema (Gateway API), podem observar que algunes de les parts, es poden delegar a determinats departaments de la nostra empresa. Fins ara amb el Ingress que es feia servir, es podia fer això, però era molt complicat de gestionar i mantenir.
Avantatges del Gateway API
Però en definitiva, els grans avantatges són:
- Suporta protocols de capa 4 (TCP/UDP) i capa 7 (HTTP/HTTPS)
- Major flexibilitat d'encaminament, incloent possibilitat d'encaminament per "headers"
- Separació de les responsabilitats per rols, que permet a diversos equips interactuar de manera segura.
- Possibilitat d'encaminar per HTTPRoute o TCPRoute, els quals en donen major flexibilitat en el moment d'encaminar el tràfic als nostres serveis.
Com a nota important, existeixen eines per migrar el nostre Ingress a un sistema de Gateway API, com pot ser la que ens proporciona Cilium
Egress Gateway
Aquesta funcionalitat de Cilium, ens permet encaminar el tràfic de determinats pods per un node, amb una IP que hem designat. M'explico:
Avui dia, si un pod que està dintre del clúster de kubernetes ha de travessar un Firewall, que està fora del clúster. L'equip de seguretat que gestiona el Firewall, ens preguntarà quina és la IP d'origen d'aquesta petició. Referent a aquesta pregunta, nosaltres li direm; que el tràfic que li arribarà al seu Firewall pot ser qualsevol de les IP's dels workers de Kubernetes. Ja que en funció d'on estigui el pod, el tràfic sortirà pel worker en el que hi sigui.
Amb l'Egress Gateway, podem fer servir un o diversos nodes, amb una IP específica, d'aquesta manera si l'equip de seguretat ens torna a fer la mateixa pregunta, l'indicarem la IP que s'ha especificat en l'Egress Gateway.
LB IPAM
LB IPAM (LoadBalancer IP Address Management), és una funcionalitat que ens pot entregar IP's en el moment d'aixecar un servei del tipus LoadBalancer. Aquest tipus de funcionalitat, és entregada pel servei Cloud, però si fem servir Cilium On-Premise, aquesta funcionalitat és molt útil. Per fer una similitud, LB IPAM, seria el substitut de MetalLB.
Cluster Mesh
Aquesta funcionalitat que ens aporta Cilium anomenada Cluster Mesh, no s'ha de confondre amb una altra funcionalitat anomenada Service Mesh, que no té res a veure, i està fora de l'abast d'aquest post.
Continuant amb la idea de Cluster Mesh, aquesta funcionalitat ens permet unificar diversos clústers i permetre que un servei pugui accedir a diversos pods repartits entre diferents clústers.
També podríem fer que si uns pods del nostre clúster fallessin per qualsevol motiu, el tràfic s'encaminés capa un altre clúster, fent el que es diu tècnicament un FailOver
External workloads
A vegades ens podem trobar que necessitem gestionar equips que estan fora del clúster de Kubernetes, com si estiguessin dintre del nostre clúster i poder aprofitar tota la potència que ens dona Cilium per poder gestionar-les. Amb aquesta funcionalitat guanyem:
- Visibilitat a nivell de networking
- Poder aplicar network policies
- Fer balanceig de tràfic
Hubble
Hubble és un sistema per monitorar el tràfic que hi ha entre els diferents pods. Gràcies a aquest monitoratge, podem veure perquè el tràfic entre diversos pods, es bloqueja. Tenim dues opcions per veure-ho:
Via GUI:
O via consola:
Aquesta funcionalitat que ens permet tenir una visibilitat (Hubble), és totalment gratuïta. No com altres CNIs, que aquesta funcionalitat només la podem disposar en la versió Enterprise.
Transparent Encryption
Aquesta funcionalitat ens pot sobtar una miqueta, i el dubte és: perquè volem encriptar el tràfic? La resposta té molta lògica quan estem treballant en el cloud.
Qui ens assegura, que els paquets que van des d'un dels nostres pods, que està ubicat en un worker de kubernetes, en anar a un altre pod que està ubicat en un altre node de Kubernetes, no hi ha ningú que ens estigui robant (esnifant) la informació que transita entre els pods.
Amb la funcionalitat de Transparent Encryption, el que fem és encriptar tot el tràfic que surt del nostre node de kubernetes cap als altres nodes. Per fer això tenim dos tipus d'encriptació que podem escollir:
- IPSec
- WireGuard
Si heu de fer servis aquesta característica de Cilium, us aconsellem fer servir WireGuard, per aquests motius:
- A l'estar integrat en el Kernel, té una millor performance
- Cada node de manera automàtica, crea les seves pròpies claus d'encriptació i les distribueix mitjançant una anotació del CRD de Cilium, als altres nodes.
I un sin fi més d'etc...
Espero que us hagi servit d'ajuda. Soc conscient que no he dit totes les funcionalitats que ens pot donar Cilium, però crec que aquestes són les més interessants.
