ingress-nginx - создать один вход на хост? Или объединить множество хостов в один вход и перезагрузить?

Я создаю сервис, в котором пользователи могут создавать веб-приложения - эти приложения будут размещаться под виртуальным DNS-именем * .laska.io.

Например, если Том и Джерри создали приложение, они разместили бы его в:

tom.laska.io
jerry.laska.io

Теперь предположим, что у меня 1000 пользователей. Следует ли создать один большой вход, который выглядит так?

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: tom.laska.io
    http:
      paths:
      - backend:
          serviceName: nginx-service
          servicePort: 80
  - host: jerry.laska.io
    http:
      paths:
      - backend:
          serviceName: nginx-service
          servicePort: 80          
  ...and so forth

Меня беспокоит время простоя - например, если у меня есть приложение с веб-сокетами. Также файл станет огромным с 1000 пользователей. Пройдет ли перезарядка входящего трафика достаточно быстро? Кроме того, как мне его перезагрузить?

Второй вариант, на мой взгляд, - просто создать по одному входу для каждого веб-приложения. Меня беспокоит то, может ли ingress-nginx обрабатывать много входов? Или это антипаттерн?

Какой лучше?


kubernetes kubernetes-ingress google-kubernetes-engine nginx-ingress
person Nick    schedule 18.09.2018    source источник

Ответы (2)


arrow_upward
15
arrow_downward

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

Следует четко понимать, что входящий ресурс - это просто определение правила маршрутизации. (Он не добавляет дополнительный входной контроллер или какой-либо другой дополнительный компонент среды выполнения.) Таким образом, для приложения имеет большой смысл определять собственное правило маршрутизации.

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

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

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

person Ryan Dawson    schedule 18.09.2018

arrow_upward
1
arrow_downward

ingress ресурс - это просто правило. Лучше разделить ingress ресурсы по разным файлам и просто повторно применить ресурсы, которые нужно изменить. Я ни разу не заметил простоев при применении ресурса.

person cyrilbkr    schedule 18.09.2018