Масштаб нескольких развертываний k8s

Question

Я исследовал k8s, но не смог найти ответ на мою нетривиальную настройку.

У меня есть 2 приложения (2 контейнера), которые работают вместе, но не связаны между собой.
app1 получает и фильтрует данные, а затем отправляет на app2.

1. Я решил иметь deployment на приложение;
   1.1. (И не оба контейнера находятся в одном и том же POD), поскольку они не должны ничего совместно использовать - обмен данными осуществляется в стандартной сети.
   1.2. Каждый из них может масштабироваться независимо

-> Q1 Является ли этот подход правильным?

Итак, у меня есть 2 развертывания, соответствующих этим двум приложениям. Определено в deployment1.yaml и deployment2.yaml. Каждый из них может масштабироваться независимо с помощью kubectl scale.

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

Масштабировать deployment1 и deployment2

-> Q2 Есть ли способ выполнить масштабирование нескольких развертываний с k8s?

Сделайте что-нибудь для только что созданного экземпляра deployment1, чтобы он знал о существовании нового экземпляра deployment2 (IP-адрес и т. Д.). то есть я хотел бы отправить ему запрос с deployment2 ip.

-> Q3 Есть ли способ использовать какой-нибудь хук для after-successful-scale для запуска некоторого кода? например скрипт bash? Если есть - кто это управляет? мастер-узел? Какой-то контейнер инициализации?

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

-> Q4 Есть ли способ сделать это динамически? Первый экземпляр deployment1 может иметь конфигурацию, отличную от второго. Я понимаю, что мог бы использовать StatefulSets вместо Deployments , чтобы я мог распознать уникальный экземпляр.
Я думал об использовании некоторого общего тома / ConfigMap, чтобы все экземпляры считывали свою собственную уникальную конфигурацию сих номер экземпляра. Но я также подумал, что есть более стандартный способ сделать это, поэтому я спрашиваю.

---

Я подумал, как выполнить эти требования при простой настройке веб-приложений, и подумал:

1. Оба deployments автоматически масштабируются при необходимости в соответствии с каким-либо триггером.
2. Оба deployments экспортируют LoadBalancer, поэтому app1 всегда общается с app2 LoadBalancer - тогда deployment1 действительно не зависит от deployment2;и scale, и LoadBalancer обрабатывают нагрузку.

-> Q5 Правильна ли эта мысль для тривиального случая?

Answer 1

Для q5: просто создайте Сервис, дайте приложениям общаться внутри кластера kubernetes, и Сервис будет обрабатывать балансировку нагрузки (по запросу). Вам не нужна служба типа LoadBalancer, и приложения должны использовать внешний IP-адрес.

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

Answer 2

Для 1 и 2: вы можете использовать два развертывания, A и B, и два сервиса, svcA и svcB, чтобы открыть модули. Таким образом, A может просто ссылаться на B, используя имя 'svcB'.

Вам действительно нужно знать, создан ли новый экземпляр pod? Потому что, если запущено несколько экземпляров модуля B, служба svcB будет выступать в качестве балансировщика нагрузки и распределять нагрузку между экземплярами B.

Для хранения конфигураций используйте ConfigMap исмонтировать в configmap в вашем развертывании для A и B. Однако, это даст вам идентичные конфигурации для всех экземпляров модулей.

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

Answer 3

Чем больше я на это смотрю, тем больше понимаю, что K8S напрямую не отвечает моим требованиям.

Я реализую VNF, поэтому мне нужен еще один уровень абстракции.
В настоящее время я смотрю на OSM , который на первый взгляд выглядит так, как будто имеет то, что мне нужно.

Я попытаюсь обновить после того, как узнаю больше.