Nyligen har jag arbetat med PaaS-innehåll, och jag har precis kommit i kontakt med Kubernetes, som innebär nätverkstäckning, det vill säga kommunikation mellan containers över värdar. Så en rad open source-komponenter har dykt upp, såsom flanell, calico, weave, etc. Här är främst Calico och Fannel.
Flanellprincipen
Flannel, ett projekt utvecklat av CoreOS, är förmodligen det mest direkta och populära CNI-pluginet. Det är ett av de mest mogna exemplen på nätverksarkitektur i containerorkestreringssystem och är utformat för att möjliggöra bättre nätverk mellan containrar och värdar. Med framväxten av CNI-konceptet är Flannel CNI-pluginet en tidig introduktion.
Flannel är relativt enkelt att installera och konfigurera jämfört med andra alternativ. Det är paketerat som en enda binär FlannelD, och många vanliga Kubernetes-klusterdistributionsverktyg samt många Kubernetes-distributioner kan installera Flannel som standard. Flannel kan använda det befintliga etcd-klustret i Kubernetes-klustret för att lagra sin tillståndsinformation via API:et, så det kräver inte en dedikerad datalagring.
Flannel konfigurerar ett lager 3 IPv4-överläggsnätverk. Den skapar ett stort internt nätverk som täcker varje nod i klustret. I detta överliggande nätverk har varje nod ett subnät som används för att tilldela IP-adresser internt. När man konfigurerar en pod tilldelar Docker-brygggränssnittet på varje nod en adress till varje ny container. Poddar i samma värd kan kommunicera med hjälp av Docker-bryggor, medan poddar på olika värdar använder flanneld för att kapsla in sin trafik i UDP-paket så att de kan dirigeras till rätt destination.
Flannel har flera olika typer av backends som kan användas för inkapsling och routing. Standardmetoden och rekommenderad metod är att använda VXLAN eftersom VXLAN presterar bättre och kräver mindre manuell inblandning.
Calico-arkitektur
Calicoen innehåller följande viktiga komponenter: Felix, etcd, BGP Client och BGP Route Reflector. Följande är förklaringarna till var och en av dessa komponenter.
Felix: Huvudsakligen ansvarig för routkonfiguration, ACLS-regelkonfiguration och leverans, den finns på varje nod.
etcd: Distribuerad nyckelvärdeslagring, huvudsakligen ansvarig för konsistens i nätverkets metadata, säkerställer noggrannheten i Calico-nätverkstillståndet, kan delas med Kubernetes;
BGPClient (BIRD) ansvarar främst för att distribuera routningsinformationen som Felix skriver till kärnan till det nuvarande Calico-nätverket för att säkerställa effektiviteten i kommunikationen mellan arbetsbelastningarna.
BGPRoute Reflector (BIRD) används i storskaliga installationer, där mesh-läget för att sammankoppla alla noder överges och istället en eller flera BGPRoute-reflektorer används för att slutföra centraliserad routing och distribution.
Principen om calico
Som visas i följande diagram visas processen från källcontainern via källvärden, genom routningen av datacentret och slutligen till destinationsvärden och slutligen tilldelad destinationscontainern.
Kontrast
Utifrån ovanstående princip kan man se att flannel utför paketupppackningsoperationer baserat på routöverföring, vilket slösar CPU-datorresurser. Diagrammet nedan jämför prestandan för olika öppen källkodskomponenter som finns online. Det kan ses att när det gäller bandbredd och nätverkslatens är prestandan för Calico och värden liknande.
|
Publicerad på 2020-11-09 11:23:01
|
|
|
|
