V
а как лучше ?
Size: a a a
2020 June 18
AK
а как лучше ?
нет такой шкалы лучшести, на которую можно положить alb ingress controller и nginx ingress controller и померить что лучше
b
попробовать прописать полный путь до сервиса
что значит полный путь?
AK
Зайдите в любой под, сделайте cat /etc/resolv.conf и все поймете
VR
bugs_bunny
что значит полный путь?
DS
нет такой шкалы лучшести, на которую можно положить alb ingress controller и nginx ingress controller и померить что лучше
производительность, гибкость настроек, метрики (их разнообразие), другие фичи. Вполне себе шкалы
AK
производительность, гибкость настроек, метрики (их разнообразие), другие фичи. Вполне себе шкалы
вопрос был не "что производительней/гибче в настройках/..." - вопрос был что лучше
DS
вопрос был не "что производительней/гибче в настройках/..." - вопрос был что лучше
кто по большинству параметров лучше, тот и лучший 🤷
AK
кто по большинству параметров лучше, тот и лучший 🤷
неправильно.
L
До тех пор, пока не перестанут создаваться по отдельному ALB на каждый манифест ингресса - оно будет не пригодным к использованию
DS
Привет. Разбираюсь тут с EKS, я правильно понимаю что можно либо использовать ELB (alb ingress) те по сути амазоновский и в самом k8s кластере не ставить nginx ingress, а можно например поставить nginx ingress и настроить network load балансер который тупо будет 443 80 проксировать на ingress nginx ?
я alb не юзал. Но часто наблюдал, как в чате писали, что отказались от alb ingress controller, в пользу других ingress контроллеров, по каким либо причинам. Поэтому можно сделать вывод, что alb ingress точно не лучший ))
V
ок приблизительно понял. Спасибо
DS
До тех пор, пока не перестанут создаваться по отдельному ALB на каждый манифест ингресса - оно будет не пригодным к использованию
еще интересно как там с метриками. Насколько я помню, балансеры в aws метрики не отдают, а народ их парсит по логам. А так как alb ingress controller это обертка над собственно alb, то фиг знает. Но может щас уже лучше с этим
DS
До тех пор, пока не перестанут создаваться по отдельному ALB на каждый манифест ингресса - оно будет не пригодным к использованию
я думал по alb на namespace. А там на каждый манифест ingress по балансеру? Это же сколько денег нужно 0_о
DS
а как лучше ?
узнав больше, я могу точно сказать alb ingress controller хуже nginx ingress controller =)
b
Зайдите в любой под, сделайте cat /etc/resolv.conf и все поймете
вижу только dns👀
DS
bugs_bunny
вижу только dns👀
а вывод ты не даш конечно, следуя традициям. Минимум инфы и контекста =). Из предоставленной тобой информации тебе можно так помочь: посылать запросы на сервис можно по доменному имени. Способ образавания имен ты можешь уточнить в доках: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
b
а вывод ты не даш конечно, следуя традициям. Минимум инфы и контекста =). Из предоставленной тобой информации тебе можно так помочь: посылать запросы на сервис можно по доменному имени. Способ образавания имен ты можешь уточнить в доках: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
nameserver 169.10.25.10вот вывод)
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
AK
До тех пор, пока не перестанут создаваться по отдельному ALB на каждый манифест ингресса - оно будет не пригодным к использованию
используют же
DS
bugs_bunny
nameserver 169.10.25.10вот вывод)
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
Теперь инфу о том, в каком namespace находится под с которого ты посылаешь запросы (это у него resolv.conf ты вывел?). И в каком namespacce находится сервис, куда ты хочешь посылать запросы