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