В чем преимущество использования cni вместо статической таблицы маршрутов в k8s - PullRequest
Новая
       27

В чем преимущество использования cni вместо статической таблицы маршрутов в k8s

0 голосов
/ 29 мая 2019

Добавив статическую таблицу маршрутов на каждый узел с соответствующими правилами, контейнерная сеть также работает нормально. Например, даны три узла с тремя различными подсетями докерного моста: 

node-1(192.168.0.1):
10.0.1.1/24
node-2(192.168.0.2):
10.0.2.1/24
node-3(192.168.0.3):
10.0.3.1/24

На каждом узле добавить следующие маршруты: 

ip route add 10.0.1.0/24 via 192.168.0.1 dev eth0
ip route add 10.0.2.0/24 via 192.168.0.2 dev eth0
ip route add 10.0.3.0/24 via 192.168.0.3 dev eth0

Когда kube-proxy работает в режиме iptables, cluster-service-ip преобразуется в pod ip и, наконец, направляется на связанный узел по таблице маршрутизации.

Так в чем же преимущество использования плагина cni над таблицей маршрутов? Есть ли проблема с производительностью метода таблицы маршрутов?

1 Ответ

1 голос
/ 06 июня 2019

По своему замыслу Кубернетес имеет плавную структуру.Модули, службы, узлы могут приходить и уходить в зависимости от потребностей, либо путем ручных изменений (непрерывное обновление, новые развертывания), либо путем автоматического масштабирования (HPA, автоматическое масштабирование узла).Ручная настройка жесткой структуры сети сводит на нет преимущества динамической среды Kubernetes.

По умолчанию оверлейные сети не требуются, однако они помогают в определенных ситуациях.Например, когда у нас недостаточно IP-пространства или сеть не может обработать дополнительные маршруты.Или, может быть, когда нам нужны дополнительные функции управления, которые предоставляют оверлеи.Один из наиболее распространенных случаев - ограничение количества маршрутов, которые могут обрабатывать таблицы маршрутов облачного провайдера.Например, таблицы маршрутов AWS поддерживают до 50 маршрутов, не влияя на производительность сети.Поэтому, если у нас более 50 узлов Kubernetes, таблицы маршрутов AWS будет недостаточно.В таких случаях помогает использование оверлейной сети.

По сути, это инкапсуляция пакета в пакете, который пересекает собственную сеть через узлы.Возможно, вы не захотите использовать оверлейную сеть, так как это может привести к некоторой задержке и усложнению из-за инкапсуляции-декапсуляции всех пакетов.Часто это не нужно, поэтому мы должны использовать его только тогда, когда знаем, зачем оно нам нужно.

https://itnext.io/an-illustrated-guide-to-kubernetes-networking-part-2-13fdc6c4e24c

Если вы беспокоитесь о задержке и накладных расходах, вызванных плагинами CNI, здесьэто удобный Результаты тестов сетевых плагинов Kubernetes

...