Правило входа не перенаправляет на развертывание

Question

вход

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: assortment-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - myapp.centralus.cloudapp.azure.com
    secretName: aks-ingress-tls
  rules:
  - host: myapp.centralus.cloudapp.azure.com
    http:
      paths:
      - path: /my-service
        backend:
          serviceName: my-backend
          servicePort: 80

развертывание и обслуживание

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myservice
    spec:
      containers:
      - name: myservice
        image: myreg.azurecr.io/my-latest
        imagePullPolicy: Always
        ports:
           - name: http
             containerPort: 8080
      imagePullSecrets:
      - name: my-auth

apiVersion: v1
kind: Service
metadata:
 name: my-backend
spec:
 type: ClusterIP
 selector:
   app: myservice
 ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080

тем не мение

curl https://myapp.centralus.cloudapp.azure.com/my-service

дает

бэкэнд по умолчанию - 404

Обратите внимание, что myapp.centralus.cloudapp.azure.com уже разрешает общедоступный IP-адрес контроллера входа.

Когда я создаю сервис с типом LoadBalancer с тем же конфигом, он работает с публичным API.

Answer 1

Прежде всего, проверьте, что ваши модули находятся в рабочем состоянии.

или же

может быть причиной перенаправления слишком большого количества портов с 80 на 8080.войдите на службу к целевому порту.

Ваш конфиг абсолютно прав, это простая проблема, которая может быть связана с тем, что модуль не запущен или подождет некоторое время с чистым кэшем браузера

Answer 2

Проблема заключалась в том, что при доступе к внутреннему приложению через контроллер ngix были добавлены следующие заголовки.

X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443

Хотя доступ к нему через общедоступный IP-адрес LoadBalancer не был проблемой, проблема может быть воспроизведена, когда мы добавим заголовок

curl -v 104.43.164.105 -H "X-Forwarded-Proto: https"

Дает 302 найдено

Эти дополнительные заголовки не понравились следующей конфигурации весенней загрузки в application.yaml

server:
  useForwardHeaders: true

Это было исправлено

server:
  useForwardHeaders: false

или же

удаление вышеуказанной конфигурации в целом.

Answer 3

Когда вы используете TLS с Ingress, у вас также есть два способа использовать сертификаты.

Одним из них является то, что использовать свой собственный сертификат. Вы можете выполнить действия, описанные в разделе Создание входного контроллера HTTPS, и использовать собственные сертификаты TLS в службе Azure Kubernetes (AKS). Но для этого вы можете просто получить доступ к URL-адресу следующим образом:

curl -v -k --resolve demo.azure.com:443:yourIngressExternalIP https://demo.azure.com

Когда вы используете DNS-имя, заданное в Azure с общедоступным IP-адресом, вы можете создать сертификат в следующем случае:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out aks-ingress-tls.crt \
    -keyout aks-ingress-tls.key \
    -subj "/CN=myapp.centralus.cloudapp.azure.com/O=aks-ingress-tls"

Тогда вы можете подать в суд на команду curl https://myapp.centralus.cloudapp.azure.com, но это покажет так:

Когда вы используете браузер для доступа к URL, он будет отображаться так:

Чтобы использовать другой способ, выполните действия, описанные в разделе Создание входного контроллера со статическим общедоступным IP-адресом в службе Azure Kubernetes (AKS). Я предлагаю этот способ. Попробуй.