Kubernetes - Развертывание нескольких изображений в одном модуле

Question

У меня возникла проблема, потому что приложение изначально было настроено на выполнение в docker-compose. Мне удалось перенести и переписать файлы развертывания .yaml в Kubernetes, однако проблема заключается в связи модулей.

Интерфейс связывается с бэкэндом для доступа к сервисам, и я предполагаю, что, как и должно быть в той же сети, веб-интерфейс вызывает сервисы с локального хоста. У меня нет доступа к коду, так как это проприетарное приложение, которое было разработано компанией и не поддерживает Kubernetes, поэтому изменение кода не подлежит обсуждению.

Я полагаю, что главная причина в том, что интерфейс и сервер работают на разных модулях с разными IP-адресами.

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

К сожалению, я не знаю, как создать файл yaml для создания обоих контейнеров в одном модуле.

Возможно ли, чтобы на одном и том же модуле работали как внешние, так и внутренние контейнеры, или был бы другой способ установить связь между контейнерами (возможно, прокси)?

Answer 1

Поэтому я пытаюсь развернуть как внешний, так и внутренний интерфейс в одном модуле, чтобы они использовали один и тот же IP-адрес кластера.

Хотя у вас уже есть принятый ответ, который рассматривает пример запуска большего количества контейнеров в одном модуле, я хотел бы указать на несколько деталей:

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

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

• Более философский подход к Кубернетесу заключается в следующем:

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

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

Answer 2

Да, вы просто добавляете записи в раздел containers в файле yaml, например:

apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
    restartPolicy: Never
containers:
    - name: nginx-container
      image: nginx
    - name: debian-container
      image: debian