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

Question

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

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 над таблицей маршрутов? Есть ли проблема с производительностью метода таблицы маршрутов?

Answer 1

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

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

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

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

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