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

Question

Ingress

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

Когда вы используете 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 Service (AKS) .Я предлагаю этот способ.Попробуйте.

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

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

или

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

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