Spero che la Parte 1 dedicata a eBPF Le sia piaciuta! Ora analizziamo Cilium come una delle soluzioni eBPF più diffuse per K8s e vediamo che rapporto ha con Dataplane V2.
Cilium 🐝 è una tecnologia del momento, alimentata da eBPF. È spesso la prima cosa che viene in mente quando si parla di eBPF, soprattutto in ambito K8s. In sostanza, Cilium è un software open source che funge da plugin CNI per Kubernetes. Offre networking, observability e sicurezza basati su eBPF, con scalabilità e prestazioni ottimali per i team di piattaforma che gestiscono ambienti Kubernetes in cloud e on-premise.
Sfruttando l'Extended Berkeley Packet Filter (eBPF), Cilium porta in K8s tutta una serie di funzionalità interessanti. Vediamole più da vicino.
Network Policies 🕸
Adottare il principio del Least Privilege è una buona prassi quando si tratta della comunicazione tra i pod K8s. Le Network Policies di base di K8s (che operano a livello L3/L4) svolgono bene il loro lavoro, ma è possibile arricchirle con le Cilium Network Policies (che operano a livello L3-L7).
Si tratta di un aspetto particolarmente utile nel mondo di K8s e dei microservizi, perché analizzare e controllare il traffico di rete sulla base di metadati come IP e porte serve a poco. IP e porte cambiano in continuazione, mentre i servizi nascono e si spengono. Con Cilium può controllare il traffico anche sulla base di Pod, HTTP, gRPC, Kafka, DNS e altri metadati.
Per esempio, può definire regole HTTP che consentono una specifica chiamata API da un determinato pod in base a path, header e metodo della richiesta. Oppure può definire regole DNS basate su FQDN, in modo da consentire solo le query verso un dominio specifico. Questo ci permette di scrivere policy di sicurezza più rilevanti e davvero applicabili ai casi d'uso reali.
Connettività multi-cluster 🔗
Tramite una cluster mesh, Cilium permette ai pod K8s di comunicare e di essere individuati tra cluster K8s diversi. I casi d'uso includono l'alta disponibilità e il multi-cloud (collegamento tra cluster K8s di provider differenti).
Load Balancing ⚖️
Cilium sostituisce kube-proxy con BPF. kube-proxy si basa su iptables, che sta venendo soppiantato da BPF. Un cambio che migliora drasticamente le prestazioni.
Altre funzionalità
- Crittografia trasparente tra pod, con supporto IPsec/Wireguard
- Prestazioni di rete superiori
- Elevata scalabilità infrastrutturale
- Visibilità più ricca sui flussi di traffico, non solo per IP e porte ma anche per i protocolli L7. Dia un'occhiata a questo articolo su un'interessante sessione di debug del DNS
- Monitoring e maggiore visibilità sugli errori di rete tra i microservizi. Cilium fornisce metriche compatibili con Prometheus
Due parole sulle alternative. Sul mercato esistono altri plugin CNI altrettanto validi. Qui trova un confronto (forse di parte). Anche Calico ha recentemente introdotto un Dataplane eBPF.
Dataplane V2 ✈
Google Cloud Platform tiene GKE (Google Kubernetes Engine) al passo coi tempi integrando Cilium nel proprio meccanismo, Dataplane V2. Ma Dataplane V2 è davvero un Cilium gestito da Google per GKE? In fondo i servizi gestiti ci piacciono tutti, no? La questione merita un'analisi attenta.
Esaminando la documentazione di Google sui concetti di Dataplane V2, non si trova alcuna indicazione né riferimento al progetto Cilium (al momento in cui scriviamo). Tuttavia, nel post ufficiale del blog e in parte della documentazione compaiono alcuni riferimenti minori.
Il control plane di Dataplane V2 viene distribuito come DaemonSet K8s chiamato anetd. Un rapido kubectl describe daemonsets.apps -n kube-system anetd rivela che utilizza l'immagine gke.gcr.io/cilium/cilium:v1.9.4-gke.17.
Quindi, è davvero Cilium? Eseguiamo kubectl exec -n kube-system -ti ds/anetd — cilium version. Ecco l'output:
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
Sì! Si tratta proprio di Cilium 1.9.4! Confrontandola con l'immagine ufficiale di Cilium v1.9.4, però, il risultato è leggermente diverso:
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
Mettiamo ora a confronto le immagini Docker gke.gcr.io/cilium/cilium:v1.9.4-gke.17 e quay.io/cilium/cilium:v1.9.4 con uno strumento come Dive. Sembra esserci qualche differenza nei layer, ma è difficile capire se ci siano variazioni logiche significative rispetto a quanto offerto da Cilium.
Vale anche la pena segnalare che, in questo articolo, si afferma che Google si è impegnata in prima persona contribuendo al progetto Cilium con diverse funzionalità rilevanti. Un segnale di un certo livello di commitment.
Quindi Dataplane V2 = Cilium gestito?
Per ora non posso affermare con certezza che Dataplane V2 sia un Cilium gestito per GKE. E senza una conferma ufficiale, possiamo dire che almeno come prodotto Dataplane V2 ≠ Cilium. Sembra che Cilium venga utilizzato dietro le quinte, ma la documentazione di Google non lo dice né rimanda a quella di Cilium. Si tratta di un'offerta del tutto distinta.
Dai test che ho condotto, alcune funzionalità di Cilium sembrano funzionare anche su Dataplane V2. Tuttavia, non esiste un supporto ufficiale di Google. Inutile dirlo: oggi le funzionalità Cilium "non documentate" su Dataplane V2 potrebbero anche funzionare, ma potrebbero smettere di farlo da un momento all'altro. Meglio quindi non avventurarsi in territori sconosciuti e attenersi alla documentazione ufficiale.
Cilium vanilla o Dataplane V2? 🤔
Ecco un confronto tra le funzionalità.
Le caratteristiche oggi comuni a Cilium e Dataplane V2 sono:
- K8s Network Policies (non CiliumNetworkPolicy, anche se al momento Dataplane V2 non sembra rifiutarle),
- Sostituzione di
kube-proxycon eBPF, - Network Policy Logging. A rigore non è una funzionalità di Cilium, ma è basata su Cilium. Permette di monitorare l'esito delle network policy applicate al traffico.
La mia opinione 💭
Cerco sempre di scegliere la soluzione più semplice possibile. Se è gestita, ancora meglio! Si risparmia tempo prezioso a tutte le parti coinvolte. Dataplane V2 sembra una soluzione gestita più semplice e immediata se tutto ciò che serve è sfruttare le K8s Network Policies, sostituire kube-proxy con eBPF per ragioni di prestazioni e scalabilità e disporre di un logging facile da consultare per gli esiti delle network policy.
Si assicuri solo di tenere a mente le sue limitazioni. Se Le servono funzionalità aggiuntive di Cilium come Hubble, le Cilium L7 Network Policies, la Cluster Mesh, oppure utilizza un'infrastruttura self-hosted o un altro cloud provider, probabilmente Le converrà optare per Cilium vanilla.
Dataplane V2: i pro 👍
- Innanzitutto, è facile da installare. Basta aggiungere il flag
—enable-dataplane-v2quando si crea un nuovo cluster GKE tramitegcloud container clusters create. - È basato sul progetto open source Cilium.
- Dataplane V2 è la base del Network Policy Logging in GKE: una funzionalità molto comoda che genera log quando una connessione viene consentita o negata da una network policy.
- Il plugin
anted, parte di Dataplane V2 (e basato su Cilium), è gestito da Google ed è attualmente in GA (General Availability). È quindi pronto per workloads di produzione, con aggiornamenti e supporto continui. - È ragionevole pensare che Google aggiungerà ulteriori integrazioni con le funzionalità native di GKE, e probabilmente anche con quelle native di Cilium. Una scelta che diventa quindi ancora più convincente in un'ottica di lungo periodo.
Dataplane V2: i contro 👎
- Al momento non sono riuscito a trovare un modo per usare Hubble con Dataplane V2. Hubble è un ottimo strumento di observability targato Cilium, capace di offrire una visibilità preziosa sfruttando l'eBPF di Cilium. Può seguirne gli sviluppi qui.
- Ufficialmente, Dataplane V2 non è una soluzione Cilium gestita. Significa che non può fare affidamento su alcune funzionalità di Cilium che oggi funzionano per Lei su Dataplane V2: in futuro potrebbero smettere di farlo.
- Può essere abilitato solo su un cluster GKE appena creato. Non è quindi possibile attivarlo sui cluster GKE già esistenti.
- Esistono anche altre limitazioni da tenere presenti.
Per iniziare 🏃🏽♀️
Per iniziare con Cilium su K8 — clicchi qui.
Per iniziare con Dataplane V2 su GKE — clicchi qui.
Pro Tip: quando scrive o pianifica i Suoi manifest delle K8s/Cilium Network Policy, utilizzi il Cilium Editor per un'esperienza divertente e sicura.
Il futuro di eBPF
Per quanto rivoluzionaria, questa tecnologia ci riserverà ancora molte soluzioni e sviluppi interessanti basati su eBPF.
Una delle aree potenzialmente più interessate è quella del service mesh. La maggior parte delle soluzioni di service mesh attuali (per esempio Istio o Linkerd) si basa su sidecar proxy collegati ai pod. Una scelta che incide sulle prestazioni, aumenta la complessità e introduce ulteriori punti di guasto. eBPF ha le potenzialità per offrire funzionalità di service mesh sostituendo i sidecar proxy con logica eBPF, rendendo il service mesh accessibile a nuovi casi d'uso.
Restate sintonizzati!
Grazie per la lettura! Per restare in contatto, ci segua sul DoiT Engineering Blog, sul canale LinkedIn DoiT e sul canale Twitter DoiT. Per scoprire le opportunità di carriera, visiti https://careers.doit-intl.com.