Recent, am lucrat la conținut PaaS și tocmai am intrat în contact cu Kubernetes, care implică acoperirea rețelei, adică comunicarea între containere cross-host. Astfel, au apărut o serie de componente open source, precum flanel, calico, weave etc. Aici sunt în principal Calico și Fannel.
Principiul flanelei
Flannel, un proiect dezvoltat de CoreOS, este probabil cel mai direct și popular plugin CNI. Este unul dintre cele mai mature exemple de arhitectură de rețea în sistemele de orchestrare a containerelor și este conceput pentru a permite o rețea mai bună între containere și între host. Odată cu apariția conceptului CNI, pluginul Flannel CNI este o introducere timpurie.
Flanel este relativ ușor de instalat și configurat comparativ cu alte opțiuni. Este ambalat ca un singur binar FlannelD, iar multe instrumente comune de implementare a clusterelor Kubernetes și multe distribuții Kubernetes pot instala Flannel implicit. Flannel poate folosi clusterul etcd existent al clusterului Kubernetes pentru a stoca informațiile sale de stare folosind API-ul, astfel încât nu necesită un depozit dedicat de date.
Flannel configurează o rețea suprapusă IPv4 de Nivel 3. Creează o rețea internă mare care acoperă fiecare nod din cluster. În această rețea Overlay, fiecare nod are o subrețea care este folosită pentru a atribui intern adrese IP. La configurarea unui pod, interfața Docker bridge de pe fiecare nod atribuie o adresă fiecărui container nou. Pod-urile din aceeași gazdă pot comunica folosind bridge-uri Docker, în timp ce pod-urile de pe gazde diferite folosesc flanneld pentru a-și încapsula traficul în pachete UDP, astfel încât să poată fi rutate către destinația corespunzătoare.
Flanel are mai multe tipuri diferite de backend-uri care pot fi folosite pentru încapsulare și rutare. Abordarea implicită și recomandată este să folosești VXLAN, deoarece VXLAN performează mai bine și necesită mai puțină intervenție manuală.
Arhitectura calico
Calico include următoarele componente importante: Felix, etcd, BGP Client și BGP Route Reflector. Următoarele sunt explicațiile fiecăruia dintre aceste componente.
Felix: Responsabil în principal pentru configurarea rutare, configurarea regulilor ACLS și livrarea, acestea există pe fiecare nod.
etcd: Depozitul distribuit cheie-valoare, responsabil în principal pentru consistența metadatelor rețelei, asigurarea acurateței stării rețelei Calico, poate fi partajat cu Kubernetes;
BGPClient (BIRD) este responsabil în principal pentru distribuirea informațiilor de rutare scrise de Felix către nucleu, către rețeaua actuală Calico, pentru a asigura eficiența comunicării între sarcinile de lucru.
Reflectorul BGPRoute (BIRD) este folosit în implementări la scară largă, renunțând la modul mesh de interconectare a tuturor nodurilor și folosind unul sau mai mulți reflectori BGPRoute pentru a finaliza rutarea și distribuția centralizată.
Principiul calicoului
Așa cum se arată în diagrama următoare, procesul este reprezentat de la containerul sursă prin gazda sursă, prin rutarea centrului de date, și în final către gazda destinație și în final alocat containerului de destinație.
Contrast
Din principiul de mai sus, se poate observa că flanel efectuează operații de despachetare a pachetelor pe baza redirecționării rutare, ceea ce irosește resurse de calcul ale CPU-ului. Graficul de mai jos compară performanța diferitelor componente de rețea open source găsite online. Se poate observa că, în termeni de lățime de bandă și latență de rețea, performanța lui Calico și a gazdei este similară.
|
Postat pe 09.11.2020 11:23:01
|
|
|
|
