Comments 22
А какая система хранения файлов на том же железе будет быстрее чем NFS?
Быстрый NFS на флэшках, подключенный к кластеру сетью 10Gbps.
Ключевое было "на том же железе". Вот есть NFS-сервер, решили в кубер переехать, надо ли сносить на нём NFS и ставить что-то другое или оставить как есть?
Так может делать rook и longhorn из того что приходилось использовать.
Поэтому есть смысл оставить как есть, потому что для администрирования того же ceph нужны совершенно другие знания и это может оказаться проблемой.
При нужде со временем сможете поменять nfs на что-то более подходящее.
А на одном хосте она как будет по сравнению с NFS?
В рамках одного хоста NFS, вероятно, будет лучшим решением по соотношению сложности развертывания / поддержки и работоспособности.
Я это знаю. Собственно потому и вызвал недоумение совет заменить его на что-то более быстрое без упоминания что сначала надо пачку серверов купить.
Как-то это не ясно из статьи. Да и термин "ошибка уровня Pro" какой-то расплывчатый. Будет ли ошибкой уровня Pro решение использовать имеющийся NFS, если на предложение купить пару-тройку серверов бизнес ответил отказом, сделав уточнение в SLA что файлы там могут быть недоступны сутки например?
P.S. Увидел апдейт, в общем ситуация кажется "как не сделать ошибок при неограниченных бюджетах"
Тогда все равно нужно делать бэкапы файлов, выделять под это дополнительные серверы, писать проверки консистентности данных.
И хранение файлов не единственный кейс для СХД в Kubernetes. Например, вам нужно будет развернуть систему мониторинга. Ей нужно хранить данные.
Что делают в маленьких проектах на self-hosted Kubernetes? Прибивают Prometheus к одной ноде, на которой он и хранит данные. Если нода выйдет из строя, кластер останется без мониторинга. Prometheus не сможет переехать на другую ноду, так как его данные никак не шарятся по кластеру. Или сможет, но с потерей данных.
Можно, конечно, вынести мониторинг из кластера на отдельные серверы, но, во-первых, это как раз ведет к увеличению необходимых затрат на инфраструктуру, во-вторых, все также ведет к недоступности мониторинга в случае выхода из строя сервера.
Критично ли это? Если не принципиально наличие мониторинга 100% времени, то нет, можно действительно жить так. Но для большинства крупных проектов это будет недопустимо
под базой данных в Kubernetes будет лежать сетевое хранилище
Кто же так вообще делает в серьёзном проде?
Именно стейтфул, а не всякие in-memory.
Это действительно самые распространенные косяки ) Но 11 конечно самая болевая точка
В официальной доке я давно и плотно, но «прорыва» так и не случилось. С простыми шаблонами разобрался, а вот сложные конструкции ставят в тупик.
11 факапов PRO-уровня при внедрении Kubernetes и как их избежать