Кубернетес Под общением через сервисы - PullRequest
0 голосов
/ 29 января 2020

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

Например, приложению Django требуется имя хоста базы данных в ее переменных config / environment (вместе с именем базы данных и некоторыми другими вещами) для подключения к базе данных.

Вы должны иметь возможность указать службу следующим образом (при условии, что база данных имеет служба db-service в пространстве имен по умолчанию):

Внутри Django app demployment.yaml file:

    env:
    - name: SQL_HOST
      value: "db-service.default"

имя хоста для контейнера базы данных (если оно похоже на имя приложения), например:

Внутри Django файл приложения demployment.yaml:

env:
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

- name: SQL_HOST
  value: $(POD_NAME)-db

Внутри Postgres файла demployment.yaml:

spec:
  replicas: 1
  selector:
    matchLabels:
      app: sitename-db-container
  template:
    metadata:
      labels:
        app: sitename-db-container
    spec:
      hostname: sitename-db

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

1 Ответ

1 голос
/ 29 января 2020

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

Что вы подразумеваете под «множественное развертывание внутри службы» ? В определении Service вы должны выбрать только один набор Pods, скажем, управляемый одним конкретным c Deployment. Как предложил @Matt, вы всегда должны создавать сервис с уникальным именем для каждого pod / db, к которому вы хотите получить доступ . Если у вас есть Pods, выделенная для выполнения определенных c задач, вы развертываете их отдельно (как отдельные Deployments). Они могут даже состоять из одного Pod, если вам не нужна избыточность. И в основном вы всегда будете создавать отдельный Service (очевидно, с уникальным именем, поскольку вы не можете создать больше Services, используя то же имя) для предоставления различных микросервисов (представленных уникальным Deployment). Обратите внимание, что если вы не создаете Deployment, а просто Pod, он не будет управляться каким-либо контроллером, поэтому, если он выйдет из строя, ничто не позаботится о его воссоздании. Поэтому, безусловно, вы всегда должны использовать Deployment даже для запуска одного Pod, представляющего ваш микросервис.

Читали ли вы this topi c в официальной документации kubernetes? Если вы не укажете тип Service, по умолчанию он создаст так называемую службу ClusterIP, которая, по сути, является тем, что вам нужно для внутреннего представления компонентов app (сделайте их доступными для других компонентов приложения в вашем кластере).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...