Открыть список
Как стать автором
Обновить

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

Вам надо 11 пункт вынести вверх списка номером 0. :)

А какая система хранения файлов на том же железе будет быстрее чем NFS?

Быстрый NFS на флэшках, подключенный к кластеру сетью 10Gbps.

Ключевое было "на том же железе". Вот есть NFS-сервер, решили в кубер переехать, надо ли сносить на нём NFS и ставить что-то другое или оставить как есть?

Ну вы можете использовать Storage Provider, который позволит вам использовать существующий NFS как persistent volume.
Так может делать rook и longhorn из того что приходилось использовать.
Поэтому есть смысл оставить как есть, потому что для администрирования того же ceph нужны совершенно другие знания и это может оказаться проблемой.
При нужде со временем сможете поменять nfs на что-то более подходящее.
Например, CephFS, так как это распределенная система хранения и хранить (и отдавать) данные она может распределенно на нескольких хостах, что повышает скорость доступа к данным.

А на одном хосте она как будет по сравнению с NFS?

Ceph — кластерная система хранения данных, использование ее в рамках одного хоста вряд ли принесёт какой то профит. Вся суть достижения отказоустойчивости — использование нескольких независимых серверов для резервирования данных.
В рамках одного хоста NFS, вероятно, будет лучшим решением по соотношению сложности развертывания / поддержки и работоспособности.

Я это знаю. Собственно потому и вызвал недоумение совет заменить его на что-то более быстрое без упоминания что сначала надо пачку серверов купить.

В рамках статьи я говорю об ошибках уровня Pro, то есть на проектах, где для выполнения SLA надо выстраивать отказоустойчивые кластерные системы на всех уровнях: начиная от гипервизоров и оркестраторов, заканчивая СХД, системами мониторинга и логирования. И простые решения там просто перестают работать.

Как-то это не ясно из статьи. Да и термин "ошибка уровня Pro" какой-то расплывчатый. Будет ли ошибкой уровня Pro решение использовать имеющийся NFS, если на предложение купить пару-тройку серверов бизнес ответил отказом, сделав уточнение в SLA что файлы там могут быть недоступны сутки например?


P.S. Увидел апдейт, в общем ситуация кажется "как не сделать ошибок при неограниченных бюджетах"

Нет, в этом случае использование NFS не будет ошибкой. В любом случае нужно исходить из требований бизнеса. Другой вопрос: бизнес может устраивать недоступность файлов в течение суток, но устроит ли его потеря файлов?
Тогда все равно нужно делать бэкапы файлов, выделять под это дополнительные серверы, писать проверки консистентности данных.

И хранение файлов не единственный кейс для СХД в Kubernetes. Например, вам нужно будет развернуть систему мониторинга. Ей нужно хранить данные.
Что делают в маленьких проектах на self-hosted Kubernetes? Прибивают Prometheus к одной ноде, на которой он и хранит данные. Если нода выйдет из строя, кластер останется без мониторинга. Prometheus не сможет переехать на другую ноду, так как его данные никак не шарятся по кластеру. Или сможет, но с потерей данных.
Можно, конечно, вынести мониторинг из кластера на отдельные серверы, но, во-первых, это как раз ведет к увеличению необходимых затрат на инфраструктуру, во-вторых, все также ведет к недоступности мониторинга в случае выхода из строя сервера.

Критично ли это? Если не принципиально наличие мониторинга 100% времени, то нет, можно действительно жить так. Но для большинства крупных проектов это будет недопустимо
под базой данных в Kubernetes будет лежать сетевое хранилище

Кто же так вообще делает в серьёзном проде?

А можете рассказать в каких случая база вообще себя оправдывает в кубике?
Именно стейтфул, а не всякие in-memory.

Унификация разворачивания — натравили один чарт на нулевый кластер (вариант — неймспэйс) и получили готовую систему через некоторое время.

В Kubernetes база данных может быть оправдана для тестирования, разворачивания динамических окружений по кнопке, всяческих PoC.

Возможно ещё для multi tenant

Да, я бы тоже не советовал так делать, как раз из-за увеличения задержки. Однако на практике бывают разные задачи и разные по нагрузке проекты
А нет варианта этой статьи на английском? Очень хочется дать почитать данную статью некоторым руководителям.

Это действительно самые распространенные косяки ) Но 11 конечно самая болевая точка

Коллеги! Пользуясь случаем, посоветуйте простой и понятный документ/туториал объясняющий язык шаблонов «Constraint Templates» для OPA Gatekeeper в части написания rego.
В официальной доке я давно и плотно, но «прорыва» так и не случилось. С простыми шаблонами разобрался, а вот сложные конструкции ставят в тупик.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
team.mail.ru
Численность
5 001–10 000 человек
Дата регистрации
Представитель
Павел Круглов

Блог на Хабре