Viene presentato il lancio del progetto Cilium 1.4, in cui, con la partecipazione di Google, Facebook, Netflix e Red Hat, si sta sviluppando un sistema per garantire l'interazione di rete e applicare politiche di sicurezza per contenitori e processi isolati.
Per distinguere tra l'accesso alla rete in Cilium, Viene utilizzato eBPF (Filtro a pacchetto Berkeley) e XDP (eXpress Data Path). Il codice per i componenti a livello utente è scritto in Go ed è distribuito con la licenza Apache 2.0.
Gli script BPF caricati nel kernel Linux sono disponibili sotto la licenza GPLv2.
A proposito di Cilium
La base di Cilium è un processo in background che funziona nello spazio utente e svolge il lavoro di generazione e compilazione di programmi BPF., oltre a interagire con il runtime fornito dai contenitori.
Sotto forma di programmi GMP, sono implementati sistemi per garantire la connettività dei container, integrazione con il sottosistema di rete (reti fisiche e virtuali, VXLAN, Geneve) e bilanciamento del carico.
Il processo in background è integrato con un'interfaccia di amministrazione, un repository di regole di accesso, un sistema di monitoraggio e moduli di integrazione con supporto per Kubernetes, Mesos, Istio e Docker.
Le prestazioni di una soluzione basata su Cilium con un gran numero di servizi e connessioni sono due volte più avanti rispetto alle soluzioni basate su iptables a causa dell'elevato sovraccarico di ricerca delle regole.
Principali innovazioni
Ciglio hai la possibilità di instradare e inoltrare il traffico di servizio tra più cluster Kubernetes.
Viene inoltre proposto il concetto di servizi globali (una variante dei servizi full-service Kubernetes con backend su più cluster).
anche dispone di strumenti per impostare le regole per l'elaborazione delle richieste e delle risposte DNS insieme ai gruppi di contenitori (pod), consentendo di aumentare il controllo sull'utilizzo delle risorse esterne dei contenitori.
Inoltre, c'è il supporto per la registrazione di tutte le richieste e risposte DNS insieme ai pod. Oltre alle regole di accesso a livello di indirizzo IP, adesso è possibile determinare quali query DNS e risposte DNS sono valide e quali devono essere bloccate.
Ad esempio, è possibile bloccare l'accesso a domini specifici o consentire richieste solo per il dominio locale, senza la necessità di tenere traccia delle modifiche nell'associazione dei domini all'IP.
Ciò include la possibilità di utilizzare l'indirizzo IP restituito nel processo di una richiesta DNS per limitare le operazioni di rete successive (ad esempio, è possibile consentire solo l'accesso agli indirizzi IP restituiti durante la risoluzione DNS.
Principali novità della versione 1.4 di Cilium
Nella nuova versione Aggiunto supporto sperimentale per la crittografia trasparente di tutto il traffico tra i servizi. La crittografia può essere utilizzata per il traffico tra diversi cluster, nonché all'interno dello stesso cluster.
È stato anche aggiunto la capacità di autenticare i nodi, consentendo al cluster di essere posizionato su una rete non attendibile.
La nuova funzionalità consente, in caso di malfunzionamenti del backend che assicurano il funzionamento del servizio in un cluster, reindirizzare automaticamente il traffico ai processori di questo servizio in un altro cluster.
Aggiunto supporto sperimentale per interfacce di rete IPVLAN, consentendo prestazioni più elevate e ritardi inferiori nell'interazione tra due contenitori locali;
Aggiunto un modulo per l'integrazione di Flannel, un sistema per automatizzare la configurazione dell'interazione di rete tra i nodi in un cluster Kubernetes, consentendo di lavorare in parallelo o eseguire Cilium su Flannel (interazione di rete Flannel, bilanciamento di Cilium e politiche di accesso).
È stata fornita assistenza sperimentale per definire le regole di accesso basate sui metadati AWS (Amazon Web Services), come tag EC2, gruppi di sicurezza e nomi VPC.
È stata inoltre proposta l'opportunità di lanciare Cilium su GKE (Google Kubernetes Engine su Google Cloud) utilizzando COS (Container Optimized Operating System);
Ciò fornisce un'opportunità di test per utilizzare Sockmap BPF per accelerare la comunicazione tra i processi locali (ad esempio, utile per accelerare l'interazione tra il proxy sidecar ei processi locali).