Recentemente ho lavorato su contenuti PaaS e ho appena entrato in contatto con Kubernetes, che riguarda la copertura di rete, cioè la comunicazione tra container cross-host. Così è emersa una serie di componenti open source, come flanella, calico, weave, ecc. Qui ci sono principalmente Calico e Fannel.
Principio di flanella
Flannel, un progetto sviluppato da CoreOS, è probabilmente il plugin CNI più diretto e popolare. È uno degli esempi più maturi di architettura di rete nei sistemi di orchestrazione dei container ed è progettato per consentire un migliore networking inter-container e inter-host. Con l'ascesa del concetto CNI, il plugin Flannel CNI è una delle prime introduzioni.
La flanella è relativamente facile da installare e configurare rispetto ad altre opzioni. È confezionato come un singolo binario FlannelD, e molti strumenti comuni di deployment per cluster Kubernetes e molte distribuzioni Kubernetes possono installare Flannel di default. Flannel può utilizzare il cluster etcd esistente del cluster Kubernetes per memorizzare le sue informazioni di stato tramite l'API, quindi non richiede uno store dati dedicato.
Flannel configura una rete di sovrapposizione IPv4 di Layer 3. Crea una vasta rete interna che copre ogni nodo del cluster. In questa rete Overlay, ogni nodo ha una sottorete utilizzata per assegnare internamente gli indirizzi IP. Quando si configura un pod, l'interfaccia bridge Docker su ogni nodo assegna un indirizzo a ogni nuovo container. I pod nello stesso host possono comunicare usando bridge Docker, mentre i pod su host diversi usano flanneld per incapsulare il loro traffico in pacchetti UDP in modo da poter essere instradati verso la destinazione appropriata.
La flanella dispone di diversi tipi di backend che possono essere utilizzati per l'incapsulamento e il routing (instradamento). L'approccio predefinito e consigliato è usare VXLAN perché VXLAN funziona meglio e richiede meno interventi manuali.
Architettura in calicotto
La calico include i seguenti componenti importanti: Felix, etcd, BGP Client e BGP Route Reflector. Di seguito sono riportate le spiegazioni di ciascuno di questi componenti.
Felix: Principalmente responsabile della configurazione del routing, della configurazione delle regole ACLS e della consegna, esiste su ogni nodo.
etcd: Lo store chiave-valore distribuito, principalmente responsabile della coerenza dei metadati di rete, garantendo l'accuratezza dello stato della rete Calico, può essere condiviso con Kubernetes;
BGPClient (BIRD) è principalmente responsabile della distribuzione delle informazioni di routing scritte da Felix al kernel della rete Calico attuale per garantire l'efficacia della comunicazione tra i carichi di lavoro.
Il Riflettore BGPRoute (BIRD) è utilizzato in implementazioni su larga scala, abbandonando la modalità mesh di interconnessione di tutti i nodi e utilizzando uno o più Riflettori BGPRoute per completare l'instradamento e la distribuzione centralizzati.
Il principio del calicot
Come mostrato nel diagramma seguente, il processo viene rappresentato dal container sorgente attraverso l'host sorgente, attraverso l'instradamento del data center, infine verso l'host di destinazione e infine assegnato al container di destinazione.
Contrasto
Dal principio sopra indicato, si può vedere che la flanella esegue operazioni di spacco di spacchetti sulla base dell'inoltro di instradamento, il che spreca risorse di calcolo della CPU. Il grafico qui sotto confronta le prestazioni di vari componenti di rete open source trovati online. Si può vedere che, in termini di larghezza di banda e latenza di rete, le prestazioni di Calico e dell'host sono simili.
|
Pubblicato su 09/11/2020 11:23:01
|
|
|
|
