helm controller имеет место быть

• HelmRepository CRD
• HelmChart CRD

этого достаточно
Так что ответ:
1. это не совсем helm operator
2. но по сути то же самое

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

Как ты сделаешь локальность файла и пода?

У тебя под может ездить по всем нодам кластера

Кмк ты не с той стороны заходишь к задаче

да, это понятно, но когда они рядом можно взять и локально с ноды

я одного не понял - зачем 50-ти сервисам обрабатывать один и тот же файл?

что за паттерн? точнее для какой задачи

Цеф тебя кстати не спасёт

Он сам твою сеть сожрет в момент репликации изменений

система обработки файлов. каждый  сервис получает инфу о файле потом группируется инфа. это на ETL похоже

в gcp был диск на RO для пачки подов с одновременным монтированием

может быть и без GCP так можно, хотя в любом случаи между нодами надо как-то шарить файл

кстати опять же в том же AWS есть хорошая штука под названием storage gateway… это nfs сервер с апстримом и кэшем к S3. Горячие файлы держит локально.

хмм ну как бы присутсвует и я вижу что количество подов меняется, но у меня ноды не появляются новые хотя в DO все включено читал доки все зделано правильно, уже перепроверял

а без HPA сервис скалируется вообще? должно же хоть что-то появляться

Ну, если костылить костыли костыльно, то внешняя сбоку-хранилка может реализовать getSHAsum(file), кэш файлов хранить на hostPath /cache/,

if !exist(/tmp/{file}) || getSHAsum(file) != shasum(/tmp/{file}) { download file }