Kubernetes e CNI: analisi tecnica e comparazione dei plugin più utilizzati

Il Networking rimane senza ombra di dubbio uno dei temi più spinosi in ambito Kubernetes. Nel corso del tempo sono state rilasciate varie soluzioni per implementare le specifiche richieste per la comunicazione dei container inter e intra cluster.

Con l’acronimo CNI si indica il termine Container Network Interface, ossia uno standard per facilitare o normalizzare la configurazione dello strato di networking per container. Nell’ecosistema Kubernetes abbiamo a disposizione diversi plugin CNI, i quali fanno sì che siano soddisfatti tutti i requisiti di rete e siano implementate tutte le features che il cluster richiede.

Un pò di technicalities

I container runtime offrono diverse modalità di networking, ognuna per scopi differenti. Per esempio possiamo elencare:

• None: nessuna connettività
• Host: connessione diretta allo stack di rete dell’host
• Default bridge: creazione di un bridge di rete e inter-connessione del container tramite un IP dedicato (modalità di default in Docker)
• Custom bridge: creazione di bridge user-defined, con aggiunta di funzionalità aggiuntive, isolamento, ecc.

Inoltre, al di là delle modalità di networking, è possibile implementare soluzioni multi-host che si basano sull’utilizzo del concetto di overlay network.

L’idea che sta alla base dell’iniziativa CNI è proprio quella di fornire un framework per l’allocazione dinamica delle configurazioni e impostazioni di rete di un container, in ottica di orchestrazione all’interno di un cluster (provisioning).

Il plugin CNI sarà quindi responsabile della creazione dell’interfaccia virtuale, dell’assegnazione dell’IP, delle funzionalità di connettività, ecc. nell’arco dell’intero ciclo di vita del container.

In questo contesto, all’interno del cluster Kubernetes, questa metodologia consente al kubelet di configurare automaticamente lo strato networking per i POD semplicemente chiamando il plugin installato nel cluster.

Glossario

Prima di cominciare con l’analisi dei vari plugin, facciamo chiarezza sulla terminologia utilizzata.

• Layer 2 networking: secondo lo stack OSI corrisponde al layer di dati, ossia ha a che fare con la consegna dei frame tra 2 nodi adiacenti sulla rete (es. Ethernet)
• Layer 3 networking: secondo lo stack OSI corrisponde al layer di networking, ossia si occupa del routing dei pacchetti tra host connessi e si appoggia al layer 2 sottostante (es. IPv4, IPv6, ICMP)
• VXLAN: Virtual eXtensible LAN, è principalmente utilizzata per aiutare lo scaling in ambito cloud di grosse dimensioni, incapsulando i frame Ethernet di livello 2 in datagrammi UDP. Il concetto è simile a quello delle VLAN, offrendo maggiore flessibilità e potenza
• Overlay Network: rete logica virtuale costruita on-top di una rete esistente. Utile per concetti quali l’astrazione e la separazione/segregazione
• Incapsulamento: si intende il processo di wrapping dei pacchetti di rete in layer aggiuntivi.
• Mesh network: una rete mesh è una rete all’interno della quale ogni nodo si connette agli altri nodi per cooperare a livello di routing e ottenere una connettività più estesa e organica
• BGP: Border Gateway Protocol, è utilizzato per gestire la modalità con cui i pacchetti sono ruotati tra i router di frontiera (in alcuni casi arriviamo a questo livello di dettaglio poiché alcuni plugin CNI preferiscono usare il BGP invece dell’incapsulamento in una rete di overlay)

CNI a confronto

1 – Flannel

Sviluppato da CoreOS, è forse il plugin più semplice e popolare. Tra i suoi principali pro sicuramente va citata la facilità di installazione/manutenzione, si installa come singolo binario (flanneld) e inoltre può utilizzare il solito backend etcd del cluster Kubernetes su cui opera.

A livello tecnico Flannel opera tramite un’overlay network IPv4 a livello 3. Ad ogni nodo del cluster viene associata una sottorete dedicata su cui allocare internamente indirizzi IP. Quando viene avviato un POD, l’interfaccia di bridging Docker su ciascun nodo alloca un indirizzo dedicato per ogni container. I POD all’interno di un singolo host comunicano attraverso questo bridge, mentre nel caso di comunicazione tra POD in host differenti Flannel applica un “incapsulamento” dei frame in UDP ed esegue il routing verso la destinazione corretta.

Flannel ha diversi tipi di backend per incapsulamento e routing, anche se il consigliato rimane l’utilizzo di VXLAN.

Giudizio finale: Flannel risulta vincere sul fronte della semplicità, quindi è molto consigliato come scelta iniziale soprattutto per neofiti e operatori ancora non troppo esperti nel troubleshooting di infrastrutture complesse.

2 – Calico

Anche questo progetto è tra i più popolari. A differenza di Flannel non spicca per la sua semplicità ma per prestazioni, affidabilità e versatilità. In generale lo spettro di azione di Calico si estende, oltre che all’aspetto di connettività, anche in ambito security e management di rete.

L’installazione all’interno di un cluster Kubernetes avviene tipicamente attraverso un manifest di deploy.

A differenza di Flannel, Calico non utilizza una rete overlay, bensì configura una rete di livello 3 utilizzando il protocollo BGP per il corretto instradamento dei pacchetti (non si necessità di incapsulamento), con un guadagno prestazionale evidente nonché una agevolazione in caso di debugging (la tecnologia VXLAN rende molto difficile il tracciamento).

Tra le funzionalità avanzate di Calico si annoverano anche strumenti di policy autoritative (migliorando intrinsecamente la sicurezza di comunicazione) e integrazione con prodotti di Service Mesh (per esempio Istio).

Giudizio finale: Calico si pone bene come progetto la cui attenzione si rivolge alle performance e alle funzionalità di sicurezza avanzate, inoltre fornisce anche un supporto commerciale. Di contro la gestione dell’infrastruttura di networking si complica un po’.

3 – Canal

La storia del progetto Canal è particolare, in quanto nasce come unione dei progetti Flannel e Calico. Durante lo sviluppo della soluzione gli stessi contributori si resero conto che non era necessario procedere con un’integrazione quanto piuttosto su una standardizzazione dei due progetti di partenza. Allo stato attuale possiamo considerare Canal un progetto defunto, tuttavia ci si riferisce ancora al termine Canal come best practice di utilizzo congiunto di Flannel + Calico.

Proprio per la sua natura di “intersezione” dei progetti precedenti raccoglie i benefici di entrambe le soluzioni, mitigandone i contro.

Giudizio finale: si presenta come scelta ottimale nel caso in cui si voglia utilizzare in partenza la semplicità di Flannel ma via via si voglia aggiungere funzionalità tramite le caratteristiche aggiuntive di Calico. Ottimo compromesso!

4 – Weave Net

Progetto sviluppato da Weaveworks, offre un paradigma diverso rispetto a quanto visto finora. Weave crea una rete overlay mesh tra ciascuno dei nodi del cluster, andando ad implementare un sistema di instradamento più potente e intelligente.

Per fare ciò Weave si basa su un componente di routing installato su ogni nodo del cluster Kubernetes, Tali router di scambiano informazioni sulla topologia di rete in tempo reale, per mantenere una visione sempre aggiornata. Quando si cerca di inviare traffico verso un POD allocato su di un diverso nodo del cluster, il router weave prende automaticamente la decisione se mandare il pacchetto tramite fast datapah oppure fare fall back verso il metodo sleeve di packet forwarding.

L’approccio fast datapath si basa sul modulo datapath di Open vSwitch, nativo del kernel. La modalità sleeve invece viene mantenuta come backup, agendo tramite incapsulamento, nel caso in cui la topologia di rete non sia stata ancora aggiornata e quindi i router weave non dispongano delle informazioni necessarie per l’instradamento.

Man mano che il traffico fluisce attraverso i router, questi apprendono quali peer sono associati a quali MAC address, consentendo loro di instradare in modo più efficiente con meno hop.

Così come Calico, Weave offre soluzione aggiuntive di policy autoritative e security. Sebbene aggiunga un pizzico di overhead, Weave può essere configurato per criptare automaticamente tutto il traffico (NaCl in caso di sleeve, IPsec in caso di fast datapath).

Giudizio finale: ottima opzione per chi cerca molte funzionalità aggiuntive e scenari di routing molto complessi. Questa soluzione pone un limite di performance in caso di topologie di rete molto estese. Anche in questo caso si ha la possibilità del supporto commerciale.

Bonus track: Cilium

Una menzione speciale merita il progetto Cilium. Tale progetto si configura come una soluzione Layer 3, con aggiunta di funzionalità di policy si sicurezza.

Supporta sia il routing che l’incapsulamento in overlay e funziona molto bene anche in congiunzione con altri plugin CNI.

La menzione speciale risiede nel fatto che al contrario di tutti i plugin elencati finora, tale soluzione non si basa sull’utilizzo delle iptables, bensì sulla tecnologia del kernel Linux chiamata BPF (nello specifico eBPF).

Grazie alla flessibilità della tecnologia BPF, Cilium riesce ad essere ordini di grandezza più performante nello smistamento del traffico nel cluster.

Altro aspetto che si contraddistingue dalle soluzioni precedenti è la possibilità di operare a livello 7, a livello di protocollo HTTP, rendendolo una soluzione API-aware per il networking e la security a livello applicativo.

Soluzioni commerciali

E i grandi vendor di apparati di rete stanno a guardare? Ovviamente no, c’è chi si e mosso da tempo proponendo soluzioni via via sempre più orientate al software-defined (vedi Juniper) o chi ha da poco rilasciato soluzioni che si prospettano davvero molto interessanti e innovative nell’approccio Cloud Native (vedi Arista).

Arista CloudEOS

A partire da una piattaforma già innovativa e ben collaudata, Arista ha deciso recentemente di rilasciare sul mercato 2 nuove offering relative al mondo cloud, con l’intento di approcciare alcune sfide ritenute più critiche nel mondo degli ambienti multi-cloud e Cloud Native, garantendo un’esperienza di rete a livello enterprise (segmentazione, telemetria, monitoraggio, automatic provisioning, issue solving).

Le funzionalità in questione sono le seguenti:

• CloudEOS Multi Cloud
• CloudEOS Cloud Native

Nella fattispecie CloudEOS Cloud Native si configura come un’istanza di EOS direttamente deployata come soluzione CNI su Kubernetes.

Juniper Contrail

Contrail è il bundle di soluzioni SDN rilasciato da Juniper nel lontano 2012, che si è poi negli anni arricchito di sottoprodotti, andando a soddisfare le esigenze del mercato Cloud (Contrail Networking, Contrail Cloud, Contrail Security, Contrail Enterprise Multi-Cloud, Contrail SD-WAN).

La soluzione Contrail si basa sulla piattaforma TungstenFabric. Esiste l’integrazione con i più comuni ed utilizzati sistemi di orchestrazione come Kubernetes, OpenShift, OpenStack e Mesos, e offre diverse modalità di isolamento per container e POD (ma anche banali VM e bare metal).

L’offering Contrail è molto completa e negli anni ha accumulato molti servizi di networking nel suo portfolio:

• Routing e Bridging
• Overlay tramite VXLAN e/o MPLS
• Multi tenant IPAM
• ARP proxy
• DHCP
• DNS multi tenant
• Firewall e load balancing distribuito
• Security Groups
• NAT e BGP

Fonte: Justin Ellingwoo, Comparing Kubernetes CNI Providers: Flannel, Calico, Canal, and Weave, 21 Marzo 2019 aggiornato il 4 dicembre 2019. Articolo pubblicato su www.rancher.com, https://rancher.com/blog/2019/2019-03-21-comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave