Начнем с самого начала. Слишком много, чтобы сказать об этой топике c, чтобы поместить все в комментарии, поэтому давайте перейдем к ответу. Если что-то ниже не совсем понятно, не стесняйтесь спрашивать.
Прежде всего вам нужно начать с вашей архитектуры приложения и попытаться определить, как она должна работать, какая часть должна быть в состоянии общаться с другим.
Микросервисы Подход к разработке приложений - это полная тема c, и она заслуживает скорее отдельной статьи, чем попытки объяснить это в одном ответ. Но, в двух словах, все, что нужно сделать, это разделить приложение на отдельные части, каждая из которых обладает определенной функциональностью и может разрабатываться, развертываться и обновляться отдельно. Эти элементы могут быть тесно связаны, они могут даже полностью зависеть друг от друга, но в то же время они являются отдельными сущностями.
Kubernetes по самой своей природе побуждает вас следовать вышеизложенному подходу. Если вы прочитаете больше о Pods , вы увидите, что они идеально подходят для этой цели, поскольку являются своего рода оболочкой для одиночного microservice . Это в некоторой степени упрощение, но я считаю, что оно отражает суть вопроса. В реальной производственной среде вы можете иметь набор Pods, управляемый более высокой абстракцией, такой как Deployment , но учтите, что даже если у вас есть 3 или более реплик одного Pod, он все равно представляет один и тот же единственный микросервис , масштабируется только по горизонтали, например, для обработки большей нагрузки или большего количества запросов.
Отдельные наборы Pods, представляющие различные микросервисы , могут связываться друг с другом и быть в контакте с внешним миром благодаря Службам .
Как вы можете прочитать в kubernetes docs , Ingress это:
Объект API, который управляет внешним доступом к службам в кластере, обычно HTTP. Ingress может обеспечивать балансировку нагрузки, завершение SSL и виртуальный хостинг на основе имен.
Ingress предоставляет маршруты HTTP и HTTPS извне кластера для служб внутри кластера. Маршрутизация Traffi c контролируется правилами, определенными в ресурсе Ingress.
internet
|
[ Ingress ]
--|-----|--
[ Services ]
Вы должны спросить себя, действительно ли вы хотите выставить внешнему миру как свой интерфейс, так и внутренний интерфейс Pods. Обычно вы не хотите этого делать. Backend по определению должен действовать как ... ну ... как backend вашего приложения :) Он не должен быть доступен напрямую внешним пользователям, а только через frontend часть приложения, поэтому она не должна быть открыта через Ingress. Только после того, как часть внешнего интерфейса вашего приложения получит запрос от внешнего пользователя, он отправляет собственный запрос к бэкэнду , извлекает некоторые данные, обработанные внутренним приложением, и затем передает их конечный пользователь. Пользователь не делает прямых запросов к вашему бэкэнд-приложению .
Вы можете выставлять через Ingress различные части вашего приложения, используя разные пути (как в примере, приведенном в другом ответе), которые могут поддерживаться различными микросервисами , работающими в разных наборах Pods, но все же они должны быть частями внешнего интерфейса вашего приложения, НЕ бэкэндом .
Backend Pods - это то, что вы обычно выставляете только в своем кластере kubernetes , чтобы сделать его доступным для других компонентов вашего приложения. Для этой цели простой Сервис типа ClusterIP (который, кстати, является типом по умолчанию, автоматически выбирается, когда поле type: не указано) - это путь к go.
Я бы посоветовал вам прочитать больше о различных Service типах и для чего они используются.
Возможно, вы также захотите взглянуть на следующие статьи. Я верю, что они сделают всю концепцию еще яснее:
Соединение приложений со службами
Подключение внешнего интерфейса к внутреннему с помощью службы
Что касается объединения различных kubernetes объекты определений в один yaml файл, как в в этом примере, где вы можете видеть Service и Deployment, определенные в одном файле yaml и разделенные ---, просто конвенция, и я бы не стал уделять ей слишком много внимания. Если это делает вашу работу более удобной, вы можете использовать ее.
Что касается вашего дополнительного вопроса в комментарии:
Мне интересно, если бы два балансировщика нагрузки также работали как ну или если Ingress лучше подходит для этого сценария?
Я надеюсь, что после прочтения полного ответа, это уже намного яснее. Обратите внимание, что обычно Ingress также использует loadbalancer под капотом. Если вы хотите использовать только внешнее приложение для внешнего интерфейса без использования различных путей, которые поддерживаются отдельными микросервисами , вам может даже не понадобиться Ingress. LoadBalancer Service будет вполне достаточно для того, что вы хотите выполнить sh. Помните, что вы также используете его, чтобы представить свое приложение внешнему миру. Если вы выставляете что-то только в своем кластере, что не должно быть доступно извне, используйте вместо него простой ClusterIP Service.
LoadBalancer: предоставляет сервис извне, используя балансировщик нагрузки облачного провайдера. Службы NodePort и ClusterIP, для которых автоматически создаются маршруты для балансировки внешней нагрузки.
Надеюсь, это ответило на ваш вопрос.