Редактирование входа Kubernetes: HTTP 400 Bad request — простой HTTP-запрос был отправлен на HTTPS

Может ли быть какая-либо причина, по которой веб-приложение, которое отлично загружается, дает порт *HTTP 400 Bad request - The plain HTTP request was sent to HTTPS* после того, как вход веб-приложения был отредактирован вручную или отредактирован с помощью автоматизированного задания, которое обновляет вход, изменяя IP-адреса из белого списка?

Судя по всему, эта проблема исправляется, когда мы повторно развертываем веб-приложение после очистки развертывания веб-приложения...

Любые указатели на это были бы замечательны, поскольку это происходит в нашей среде PROD и не воспроизводится ни в каких более низких средах. Обратите внимание: - Настройка контроллера Nginx Ingress одинакова для более низких env и Prod env.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/force-ssl-redirect: "true"
    ingress.kubernetes.io/ingress.allow-http: "false"
    ingress.kubernetes.io/proxy-body-size: 20M
    ingress.kubernetes.io/secure-backends: "true"
    ingress.kubernetes.io/whitelist-source-range: xxx.yy.zz.pp/32, yyy.ss.dd.kkl/32
    ingress.kubernetes.io/whitelist-source-range-status: unlocked
creationTimestamp: 2018-11-29T15:34:05Z
generation: 5
 labels:
   app: xyz-abc-pqr
  name: xxxx-webapp-yyyy-zzzz
  namespace: nspsace-name
  resourceVersion: "158237270"
  selfLink: /apis/extensions/v1beta1/namespaces/nspsace-name/ingresses/xxxx-webapp-yyyy-zzzz
  uid: 348f892e-f3ec-11e8-aa6f-0a0340041348
  spec:
   rules:
    - host: ssssssss.wwwwweewwerwerw.co.uk
      http:
      paths:
       - backend:
          serviceName: xxxx-webapp-yyyy-zzzz
          servicePort: 443
        path: /
    - host: xxxx-webapp-yyyy-zzzz.bbbbv.lasdfkla.ajksdfh.ioohhsaf.pp
     http:
       paths:
        - backend:
          serviceName: xxxx-webapp-yyyy-zzzz
          servicePort: 443
       path: /
     tls:
       - hosts:
          - ssssssss.wwwwweewwerwerw.co.uk
          - xxxx-webapp-yyyy-zzzz.bbbbv.lasdfkla.ajksdfh.ioohhsaf.pp
         secretName: xxxx-webapp-yyyy-zzzz-server-tls
     status:
       loadBalancer:
        ingress:
         - {}

person Avi    schedule 29.11.2018    source источник
comment
Можете ли вы опубликовать свой Ingress YAML? А также опишите, что именно вы меняете вручную и как: kubectl edit?   -  person Clorichel    schedule 29.11.2018
comment
да, используя kubectl edit.. Опубликовал входной YAML выше. Мы просто меняем IP-адреса из белого списка, чтобы ограничить доступ веб-приложения к внешнему миру.   -  person Avi    schedule 29.11.2018
comment
Убедитесь, что ваши добавочные развертывания действительно включают входное обновление. Может что-то вроде helm upgrade --install (your-ingress)   -  person Brent Bradburn    schedule 30.11.2018


Ответы (1)


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

$ kubectl cp <nginx-ingress-controller-pod>:nginx.conf nginx.conf.before
$ kubectl edit ingress <your-ingress>
$ kubectl cp <nginx-ingress-controller-pod>:nginx.conf nginx.conf.after
$ diff nginx.conf.before nginx.conf.after

Вы можете видеть, что это может произойти с nginx из-за чего-то вроде этого: sent-to-https-port-error">Работа с nginx 400 Обычный HTTP-запрос был отправлен на HTTPS-порт с ошибкой.

person Rico    schedule 30.11.2018
comment
Моему веб-приложению нужен внутренний вход и внешний вход, обслуживающий внутренний трафик и внешний мир. Проблема заключалась не в указании или упоминании Ingress_Class в шаблоне внутреннего входа, который создавал дополнительный вход для обработки внешнего трафика, который имел неправильные сопоставления хостов, отличные от ожидаемых URL-адресов хостов, разрешенных извне. Все внутренние поды контроллера входящего трафика обновили бы файл nginx.conf после указания правильной аннотации INGRESS CLASS. - person Avi; 04.12.2018