Pull to refresh

Comments 12

Kubernetes ради kubernetes?
Зачем изобретать велосипеды, если для решения этих задач можно использовать другие интрументы?

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

Даже в рамках одного продукта, но построенного на базе 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

Sign up to leave a comment.