All streams
Search
Write a publication
Pull to refresh

Comments 14

Огонь, пиши ещё!

Тоже не одобряю всю эту тягу куберцев к оверлейным сетям.

Дочитав до адресации понял, что статья про юмор. До этого читал серьёзно:-)

Спасибо, очень познавательно!

Круто. Наконец-то кто-то объяснил нормально как calico под копотом работает.

Вопрос - а чем плох VXLAN? Мне тут просто кластер на нем сдали рабочий.

Всем хорош

Но это оверлей, лишние заголовки а автор хотел без них как я понимаю

Вообще то можно при сильном желании собрать кластер прям даже совсем без cni, и базово это будет работать.

Каждый кублет можно настроить выдавать адреса из своего пула, ну и маршруты прописать к ним, статика или динамика, по вкусу.

И это будет даже работать, в среде где вы контролируете сеть, те управляете маршрутизацией.

Но очень часто это не так, и тогда уже без оверлея в том или ином виде не обойтись

А без CNI собрать это как будет выглядеть? И как оно на нескольких нодах будет работать?

Я разобрал лабу три года назад - так что прямо вот с конфигами в руках показать не могу

Но сути такая

- на conroller-manager задается (щас подсмотрел в хелп) что-то вроде

--allocate-node-cidrs
--cluster-cidr - тут указывается сеть например 10.100.0.0/16

Из этой сети будет назначаться блок на каждую ноду
--node-cidr-mask-size

По памяти мне казалось что это распределение иежду нодами я делал в ручном режиме. Но сейчас в Help говорит что нет

--pod-cidr string The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master.


В результате POD после старта получает IP из диапазона --cluster-cidr
Вроде был флаг --network-plugin=kubenet но сейчас судя по документации это поведение изменено, но сути это не меняет


В результате имеем - у ПОДа есть адрес, взятый из диапазона. Осталось дело за малым-обеспечить к нему маршрут "для всех"

В моем тестовом сетапе это решалось ospf и redistribute static/connected/kernel , но протокол маршрутизации может быть любой

Очевидно, что такая настройка нужна каждой ноде. Как только на ней поднимается ПОД то у ноды появляется маршрут, о котором она "рассказывает" через протокол динамической маршрутизации всем остальным, и под становится доступен по сети (в этом сетапе - не только другим подам, а всем кому будет передан маршрут, это удобно или нет в зависимости от того что хотите сделать)

Тут могут быть неточности, так как "живого" кластера под рукой у меня нет, и в ближайшее время восстанавливать его не планировал (ручная сборка с выпуском сертефикатов и настройкой всего с нуля - приличный гимморой)

В моем тестовом сетапе это решалось ospf и redistribute static/connected/kernel , но протокол маршрутизации может быть любой

Но ведь это ровно то чем сейчас занят CNI?

Не совсем
CNI (в моем понимании) в первую очередь предназначен для того что бы реализовать связность и оверлейную сеть там, где физической сетью вы не управляете

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

В моем же сетапе я полностью контролировал как ноды кластера (в моем тестовом сетапе это были малинки), так и сетевую инфраструктуру - маршрутизаторы и свитчи (в моем сетапе эти обе роли играл страрый L3 свитч Catalyst 3560G, старый но не бесполезный)

В случае CNI - у вас пакет прежде чем покинуть ноду инкапсулируется в VXLAN ну или что-то другое (что-то что накодили авторы CNI), что бы внешние адреса были те, что выдал провайдер (а иначе пакет просто никуда не дойдет) "Внутренний мир" кластера, адресация - от провайдера скрыты. Это удобно тем что не требует взяимодействия с провайдером, но требует дополнительных ресурсов на инкапсуляцию/декапсуляцию каждого пакет. Откровенно сказать не таких уж больших ресурсов, но все же.

В случае "без CNI" нет нужды ничего инкапсулировать - вы, контролируя сеть, можете обеспечить доставку пакетов "как есть" без инкапсуляции (и это сильно проще, OSPF уже много лет "просто работает", как минимум в таких простых схемах)

Ну, это именно что ваше понимание, потому что CNI - это набор хуков для настройки сети, которые дёргает рантайм для, собственно, настройки сети. Спецификация CNI не тождественна оверлеям..

Вы несомненно правы, CNI != overlay
Но тем не менее других CNI я не встречал, хотя скорее всего `--network-plugin=kubenet ` тоже по сути CNI

Статья огонь!

соскучился по языку образца журнала }{akep ))

А нету ли планов попробовать всё то же с плагином Flannel ?

Привет. Разве что на пенсии :)
Но кажется у Flanel нет поддержки BGP, и именно что такое же провернуть не удастся

как лучик солнца в пасмурную погоду!

Sign up to leave a comment.

Articles