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

Question

Я создаю службу, где пользователи могут создавать веб-приложения - эти приложения будут размещаться под виртуальным 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 справиться со многими входами?Или это анти-паттерн?

Какой из них лучше?

Answer 1

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

Answer 2

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

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

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

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

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