@Kvaps - по MetalLB 1. У меня, как человеку, долгое время

проработавшему в провайдинге, слово NAT вызывает плохие чуства. Как вспомню сколько core2duo кушает NAT потока 30к пакетов.... Ну вобщем стараюсь его избегать везде где он не нужен.
и в данном случае концепция принятия http трафика в сервис типа LoadBalancer или NodePort вызывает недоумение.

причем, что интересно, в GKE есть два режима LB, при первом все идет через сервисы и NAT, а вот во втором пакеты напрямую на нужные узлы идут сразу в под...

мне не нравится принимать http через сервис. а нравится напрямую в ингресс-контроллер, запущенный с hostnetwork: true

2. Претензии уже не к самому LB, а толпе воинствующих адептов. Которые на любой вопрос про балансер сразу кричат - что надо ставить metalLB - типа оно простое и само заводится. при это адепты эти видимо не читали доки от слова совсем. и не знают о существовании странички Cloud Compatibility в доке. и что прежде чем советовать, стоит узнать о том как сеть построенна у спрашивающего.

3. Претензия к куче хаутушек с обманчиво простой инсталляцией: примените манифест, создайте конфиг-мап и все заработает - что также вызывает жалость к тем, кто попробует применить это знание не в простой L2 сети.

4. Претензия к самой доке металлб. крайне скудно описаны опции для BGP-режима, а опции для bgp-коммюнити в разных частях доки в разных ямл-переменных указываются. communities: vs bgp-communities:

5. Сам я не пробовал, но навскидку у меня есть такой вопрос к скорости переключения: Что будет если упадет узел на котором запущен controller и под с нагрузкой. (т.е. плавающий адрес на этом узле щас находится) ?
будем ждать 7,5 минут стандартных таймаутов, пока поднимется новый под с контроллером ? спикеры же только адрес подставляют и правила фаерволла на узле правят ?

6. Альтернатива в виде keepalived VRRP или pacemaker для таскания ip адреса между узлами мне кажется более надежной и универсальной.

+++++++

Я metallb в глаза не видел и даже доку не открывал , но мне кажется самое простое это каликой по BGP анонсировать podIP и сверху навесить floatingIP , который тоже анонсировать и полагаться на ECMP

Тут все просто: если человек не сможет в процессе натягивания металлб на свой кластер понять нужно оно ему или нет, то такого человека к кластеру лучше не подпускать. И если вопрошающий не в состоянии осилить ридми и сравнить требования со своей инфрой, так опять таки, не нужен ему кластер. А НАТ там кста отключается через политику сервиса (локал) и все замечательно работает. А неосиляторам давно гке прописали

> слово NAT вызывает плохие чуства. Как вспомню сколько core2duo кушает NAT потока 30к пакетов.... Ну вобщем стараюсь его избегать везде где он не нужен. Ну это скорее притензия к кубу а не к MetalLB, в принципе и без ната жить вполне можно с IPVS > мне не нравится принимать http через сервис. а нравится напрямую в ингресс-контроллер, запущенный с hostnetwork: true Ну в общем-то это не проблема, запускай и юзай, с hostNetwork оно прекрасно будет работать. > Что будет если упадет узел на котором запущен controller и под с нагрузкой. (т.е. плавающий адрес на этом узле щас находится) Контроллер занимается только тем, что выдаёт адреса сервисам типа LoadBalancer. У спикеров есть свой leader election, так что в случае краха, если у сервиса несколько эндпоинтов, айпишник просто переедет на другую ноду. если один, то будет ждать пока появится новый под

Кстати, а как ты делаешь failover для ингресс-контроллера, запущенного с hostnetwork: true?

Неистово плюсую