Soc Òscar Mas i avui m'agradaria ensenyar-vos una de les eines més fascinants de Kubernetes: Istio.
Què és Istio i quin paper té dins Kubernetes
El significat de Istio ve d'una paraula grega que significa "vela", aquesta paraula combina molt bé a la resta de l'ecosistema de Kubernetes.
Istio és una eina que comprèn molts camps dintre de la infraestructura de Kubernetes, que molta gent fa servir (té una gran comunitat al darrera) i s'està tornant un referent gràcies al canvi de paradigma que ha marcat Kubernetes, amb la deprecació del Ingress i a favor del Gateway API (no confondre amb API Gateway).
Quines funcionalitats ofereix Istio
S'ha de tenir en compte que Istio no només és un Gateway API, té moltes més funcionalitats com podrien ser:
- Service Mesh: aquesta filosofia té molts conceptes i eines, però vindria a ser una forma de gestionar la comunicació entre els nostres contenidors, aquesta definició és un bon punt de partida.
- mTLS: és el mecanisme que es permet enviar la comunicació entre els diferents contenidors de manera encriptada i segura.
- Gestió de polítiques de capa 7.
- Observabilitat del que està succeint dintre del nostre clúster.
- i un munt de coses més...
A conseqüència de què Istio és un producte tan versàtil i amb tantes opcions, la complexitat que té és bastant alta en comparació amb altres competidors. També ha de quedar clar que si només volem fer servir un dels serveis com podria ser el Gateway API, realment és igual que els seus competidors. Però Istio té moltes més coses interessants.
Les capacitats clau d’Istio
Podríem dir que els seus punts forts són:
Service resilience
És la idea que els serveis continuen funcionant correctament, encara que falli alguna cosa.
Observability
És el monitoratge del que està passant dintre del nostre clúster de Kubernetes. Per poder entendre, depurar i solucionar les anomalies o els problemes que ens puguin succeir.
Traffic Control
És la gestió del tràfic que es fa entre els contenidors del nostre clúster i tot això a nivell de capa 7.
Security
És la protecció que es pot gestionar entre els diferents serveis de manera automàtica, consistent i basada en la identitat (no en la IP).
Policy enforcement
És fer complir les normes dictades en el nostre clúster: seguretat, tràfic, accés, etc... la idea bàsicament és que encara que l'aplicació estigui mal configurada, la política de seguretat s'aplicarà passi el que passi.
Service Mesh vs Ambient Mesh
Molta gent confon els conceptes de Service Mesh i Ambient Mesh, anem a fer una miqueta de llum d'aquestes idees.
El concepte d'aquestes idees és el mateix, però la implementació que hem d'aplicar per aconseguir cadascuna, és molt diferent. El concepte en general és, controlar el que està succeint dintre del nostre clúster de Kubernetes amb totes les funcionalitats que s'han anat explicant al principi.
Service Mesh
La primera cosa que hem de tenir en compte, és que la paraula Service Mesh és genèrica i hi ha molts altres productes que es poden desplegar per aconseguir un sistema de Service Mesh, com podria ser: LinkerD, Consul Connect, Cilium Service Mesh i un munt d'etcs.
Per dir-ho d'una manera senzilla, la idea del Service Mesh, és afegir a tots els nostres serveis un firewall, per gestionar, controlar i visualitzar, el que està passant. Explicant-ho d'una manera més tècnica, el que es fa és que a cada servei, se li fica un sidecar que té un Envoy Proxy.
Aquest sistema d'afegir un Sidecar als nostres serveis, com és normal, té una càrrega addicional. Encara que el cost per servei és petit, si tenim molts serveis o el nostre clúster és molt gran, pot significar una sobrecàrrega.
Ambient Mesh
En el cas de la paraula Ambient Mesh, no és una paraula genèrica, està associada a Istio i com és normal, tenim diferents productes en el mercat com per exemple: Cilium Service Mesh, que fa el mateix.
El punt més important de l'Ambient Mesh, és que es basa en eBPF, i això vol dir que el nostre sistema de CNI que hem implementat en el nostre clúster, ha de ser gestionat per eBPF, si no, no funcionarà.
La gran avantatja entre el Service Mesh i l'Ambient Mesh, és que en aquest cas, deixem totalment el sistema de sidecars de Envoy que feia servir el Service Mesh i ens centrem en dues peces:
ztunnel:
- Gestió de capa 4
- Reemplaça els sidecars i funciona com DaemonSet
- La seva funcionalitat és interceptar el traffic d'entrada i sortida del node de Kubernetes
waypoint:
- Gestió de la capa 7
- Es gestiona per NameSpace
- La seva funcionalitat és el routing de tràfic, l'observabilitat i policy enforcement
Espero que aquest article us hagi ajudat a entendre què és Istio a Kubernetes. Soc conscient que no he dit totes les funcionalitats que ens pot donar Istio, però crec que aquestes són les més interessants.
