Напоследък работя по PaaS съдържание и току-що се запознах с Kubernetes, което включва мрежово покритие, тоест комуникация между крос-хост контейнери. Така се появи серия от компоненти с отворен код, като фланел, калико, тъкане и др. Тук са предимно калико и фанел.
Принцип на фланелена
Flannel, проект, разработен от CoreOS, вероятно е най-директният и популярен плъгин за CNI. Това е един от най-зрелите примери за мрежова архитектура в системи за оркестрация на контейнери и е проектирана да осигури по-добра междуконтейнерна и междухостова мрежа. С възхода на концепцията CNI, плъгинът Flannel CNI е ранно въведение.
Flannel е сравнително лесен за инсталиране и конфигуриране в сравнение с други опции. Той е опакован като един двоичен FlannelD, а много често използвани инструменти за разгръщане на клъстери в Kubernetes и много Kubernetes дистрибуции могат да инсталират Flannel по подразбиране. Flannel може да използва съществуващия etcd клъстер на Kubernetes клъстера, за да съхранява информация за състоянието си чрез API, така че не изисква специализирано хранилище за данни.
Flannel конфигурира Layer 3 IPv4 overlay мрежа. Тя създава голяма вътрешна мрежа, която обхваща всеки възел в клъстера. В тази Overlay мрежа всеки възел има подмрежа, която се използва за вътрешно присвояване на IP адреси. При конфигуриране на под, интерфейсът на Docker bridge на всеки възел присвоява адрес на всеки нов контейнер. Подовете в един и същи хост могат да комуникират чрез Docker мостове, докато подовете на различни хостове използват фланелд, за да капсулират трафика си в UDP пакети, така че да могат да бъдат насочени към подходящата дестинация.
Flannel разполага с няколко различни типа бекендове, които могат да се използват за капсулиране и маршрутизиране. По подразбиране и препоръчителният подход е да се използва VXLAN, защото VXLAN работи по-добре и изисква по-малко ръчна намеса.
Калико архитектура
Калико включва следните важни компоненти: Felix, etcd, BGP Client и BGP Route Reflector. По-долу са обясненията на всеки от тези компоненти.
Феликс: Основно отговаря за конфигурацията на маршрутизацията, конфигурацията на правилата на ACLS и доставката, съществува на всеки възел.
etcd: Разпределено хранилище на ключови стойности, основно отговорно за консистентността на метаданните в мрежата, осигурявайки точността на състоянието на мрежата Calico на мрежата, може да се споделя с Kubernetes;
BGPClient (BIRD) основно отговаря за разпределението на маршрутизиращата информация, написана от Felix, към ядрото към настоящата мрежа Calico, за да гарантира ефективността на комуникацията между работните натоварвания.
BGPRoute Reflector (BIRD) се използва при мащабни внедрявания, като се отказва от mesh режима за свързване на всички възли и се използва един или повече BGPRoute Reflectors за централизирано маршрутизиране и разпределение.
Принципът на калико
Както е показано на следващата диаграма, процесът е изобразен от изходния контейнер през изходния хост, през маршрутизирането на центъра за данни, и накрая до дестинационния хост, като накрая се присвоява на дестинационния контейнер.
Контраст
От горния принцип може да се види, че фланелът извършва операции по разопаковане на пакети на базата на маршрутизиране на препращане, което губи изчислителни ресурси на процесора. Графиката по-долу сравнява производителността на различни мрежови компоненти с отворен код, намерени онлайн. Вижда се, че по отношение на честотната лента и латентността на мрежата производителността на Calico и хоста е сходна.
|
Публикувано в 9.11.2020 г. 11:23:01 ч.
|
|
|
|
