Onlangs heb ik gewerkt aan PaaS-content, en ik ben net in aanraking gekomen met Kubernetes, wat netwerkdekking inhoudt, oftewel communicatie tussen cross-host containers. Zo zijn er een reeks open source componenten ontstaan, zoals flanellen, calico, weave, enzovoort. Hier zijn vooral Calico en Fannel.
Flanelprincipe
Flannel, een project ontwikkeld door CoreOS, is waarschijnlijk de meest directe en populaire CNI-plugin. Het is een van de meest volwassen voorbeelden van netwerkarchitectuur in containerorkestratiesystemen en is ontworpen om betere inter-container en inter-host netwerken mogelijk te maken. Met de opkomst van het CNI-concept is de Flannel CNI-plugin een vroege introductie.
Flanel is relatief eenvoudig te installeren en te configureren vergeleken met andere opties. Het wordt verpakt als een enkele binaire FlannelD, en veel gangbare Kubernetes-cluster-implementatietools en veel Kubernetes-distributies kunnen Flannel standaard installeren. Flannel kan het bestaande etcd-cluster van de Kubernetes-cluster gebruiken om zijn toestandsinformatie op te slaan via de API, waardoor het geen speciale dataopslag nodig heeft.
Flannel configureert een Layer 3 IPv4-overlaynetwerk. Het creëert een groot intern netwerk dat elke node in de cluster overspant. In dit overlaynetwerk heeft elke node een subnet dat intern wordt gebruikt om IP-adressen toe te wijzen. Bij het configureren van een pod wijst de Docker-bridge-interface op elke node een adres toe aan elke nieuwe container. Pods in dezelfde host kunnen communiceren via Docker-bridges, terwijl pods op verschillende hosts Flanneld gebruiken om hun verkeer in UDP-pakketten te encapsuleren zodat ze naar de juiste bestemming kunnen worden gerouteerd.
Flannel heeft verschillende soorten backends die gebruikt kunnen worden voor encapsulatie en routering. De standaard en aanbevolen aanpak is VXLAN te gebruiken omdat VXLAN beter presteert en minder handmatige interventie vereist.
Calico-architectuur
De calico bevat de volgende belangrijke componenten: Felix, etcd, BGP Client en BGP Route Reflector. Hieronder volgen de uitleg van elk van deze componenten.
Felix: Voornamelijk verantwoordelijk voor routingconfiguratie, ACLS-regelconfiguratie en -levering, het bestaat op elke node.
etcd: Gedistribueerde key-value store, voornamelijk verantwoordelijk voor de consistentie van netwerkmetadata, waarbij de nauwkeurigheid van de Calico-netwerkstatus wordt gegarandeerd, kan gedeeld worden met kubernetes;
BGPClient (BIRD) is voornamelijk verantwoordelijk voor het distribueren van de door Felix geschreven routeringsinformatie naar de kernel naar het huidige Calico-netwerk om de effectiviteit van communicatie tussen workloads te waarborgen.
BGPRoute Reflector (BIRD) wordt gebruikt bij grootschalige implementaties, waarbij de mesh-modus van het verbinden van alle knooppunten wordt verlaten en een of meer BGPRoute Reflectors wordt gebruikt om gecentraliseerde routering en distributie te voltooien.
Het calicoprincipe
Zoals getoond in het volgende diagram, wordt het proces weergegeven van de broncontainer via de bronhost, via de routering van het datacenter, en uiteindelijk naar de bestemmingshost en uiteindelijk toegewezen aan de bestemmingscontainer.
Contrast
Uit het bovenstaande principe blijkt dat Flannel pakket-unpack-unpack-operaties uitvoert op basis van routing forwarding, wat CPU-rekenkrachten verspilt. De onderstaande grafiek vergelijkt de prestaties van verschillende open source netwerkcomponenten die online te vinden zijn. Uit te zien is dat qua bandbreedte en netwerklatentie de prestaties van Calico en de host vergelijkbaar zijn.
|
Geplaatst op 09-11-2020 11:23:01
|
|
|
|
