утра писал про http и https в разных ingress.
Сделал два ingress. Но при попытке сделать curl
curl -L -H "Host: www.bbbb.ru" -i http://111.111.111.161/services/m
я попадаю не в тот ingress который с http (bbbb-http-esr1), а в тот который с https (bbbb-https-esr1)
это такая логика ingress или можно поставить какие то приоритеты?
$ kubectl -n bbbbb-ru-prod get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
bbbb-http-esr1 nginx-adx1 www.bbbbb.ru 111.111.111.161 80 3h55m
bbbb-https-esr1 nginx-adx1 www.bbbbb.ru 111.111.111.161 80, 443 6m27s
---
# Source: bbbbb/templates/esr1-http-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: bbbbb-http-esr1
labels:
helm.sh/chart: bbbbb-1
app.kubernetes.io/name: bbbbb
app.kubernetes.io/instance: bbbbb-ru
app.kubernetes.io/version: "c1c501d"
app.kubernetes.io/managed-by: Helm
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
spec:
ingressClassName: nginx-adx1
rules:
- host: www.bbbbb.ru
http:
paths:
- backend:
service:
name: bbbbb-web-to-http
port:
number: 80
path: /services/m
pathType: Prefix
---
# Source: bbbbb/templates/esr1-https-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: bbbbb-https-esr1
labels:
helm.sh/chart: bbbbb-1
app.kubernetes.io/name: bbbbb
app.kubernetes.io/instance: bbbbb-ru
app.kubernetes.io/version: "c1c501d"
app.kubernetes.io/managed-by: Helm
spec:
ingressClassName: nginx-adx1
tls:
- hosts:
- www.bbbbb.ru
rules:
- host: www.bbbbb.ru
http:
paths:
- backend:
service:
name: bbbbb-web-to-https
port:
number: 80
path: /
pathType: Prefix
давай еще раз
1) убери nginx.ingress.kubernetes.io/use-regex - он тут не используется, но при этом превращает все locations в ~, то есть в locations по регулярке, а в nginx у них другая логика работы, плюс сам nginx ingress controller их размещает в специальном порядке (сортирует по убыванию в зависимости от размера строки path) 2) У тебя опция -L у curl, из чего можно предположить, что все таки nginx-ingress controller дает редирект на https - подрверди это или поровергни. Если так, то попробуй его принудительно его отключить аннотацией для своего ингреса для http Пока на меня @gecube не начал орать что дефолты не такие
1) regex не могу убрать. у меня есть вот такой локейшн /(m/v(\d+)|tb/v(\d+))/(wg\.jsp|widget/android/|widget/ios/) надо чтобы он тоже был по http
в твоих ingress нет такого location. Ты же его выше кинул
как можно в тележке орать
у меня из там ещё штук 7
давай сначала от простого к сложному, ты дал два ingres'а с конкретными path, вот мы этот случай и рассматриваем если для этого кейса будет рабочее решение, то потом уже конкретно для твоих семи путей - будем отдельно думать. Ну и естественно ты нам потом даш полные ingres'ы
я вообще удивлен, что валидейшн вебхук такое пропустил
2) -L там потому что в поде nginx у которого в location есть proxy_pass ну и чтобы мне получить то что я хочу, а не 308 я поставил -L
-L переход по редиректу (3xx код ответа), proxy_pass вообще не про редиректы - -L для него не нужен
у тебя еще и nginx под за nginx ingress?
яж говорю тут сатанизм. монолит ломаем которому 12 лет.
Дай вывод curi -I http://111.111.111.161/services/m Для случая ингресов, которые ты описал. Без nginx.ingress.kubernetes.io/use-regex: "true" и семи дополнительных paths c регулярками
Обсуждают сегодня