кого был успешный опыт как рулить сложными зависимостями в helm? Не зависимости уровня "Вордпрес", а что-то более сложное. Ну вот например есть у меня 5 микросервисов (на самом деле нет) на PHP. Например каждый сервис состоит из контейнеров: nginx, php-fpm, memcached, 3-10 воркеров которые слушают очередь. А еще есть общие редис кластер, rabbitmq, postgres, etc. Вопросы:
1) Стоит ли 1 сервис разбивать на несколько helm charts? или все пихать в один? Ведь все компоненты сервиса будут обновляться в одно время при деплое
2) Стоит ли описывать зависимости между сервисами и между сервисом и бд, редис кластером и т.д?
3) Насколько я понял имя релиза уникальное в kubernetes namespace. Тогда как называть релизы? stable/trunk/staging уже не подходят, а т.к. имя релиза идет в названии сервиса то как-то сложно будет поддерживать все эти зависимости когда например после релиза адрес бд поменяется
4) Как при helm upgrade обновлять что-то кроме deployments? Ну т.е. обновил я ConfigMap. А Deployment от этого не стал обновлять ReplicaSet и сами поды. Ключ --recreate-pods в данном случае не помогает
Буду рад ответам
зависимости в helm не то же самое что зависимости в yum и apt-get, если 2 чарта хотят редис, то будет 2 редиса в системе, а не один на всех. так что как минимум общие редисы и прочее должны быть отдельными helm релизами
Обсуждают сегодня