Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 12

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

Даже в рамках одного продукта, но построенного на базе SOA/MSA унификация полезна. Когда с десяток сервисов деплоятся и конфигурируются единообразно, то это очень упрощает жизнь, как в плане регулярных задач, так и плане человеческой ошибки.

Во введении не написано, что хранение файлов в Kubernetes является самоцелью. По сути статья описывает часть большей задачи — по контейнеризации и миграции приложения в Kubernetes. Если такой задачи нет, то начинать лучше с понимания, зачем оно (Kubernetes) вообще нужно. Может быть, действительно не нужно?.. Без понимания/согласия на этом верхнем уровне нет смысла говорить про велосипеды и сравнивать с другими инструментами (что бы вы под ними ни подразумевали).

Для многих задач k8s выглядит оверхедом, но альтернатива ему полумёртвый Docker Swarm — технически для многих задач подходит почти идеально, но выглядит как путь в никуда: рано или поздно потребуются какие-то фичи k8s.

Складывается ощущение, что persistent storage это головная боль для k8s. При приличной нагрузке по iops решения вида Ceph, GlusterFS проигрывают «старомодным» решениям. Все-таки k8s в нынешнем виде очень тяжело готовить для statefull-приложений требовательных к дисковой системе.
Да вроде бы, понятно, что делать с k8s + требованием по большому iops. Нужно использовать локальные диски серваков, и прибивать pod к ним.

Как раз об этом Дмитрий рассказывал —

Есть ли какие-то рекомендации по поводу организации хранения для minio?

Как-то заметил в последнее время, что именно в k8s при формальных девизах 12f они нарушаются даже в примерах. Вот даже в посте: nginx конфигурируются через примонтированный конфиг, а не включением его в образ.


P. S. В Symfony специально работают над воспроизводимостью билдов.:)

а не включением его в образ.

Нет. Включение конфига внутрь докер-образа будет прямым нарушением 3го фатора — про конфигурацию.

В кубере есть kind: ConfigMap — конфиг хранится в etcd, и при старте пода он мапится в файл внутри пода. Это позволяет использовать один и тот же докер-образ с разными конфигами просто перезапуском пода

А как вариант с монтированием S3 в контейнеры через fuse? Буквально вчера столкнулся с идеей. А вообще был уверен, что для S3 в кубике если не из коробки есть драйвер, для storage class, то достаточно популярный. Увы :(

Ну если git volume диприкейтнули, то официального storage class под s3 наверное нет по схожим причинам… На практике же можно использовать инит контейнер с s3 клиентом и emptyDir

Зарегистрируйтесь на Хабре, чтобы оставить комментарий