В
kind: Service
apiVersion: v1
metadata:
name: {{ .Release.Name }}-service-external
spec:
type: ExternalName
externalName: {{ .Values.services.service.svc.name }}.svc.cluster.local
ports:
- port: {{ .Values.services.service.svc.port }}
Size: a a a
2020 March 03
В
типа такъ
DS
kind: Service
apiVersion: v1
metadata:
name: {{ .Release.Name }}-service-external
spec:
type: ExternalName
externalName: {{ .Values.services.service.svc.name }}.svc.cluster.local
ports:
- port: {{ .Values.services.service.svc.port }}
а в итоге то какой
у тебя в
{{ .Values.services.service.svc.name }}.svc.cluster.local ?у тебя в
{{ .Values.services.service.svc.name }} - название_сервиса.название_namespace ?В
все ок ок там, да, делал describe сервиса
В
копировал, вставлял в курл - ответ приходил
DS
копировал, вставлял в курл - ответ приходил
курлом из этого же namespace то работает? по
{{ .Release.Name }}-service-external ?В
курлом из этого же namespace то работает? по
{{ .Release.Name }}-service-external ?нет
В
работает myservice.namespace
.svc.cluster.localВ
курлом из этого же namespace то работает? по
{{ .Release.Name }}-service-external ?или из того же в котором сервис?
DS
Да, вот есть сервис
Он вообще отвечает в этом же неймспейсе?
{{ .Release.Name }}-service-external, он в каком-то неймспесе.Он вообще отвечает в этом же неймспейсе?
В
Да, вот есть сервис
Он вообще отвечает в этом же неймспейсе?
{{ .Release.Name }}-service-external, он в каком-то неймспесе.Он вообще отвечает в этом же неймспейсе?
да, отвечает
DS
да, отвечает
externalName вроде cname делает, не уверен что у тебя это будет работать правильно в ingress.
Ну то есть для случаев когда externalName действительно external, и редко меняется, это возможно будет работать норм, а вот если он у тебя в другом неймспейсе, ты явно захочешь чтобы nginx оператвно поды добавлял/удалял для него.
Может лучше сделать service + endpoints к нему, которые уже смотрят на нужный namespace?
Ну то есть для случаев когда externalName действительно external, и редко меняется, это возможно будет работать норм, а вот если он у тебя в другом неймспейсе, ты явно захочешь чтобы nginx оператвно поды добавлял/удалял для него.
Может лучше сделать service + endpoints к нему, которые уже смотрят на нужный namespace?
В
сейчас попробую с endpoints, спасибо
PS
externalName вроде cname делает, не уверен что у тебя это будет работать правильно в ingress.
Ну то есть для случаев когда externalName действительно external, и редко меняется, это возможно будет работать норм, а вот если он у тебя в другом неймспейсе, ты явно захочешь чтобы nginx оператвно поды добавлял/удалял для него.
Может лучше сделать service + endpoints к нему, которые уже смотрят на нужный namespace?
Ну то есть для случаев когда externalName действительно external, и редко меняется, это возможно будет работать норм, а вот если он у тебя в другом неймспейсе, ты явно захочешь чтобы nginx оператвно поды добавлял/удалял для него.
Может лучше сделать service + endpoints к нему, которые уже смотрят на нужный namespace?
работает без проблем. правда надо хост хидер переопределять. потому что на externalname тоже обычно есть L7 маршрутизация
В
Peter Shilo
работает без проблем. правда надо хост хидер переопределять. потому что на externalname тоже обычно есть L7 маршрутизация
хост не читает там вообще прилага
PS
хост не читает там вообще прилага
ну мало ли. тогда пофиг вообще, просто имя сервиса указываешь.
DS
Peter Shilo
работает без проблем. правда надо хост хидер переопределять. потому что на externalname тоже обычно есть L7 маршрутизация
сомневаюсь что это будет работать нормально для случаев когда externalName это сервис другого namespace. Оно возможно один раз зарезолвит, а вот потом апстримы будет обновлять скорее всего криво
DS
мне кажется externalName дле для таких кейсов
DS
Он кстати требует dns'ы указать для этого: https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/externalname-services#prerequisites
Если указать там coredns, возможно будет работать, но я бы на такую конструкцию не надеялся
Если указать там coredns, возможно будет работать, но я бы на такую конструкцию не надеялся
PS
сомневаюсь что это будет работать нормально для случаев когда externalName это сервис другого namespace. Оно возможно один раз зарезолвит, а вот потом апстримы будет обновлять скорее всего криво
ну смотря о каких кейсах идет речь. у ингресс контроллера есть возможность выбрать где именно будет происходить балансировка, либо на сервисе, либо контроллер будет выковыривать апстримы через апи кубернетеса. это повлияет на режимы работы когда нужна балансировка с сохранением сессии, но если просто раунд робин то почему бы и нет.