Size: a a a

Kubernetes — русскоговорящее сообщество

2020 February 25

k

kvaps in Kubernetes — русскоговорящее сообщество
corsars
опыт есть  печальный со штаными ingress - только нормальные TCP балансировщики могут разрулить backend и они или коммерческие стоят денег или как metalB который Google опубликовала в прошлом году. фишка в том что сервисы штатные не могут TCP балансировку как и LB роль
А, понял. Но я бы не назвал metallb полноценным балансировщиком, он скорее что-то типа keepalived.
для более умной балансировки, хелсчеков и всего такого по прежнему требуется что-то типа nginx или hapoxy
источник

c

corsars in Kubernetes — русскоговорящее сообщество
Alexander
Ты путаешь service-ы и ingress-ы
Нет, не путаю. Реализация сервисов увы...
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Кстати, haproxy-ingress-controller никто не пробовал случайно? Как впечатления?
источник

GG

George Gaál in Kubernetes — русскоговорящее сообщество
corsars
Нет, не путаю. Реализация сервисов увы...
Да, с реализацией services внутри кластера действительно есть вопросы
источник

A

Alexander in Kubernetes — русскоговорящее сообщество
corsars
Нет, не путаю. Реализация сервисов увы...
Service-ы вообще про http ничего не знают. Там балансировка на l4
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
George Gaál
Да, с реализацией services внутри кластера действительно есть вопросы
внутри кластера как раз вопросов меньше чем снаружи, так как всё стандартизированно
источник

Y

Yuri in Kubernetes — русскоговорящее сообщество
kvaps
Кстати, haproxy-ingress-controller никто не пробовал случайно? Как впечатления?
нет, но в планах потрогать
источник

GG

George Gaál in Kubernetes — русскоговорящее сообщество
kvaps
внутри кластера как раз вопросов меньше чем снаружи, так как всё стандартизированно
Как будто сервисы никогда не добавляют проблем !?
источник

c

corsars in Kubernetes — русскоговорящее сообщество
kvaps
А, понял. Но я бы не назвал metallb полноценным балансировщиком, он скорее что-то типа keepalived.
для более умной балансировки, хелсчеков и всего такого по прежнему требуется что-то типа nginx или hapoxy
Вот вот, но альтернативы то нет... Когда математика идет от приложений к БД и к сервису приложений - то тут только metalB и помог - стабильно зараза ведь работает. В очередь все запросы выстраивает - а со штатныеми service - фиг вам - контроллер с ума сходит. я его вынес отдельно на отдельный хост - но фигня та же (K8 котиорый)
источник

DO

Dmitriy Onishko in Kubernetes — русскоговорящее сообщество
kvaps
внутри кластера metallb не используется, снаружи кластера у тебя должен быть доступ к LoadBalancer IP, попробуй arping и смотри логи спикера запущенного на тойже ноде где и workload он должен отвечать arpreply
у меня какраз используется внутри кластера как это заложено с коробки в kubespray на нужных нодах где мне нужно выкинуть порт в мир я дедлаю
$IPT -t nat -A z_PREROUTING -d $INET_IP -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.5.0.50:80

но чтото пошло не так
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Yuri
нет, но в планах потрогать
мне сейчас предстоит организовать доступ изнутри кластера к внешним бд, нужно что-то что умеет в healthcheck, думаю его на эту роль попробовать
источник

c

corsars in Kubernetes — русскоговорящее сообщество
Dmitriy Onishko
у меня какраз используется внутри кластера как это заложено с коробки в kubespray на нужных нодах где мне нужно выкинуть порт в мир я дедлаю
$IPT -t nat -A z_PREROUTING -d $INET_IP -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.5.0.50:80

но чтото пошло не так
Вот не нужно тут nat-a по определению. Это не кубер должен делать - OOM cловишь
источник

DO

Dmitriy Onishko in Kubernetes — русскоговорящее сообщество
Dmitriy Onishko
у меня какраз используется внутри кластера как это заложено с коробки в kubespray на нужных нодах где мне нужно выкинуть порт в мир я дедлаю
$IPT -t nat -A z_PREROUTING -d $INET_IP -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.5.0.50:80

но чтото пошло не так
10.5.0.50 это ипшник metallb
источник

A

Alexander in Kubernetes — русскоговорящее сообщество
George Gaál
Как будто сервисы никогда не добавляют проблем !?
Сервисы добавляют проблем из-за своего дебильного места в рекомендуемой архитектуре куба, когда у тебя балансировка происходит на клиентах.
источник

L

Lucky SB in Kubernetes — русскоговорящее сообщество
corsars
Вот вот, но альтернативы то нет... Когда математика идет от приложений к БД и к сервису приложений - то тут только metalB и помог - стабильно зараза ведь работает. В очередь все запросы выстраивает - а со штатныеми service - фиг вам - контроллер с ума сходит. я его вынес отдельно на отдельный хост - но фигня та же (K8 котиорый)
ХАХАХАХА. рассмешил. ты как всегда... металлб у тебя запросы в очередь выстраивает.....
источник

Y

Yuri in Kubernetes — русскоговорящее сообщество
kvaps
мне сейчас предстоит организовать доступ изнутри кластера к внешним бд, нужно что-то что умеет в healthcheck, думаю его на эту роль попробовать
Возможно больше подойдёт proxysql, если базы. Сейчас юзаю хапрокси как внешний балансировщик кубера, никаких проблем.
источник

c

corsars in Kubernetes — русскоговорящее сообщество
Lucky SB
ХАХАХАХА. рассмешил. ты как всегда... металлб у тебя запросы в очередь выстраивает.....
ХА ХА - это вам не штатные недоделанные ингресы и сервисы в кубере. И какой идиот придумаел сетевые сервисы запихнуть в кластер ?
источник

c

corsars in Kubernetes — русскоговорящее сообщество
Yuri
Возможно больше подойдёт proxysql, если базы. Сейчас юзаю хапрокси как внешний балансировщик кубера, никаких проблем.
Но кстати у мну положительный опыт работы лет 15 как с HA Proxy для MYSQL + PGSQL
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
George Gaál
Как будто сервисы никогда не добавляют проблем !?
ну с IPVS всё предельно просто:
TCP  10.107.19.56:9000 rr
 -> 10.112.7.4:9000    Masq    1      0      0        
 -> 10.112.7.7:9000    Masq    1      0      0        
 -> 10.112.7.8:9000    Masq    1      0      0        
 -> 10.112.7.9:9000    Masq    1      0     0

10.107.19.56:9000 - сервис, остальное эндпоинты.
Адрес 10.107.19.56 добавлен локально на каждой ноде, стучишься на него, IPVS роутит на эндпоинты, куда уж проще?
источник

c

corsars in Kubernetes — русскоговорящее сообщество
Yuri
Возможно больше подойдёт proxysql, если базы. Сейчас юзаю хапрокси как внешний балансировщик кубера, никаких проблем.
Он не стабильнее и сложнее да и проще и надежнее сделать с ролями HA Proxy - и управлять проще потоком трафика
источник