В общем лучше самому потрогать

да, надо попробовать, где еще "подарят" 300$

а на AWS есть герои?

вопросы в целом такие же)

ну деплой в авс - это ecs инстансы, vpc отедельный с роутами на сетки и их балансер

работало

работал кубер там или впринципе?

работал

но сразу скажу тестовый

когда знакомился с ним самое простое было его апнуть в амазоне

там хватает тестовго акка для пробы? Насколько я помню там можно было на год микроинстанс взять, к8с так не попробуешь?

ну влетел я на пару сот баксов не шибко дорого как для фирмы

я посомтрел как куде-ап поднимает сиде дело в амазоне, все заморочки с сетью и тп, ну и перенес сие дело плавно на баре метал

ну прикруил только балансировщик

разрабы вон тыкают

микросервисы с дискавери апи кубера дружат

дрочат как у них хезелькаст завелся с пол пинка

=) 200 за какой период?

?

я больше тех, кто с gke) про баре я немного в курсе

там нормальная интеграция с нативным load balancer облака гугла

одна из основных плюшек юзать кубер в облаке

хотя на баре метал норм прикрутился балансировщик

внешний

внешний

хапрокся?

не не не

https://github.com/yyyar/gobetween

у него есть экзек дискавери - скриптик дергает

а скриптик из апи кубера берет поды

есть еще https://github.com/kobolog/gorb, но пока нет поддержки куба

тоже видел

гобитвин понравился именно тем что там дискавери можно было с боку прикрутить

короче го подружить с кубером у меня заняло 15 минут

а гденить выложен скрипт?

нет конечно

)

а надо?

было бы неплохо для быстрой пробы, готовое решение так сказать

а вся инфаструктура у тебя внутри кубера?

у меня просто еще есть задача много внутренних сервисов пускать в кубернейтс

не микросервисы переезжают

и как ты завернул “виртуальную” подсеть для сервисов для остальной инфраструктуры?

так через балансер

т.е. для всей инфрастуктуры добавили на гейтвее маршрут на эту виртуальную сеть на этот балансер?

нет

внешние сервисы общаются через балансер

айпи:порт

на балансере

для того он и нужен

ну так у кубера есть NodePort который тоже это делает

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

правда там балансировка на iptables сделана и нет соответсвенно хелфчеков и т.п.

окей, зачем мне дрочить контракт таблицу ноды?

почему трафик сервиса А должен ходиь через ноду, где его нет физически

и мешать тем сервисам которые на той ноде

ты можешь не одну ноду использовать, а любое количество

у меня балансер трафик пускает на прамую на под его айпи и внтуренний порт

да пофиг

Вопрос в том, что под нагрузкой контракт - это беда

он не тюнится до бесконечности

второе

я не хочу что бы через ноды на которых нет физически пода ходил трафик

это зависит от втоей архитектуры, я буду выделять ноды под определенные задачи и только ИП этих нод будут использоваться

делать только одну точку входа тоже не очень красиво, что если она упадет? прикручивать вррп?

а в чем проблема?

вы явно не стлакивались с ппс и таблицей контракта

я ничего плохого не говрю, просто хочу понять кто и как использует, везде есть плюсы и минусы

ERROR: S client not available

у меня на 5 нод полтора ляма ппс - это норма

можно на ты

но при этом я не хочу задумываться на какой ноде апнется конкретный под

если с этим упираться - то нафиг мне кубер

сейчас и так это именно так работает

под каждый микросервис из пула докер нод выбираются те, на которых он жить будет

и резервируются порты

мы хотим намного больше гибкости

но при этом не дрочить таблицу контракта

а что такое таблица контракта?

или это вы так называете conntrack?

ну та

оё

балансировщики вне куба?

да

их два

но при этом не дрочить таблицу контракта

а в чем боль? В том, что kube-proxy генерирует правила для NAT, которые потенциально медленно работают? И поэтому юзерспейс-балансировщик на го предположительно работает быстрее?

он раотает быстрее

это раз

а тесты проводили? Хинт: если у вас модуль ядра подгружен и нет правил, которые бросают трафик на NOTRACK, то ни разу он быстрее не работает. афаик kube-proxy умеет работать в режиме, в котором трафик через него не идет совсем.

ну да

быстрее только nginx stream

nginx stream + conntrack работает быстрее чем conntrack?

как балансировщик

трафик прет на прямую на айпи подов и их внутрение порты

минуя контракт ноды

еще раз: если модуль загружен, и в raw нет NOTRACK-правил, трафик хоть и идет напрямую, всё равно отмечается в conntrack.

алсоу, conntrack от connection tracking, а не от contract.

вы сомтрели как реализованно в правилах iptables все это поведение?

мне лично не понравилось

это мое мнение, я никому его не навязываю

афаик, там правила в prerouting/postrouting таблицах, которые откусывают весь трафик на пару ip:port. но признаться не смотрел давно, поэтому могу сильно путать. я зацепился только за то, что коннтрек работает медленнее, чем nginx. что звучит несколько невероятно без dpdk.