Блог

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

Мне это кажется излишним. Почему бы не разместить содержимое на томе, смонтировать его на ingress-nginx-controller и оттуда обслуживать статические ресурсы. Кажется, это лучше с точки зрения производительности: нет дополнительного прокси и дополнительного контейнера (с nginx), который потребляет вычислительные ресурсы.

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

ingress-nginx — это всего лишь одна из реализаций контроллера ingress, которая также хороша для обслуживания статического контента. HAProxy, Traefik или AWS lb находятся на другом конце шкалы.

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

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

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