Блог

Учитывая следующую схему сервисов и их зависимостей, я хотел бы разработать набор диаграмм Helm.

• API Gateway вызовы Service A и Service C
• Service A вызовы Service B
• Service B вызовы Database
• Service C вызовы Service B и Service D

На данный момент я вижу две альтернативы:

1. Каждый из 6 компонентов на диаграмме ниже представляет собой отдельную диаграмму, и каждая стрелка на диаграмме представляет собой отдельную зависимость.
   

2. Существует Umbrella диаграмма, которая зависит от всех других диаграмм. Database Диаграмма является зависимостью от Service B диаграммы.
   

В документации Helm предлагается использовать вариант 2. Однако я больше склоняюсь к варианту 1 из-за простоты локальной разработки и конвейера CI / CD.

Пример сценария: разработчик проводит рефакторинг Service C и он хочет запустить измененный им код и протестировать его.

• Вариант 1. Разработчик устанавливает только Service C диаграмму.
• Вариант 2: Разработчику придется либо:
  • установите Umbrella диаграмму, которая приводит к пустой трате ресурсов процессора и памяти из-за запуска ненужных сервисов, таких как Service A или API Gateway , которые плохо масштабируются в соответствии со сложностью системы;
  • установить Service C , затем Service B и затем Service D , что также плохо масштабируется при сложности системы, поскольку требует выполнения многих действий вручную, а также требует от разработчика быть знакомым с архитектурой системы, чтобы знать, какие диаграммы необходимо установить.

Я хотел бы принять обоснованное решение о том, какую альтернативу выбрать. Я больше склоняюсь к варианту 1, но документы Helm, а также несколько примеров, которые я смог найти в Интернете (ссылка), также подходят к варианту 2, поэтому я думаю, что, возможно, я что-то упускаю.

Я бы рекомендовал одну диаграмму для каждой службы с дополнительным упрощением, заключающимся в том, что диаграмма «service B» зависит от ее базы данных. Я бы сделал эти диаграммы независимыми: ни одна из служб не зависит ни от одной другой.

Зависимости Helm хорошо работают там, где у вас есть сервис, который встраивает / скрывает отдельные другие части. База данных, лежащая в основе B, например, является деталью реализации, и ничто за пределами B не должно знать об этом. Таким образом, B может зависеть от stable/postgres или чего-то подобного, и это хорошо работает в Helm.

Существует одна конкретная механическая проблема, которая создает проблемы для подхода с использованием зонтичных диаграмм. Скажем, служба D также зависела от базы данных, и это был один и тот же «вид» базы данных (скажем, оба используют PostgreSQL). Операционно вы хотите, чтобы эти две базы данных были разделены. Helm увидит два пути umbrella > B > database и umbrella > D > database и установит только одну копию диаграммы базы данных, так что в итоге две службы будут совместно использовать базу данных. Вы, вероятно, этого не хотите.

Другая механическая проблема, с которой вы столкнетесь при использовании зависимостей Helm здесь, заключается в том, что большинство ресурсов именуются некоторым вариантом {{ .Release.Name }}-{{ .Chart.Name }} . В вашем варианте 1, допустим, вы просто устанавливаете service C; в итоге вы получите развертывания типа service-C-C , service-C-B , service-C-database . Если бы вы затем захотели развернуть сервис A рядом с ним, это привело бы к появлению собственного service-A-B и service-A-database , что опять же не то, что вы хотите.

Я не в курсе отличного высокоуровневого решения с открытым исходным кодом для этой проблемы. Решение на основе Make является хакерским, но может работать:

 # -*- gnu-make -*-
all: api-proxy.deployed

%.deployed:
        helm upgrade --install --name $* -f values.yaml ./charts/$*
        touch $@

api-proxy.deployed: a.deployed c.deployed
a.deployed: b.deployed
c.deployed: b.deployed d.deployed