c
свой DNS что имеется ввиду?
bind (named)
Size: a a a
2020 November 03
AK
не совсем понимаю зачем он мне
DS
привет всем
подскажите пожалуйста по схему, что хочу сделать
в данный момент есть gateway service, который через alb-ingress экспозится в мир
сейчас он (временно) стучится на другие сервисы через namespace.svc.cluster.local
Что хочу сделать
consul + nginx-ingress
Вопрос собственно по nginx-ingress и consul:
nginx-ingress по дефолту создает classic elb в AWS.
я не нашел как заменить его на internal ALB/NLB
host в rules, домен может быть какой-нибудь service.local?
Если я добавлю к этому всему consul, как сервисы будут в нем регистрироваться? через nginx-ingress?
Заранее прошу прощения если что-то не понял в основе)
подскажите пожалуйста по схему, что хочу сделать
в данный момент есть gateway service, который через alb-ingress экспозится в мир
сейчас он (временно) стучится на другие сервисы через namespace.svc.cluster.local
Что хочу сделать
consul + nginx-ingress
Вопрос собственно по nginx-ingress и consul:
nginx-ingress по дефолту создает classic elb в AWS.
я не нашел как заменить его на internal ALB/NLB
host в rules, домен может быть какой-нибудь service.local?
Если я добавлю к этому всему consul, как сервисы будут в нем регистрироваться? через nginx-ingress?
Заранее прошу прощения если что-то не понял в основе)
никак не будут. nginx-ingress не занимается регистрацией сервисов.
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
AK
никак не будут. nginx-ingress не занимается регистрацией сервисов.
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
тогда вопрос
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
DS
тогда вопрос
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
Нет.
Чтобы попадало на ingress-controller, надо отправлять запрос на ingress-controller.
Для запросов внутри куба, обычно используют сервисы. Но можно и через ingress-controller.
Отправляете запрос на ingress-controller, указывается в загаловках хост, который указан в kind: Ingress, ingress-controller перенаправит этот запрос по правилам описанным в kind: Ingress.
Создавать Ingress с хостом service.namespace.svc.cluster.local - можно, но тогда надо обращаться не по http://service.namespace.svc.cluster.local, а по -H "host: service.namespace.svc.cluster.local" http://сервис_который_матчит_ingress-controller или http://ip-адрес-сервиса-который-матчит-ingress-controller или http://ip-адрес-одного-из-подов-ingress-контроллера
Чтобы попадало на ingress-controller, надо отправлять запрос на ingress-controller.
Для запросов внутри куба, обычно используют сервисы. Но можно и через ingress-controller.
Отправляете запрос на ingress-controller, указывается в загаловках хост, который указан в kind: Ingress, ingress-controller перенаправит этот запрос по правилам описанным в kind: Ingress.
Создавать Ingress с хостом service.namespace.svc.cluster.local - можно, но тогда надо обращаться не по http://service.namespace.svc.cluster.local, а по -H "host: service.namespace.svc.cluster.local" http://сервис_который_матчит_ingress-controller или http://ip-адрес-сервиса-который-матчит-ingress-controller или http://ip-адрес-одного-из-подов-ingress-контроллера
DS
тогда вопрос
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
если у меня что-то обращается на service.namespace.svc.cluster.local - оно попадет на ingress?
если нет - как мне тогда балансить между подами?
> если нет - как мне тогда балансить между подами?
Оно и по сервисам балансится, что конкретно не устраивает?
Оно и по сервисам балансится, что конкретно не устраивает?
AK
Нет.
Чтобы попадало на ingress-controller, надо отправлять запрос на ingress-controller.
Для запросов внутри куба, обычно используют сервисы. Но можно и через ingress-controller.
Отправляете запрос на ingress-controller, указывается в загаловках хост, который указан в kind: Ingress, ingress-controller перенаправит этот запрос по правилам описанным в kind: Ingress.
Создавать Ingress с хостом service.namespace.svc.cluster.local - можно, но тогда надо обращаться не по http://service.namespace.svc.cluster.local, а по -H "host: service.namespace.svc.cluster.local" http://сервис_который_матчит_ingress-controller или http://ip-адрес-сервиса-который-матчит-ingress-controller или http://ip-адрес-одного-из-подов-ingress-контроллера
Чтобы попадало на ingress-controller, надо отправлять запрос на ingress-controller.
Для запросов внутри куба, обычно используют сервисы. Но можно и через ingress-controller.
Отправляете запрос на ingress-controller, указывается в загаловках хост, который указан в kind: Ingress, ingress-controller перенаправит этот запрос по правилам описанным в kind: Ingress.
Создавать Ingress с хостом service.namespace.svc.cluster.local - можно, но тогда надо обращаться не по http://service.namespace.svc.cluster.local, а по -H "host: service.namespace.svc.cluster.local" http://сервис_который_матчит_ingress-controller или http://ip-адрес-сервиса-который-матчит-ingress-controller или http://ip-адрес-одного-из-подов-ingress-контроллера
я в процессе переезда, с ECS. И одна из главных причин - слишком много alb)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
c
никак не будут. nginx-ingress не занимается регистрацией сервисов.
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
Возможно есть какой-то оператор, который синкает сервисы куба в consul. Но почему бы просто не использовать сервисы куба?
+
z
я в процессе переезда, с ECS. И одна из главных причин - слишком много alb)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
EKS мб ?
AK
EKS мб ?
нет, именно с ECS в EKS
z
нет, именно с ECS в EKS
Ааа, я просто поднял под с nginx для роутинга между сервисами, было обусловлено тем что все сервисы общались через хостнейм/API/service
DS
я в процессе переезда, с ECS. И одна из главных причин - слишком много alb)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
последний вариант однозначно нет)
по дефолту при обращении к сервису, отдается же просто ip пода, тут никакой балансировки нет по сути, а нужно)
> Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
верно, ingress-controller для этого не нужен.
> последний вариант однозначно нет)
ну ты же сам хотел этого, что спросил то и ответил.
> по дефолту при обращении к сервису, отдается же просто ip пода
нет, отдается ip сервиса, который на самом деле является либо iptables правилом nat, либо ipvs правилом
верно, ingress-controller для этого не нужен.
> последний вариант однозначно нет)
ну ты же сам хотел этого, что спросил то и ответил.
> по дефолту при обращении к сервису, отдается же просто ip пода
нет, отдается ip сервиса, который на самом деле является либо iptables правилом nat, либо ipvs правилом
AK
> Для запросов внутри куба, обычно используют сервисы - то есть по сути запросы на service.namespace.svc.cluster.local, верно?
верно, ingress-controller для этого не нужен.
> последний вариант однозначно нет)
ну ты же сам хотел этого, что спросил то и ответил.
> по дефолту при обращении к сервису, отдается же просто ip пода
нет, отдается ip сервиса, который на самом деле является либо iptables правилом nat, либо ipvs правилом
верно, ingress-controller для этого не нужен.
> последний вариант однозначно нет)
ну ты же сам хотел этого, что спросил то и ответил.
> по дефолту при обращении к сервису, отдается же просто ip пода
нет, отдается ip сервиса, который на самом деле является либо iptables правилом nat, либо ipvs правилом
я пока что в поиске решения просто...)
то есть вы хотите сказать, что если я оставлю тупо как есть, что бы общались через сервисы, проблем с балансировкой между подами не будет?)
то есть вы хотите сказать, что если я оставлю тупо как есть, что бы общались через сервисы, проблем с балансировкой между подами не будет?)
AK
меня это немного пугает)
z
я пока что в поиске решения просто...)
то есть вы хотите сказать, что если я оставлю тупо как есть, что бы общались через сервисы, проблем с балансировкой между подами не будет?)
то есть вы хотите сказать, что если я оставлю тупо как есть, что бы общались через сервисы, проблем с балансировкой между подами не будет?)
Просто проведи тестирование, даже в официальном гайде поднимают два Nginx объединяют их в сервис и делают 10 запросов которые возвращают разные имена подов
z
Просто проведи тестирование, даже в официальном гайде поднимают два Nginx объединяют их в сервис и делают 10 запросов которые возвращают разные имена подов
Ещё можешь задерскрайбить сервис и увидеть что внутри
DS
меня это немного пугает)
какие конкретно проблемы были обнаружены с сервисами куба?
AK
какие конкретно проблемы были обнаружены с сервисами куба?
я когда-то проводил тест на AWS CloudMap, который работает по DNS. Вернулся обратно на AWS ALB, собственно из-за проблем с балансировкой
Пугает собственно что балансировка переносится на DNS...
для чего тогда в принципе используют nginx-ingress?) Для работы с paths ?
Пугает собственно что балансировка переносится на DNS...
для чего тогда в принципе используют nginx-ingress?) Для работы с paths ?
DS
я когда-то проводил тест на AWS CloudMap, который работает по DNS. Вернулся обратно на AWS ALB, собственно из-за проблем с балансировкой
Пугает собственно что балансировка переносится на DNS...
для чего тогда в принципе используют nginx-ingress?) Для работы с paths ?
Пугает собственно что балансировка переносится на DNS...
для чего тогда в принципе используют nginx-ingress?) Для работы с paths ?
а какая связь с сервисами куба?
c
Просто проведи тестирование, даже в официальном гайде поднимают два Nginx объединяют их в сервис и делают 10 запросов которые возвращают разные имена подов
При условии что еще настроить sticky session на них то будут возвращать одинаковые