#kubernetes #databases #azure #longread
Лонгрид на вечер.
Часть 1 из 4
Раз уж были вопросы, дополню своё мнение про базы в Kubernetes.
Не ради холивара, чисто технический разбор с моим взглядом на вещи.
Всё нижесказанное про базы данных в managed kubernetes (Azure/AWS).
С GCP опыта крайне мало и на него не буду ссылаться.
Мои тезисы строятся так - сама по себе идея "
- баз мало (ну, скажем, меньше 20 суммарно)
- размер их небольшой (допустим до гига)
- ops-команда шарит в бэкапах и ресторах на уровне профессионалов
В случае, когда баз становится больше, и даже команда вроде всё знает, вылезают проблемы, о которых ты раньше и не думал.
Что в AWS, что в Azure - везде свои сюрпризы, особенно неявные.
Ниже я опишу свой личный опыт большого количества баз в облачных куберах.
Зачем мы тащим базы в кубер?
Сделать себе больно? Потренироваться новыми достижениями?
Потетешкать самолюбие и похвастать на конфе?
Галочка в CV? Нет.
Изначально идея держать базы в кубере часто про экономию и удобство менеджмента(через оператора).
Мелкие базы в простое почти не жрут CPU и памяти, и если у вас есть много мелких баз, то на стоимости compute в AKS/EKS можно прилично сэкономить. Очень и очень прилично.
Плюс операторы - автоматизация, управление, всё красиво.
Мы сразу договорились: каждая база живёт в своём кластере.
Это из-за требований аудита и простой логики - чтобы "коммунальные кластеры" не ломали "соседей", если одна база вдруг начнёт жрать ресурсы как не в себя + секьюрити + изоляция.
По три реплики на базу - это не просто так: здравый смысл, богатый опыт с факапами баз и рекомендация по кворуму, чтобы не терять данные и не ловить даунтайм/сплитбрейн(а вот это я зря сказал, сейчас кааак раскритикуете🤣).
Лонгрид на вечер.
Часть 1 из 4
Раз уж были вопросы, дополню своё мнение про базы в Kubernetes.
Не ради холивара, чисто технический разбор с моим взглядом на вещи.
Всё нижесказанное про базы данных в managed kubernetes (Azure/AWS).
С GCP опыта крайне мало и на него не буду ссылаться.
Мои тезисы строятся так - сама по себе идея "
тащить базы в кубер" отличная, но ровно до момента, когда:- баз мало (ну, скажем, меньше 20 суммарно)
- размер их небольшой (допустим до гига)
- ops-команда шарит в бэкапах и ресторах на уровне профессионалов
В случае, когда баз становится больше, и даже команда вроде всё знает, вылезают проблемы, о которых ты раньше и не думал.
Что в AWS, что в Azure - везде свои сюрпризы, особенно неявные.
Ниже я опишу свой личный опыт большого количества баз в облачных куберах.
Зачем мы тащим базы в кубер?
Сделать себе больно? Потренироваться новыми достижениями?
Потетешкать самолюбие и похвастать на конфе?
Галочка в CV? Нет.
Изначально идея держать базы в кубере часто про экономию и удобство менеджмента(через оператора).
Мелкие базы в простое почти не жрут CPU и памяти, и если у вас есть много мелких баз, то на стоимости compute в AKS/EKS можно прилично сэкономить. Очень и очень прилично.
Плюс операторы - автоматизация, управление, всё красиво.
Мы сразу договорились: каждая база живёт в своём кластере.
Это из-за требований аудита и простой логики - чтобы "коммунальные кластеры" не ломали "соседей", если одна база вдруг начнёт жрать ресурсы как не в себя + секьюрити + изоляция.
По три реплики на базу - это не просто так: здравый смысл, богатый опыт с факапами баз и рекомендация по кворуму, чтобы не терять данные и не ловить даунтайм/сплитбрейн(а вот это я зря сказал, сейчас кааак раскритикуете🤣).
👍9
#kubernetes #databases #azure #longread
Часть 2 из 4
Берём пример.
У нас есть AKS-кластер, инстансы
Заливаешь одну среднюю БД, смотришь нагрузочное тестирование - в простое совсем мелкий CPU/memory usage.
Включаешь арифметику с умножением и думаешь "Отлично, сейчас закину кучу баз на пару нод".
Вынужден расстроить, но так у тебя не получится сделать, давай разберёмся почему.
1. Количество дисков
Читаешь доки Azure - максимум 16 диска на наш инстанс. Patroni для HA просит 3 реплики, то есть 3 PV на базу. Считаем: 16 дисков - это 5 изолированных кластеров БД (комплаенс, привет), 1 в запасе или под мелочи.
Поднял 3 кластера по 3 реплики - и всё, приехали, больше некуда.
https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series?tabs=sizestorageremote
Думаешь ладно. Денег много, возьму в этом же семействе инстанс дороже и мощнее, но и там ограничение 32 диска(10 кластеров + 2 диска под другие нужны).
2а. Максимальное количество подов на ноде (параметр
В Azure CNI дают до 250 подов на ноду, но по умолчанию нашего инстанса 80.
Считаем: апп с HPA (1 апп + 2 min HPA реплики) + Patroni (3 пода) = 6 подов на микросервис. Минус системные штуки (CNI, CSI, экспортёры, filebeat и так далее) - остаётся где-то 65.
То есть при привычных всем системным ресурсам и 3 репликам на бизнес микросервис апп + 3 реплики кластера БД, мы не сможем поднять больше 10 кластеров(да и не смогли бы, диски раньше нас тормознули бы).
https://learn.microsoft.com/en-us/azure/aks/azure-cni-overlay?tabs=kubectl#maximum-pods-per-node
2б. Резервирование памяти (параметр MAX_PODS)
Временно забудем про первый пункт с дисками и пофантазируем "Сейчас увеличу до 200 макс подс, в конфиге же легко и нам не будет мешать этот параметр".
AKS забирает память под ОС и kubelet: примерно 20 МБ на под + запас + операционная система +hard eviction.
Формула примерно такая, тут не буду топить за точность вычислений, на память пишу
(20 MB × 200(max_pods)) + 50 MB + 100 MB
Из ожидаемых тобой 32 гигабайт на ноде ты получаешь доступным для аллокации будет меньше.
С учётом hard eviction 100mb цифры примерно такие для нашего инстанса:
При
При
При
В попытке уместить не умещаемое ты теряешь драгоценную память на ноде.
Часть 2 из 4
Берём пример.
У нас есть AKS-кластер, инстансы
Standard_D8as_v5 - 8 ядер, 32 ГБ RAM. Заливаешь одну среднюю БД, смотришь нагрузочное тестирование - в простое совсем мелкий CPU/memory usage.
Включаешь арифметику с умножением и думаешь "Отлично, сейчас закину кучу баз на пару нод".
Вынужден расстроить, но так у тебя не получится сделать, давай разберёмся почему.
1. Количество дисков
Читаешь доки Azure - максимум 16 диска на наш инстанс. Patroni для HA просит 3 реплики, то есть 3 PV на базу. Считаем: 16 дисков - это 5 изолированных кластеров БД (комплаенс, привет), 1 в запасе или под мелочи.
Поднял 3 кластера по 3 реплики - и всё, приехали, больше некуда.
https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series?tabs=sizestorageremote
Думаешь ладно. Денег много, возьму в этом же семействе инстанс дороже и мощнее, но и там ограничение 32 диска(10 кластеров + 2 диска под другие нужны).
2а. Максимальное количество подов на ноде (параметр
MAX_PODS)В Azure CNI дают до 250 подов на ноду, но по умолчанию нашего инстанса 80.
Считаем: апп с HPA (1 апп + 2 min HPA реплики) + Patroni (3 пода) = 6 подов на микросервис. Минус системные штуки (CNI, CSI, экспортёры, filebeat и так далее) - остаётся где-то 65.
То есть при привычных всем системным ресурсам и 3 репликам на бизнес микросервис апп + 3 реплики кластера БД, мы не сможем поднять больше 10 кластеров(да и не смогли бы, диски раньше нас тормознули бы).
https://learn.microsoft.com/en-us/azure/aks/azure-cni-overlay?tabs=kubectl#maximum-pods-per-node
2б. Резервирование памяти (параметр MAX_PODS)
Временно забудем про первый пункт с дисками и пофантазируем "Сейчас увеличу до 200 макс подс, в конфиге же легко и нам не будет мешать этот параметр".
AKS забирает память под ОС и kubelet: примерно 20 МБ на под + запас + операционная система +hard eviction.
Формула примерно такая, тут не буду топить за точность вычислений, на память пишу
(20 MB × 200(max_pods)) + 50 MB + 100 MB
Из ожидаемых тобой 32 гигабайт на ноде ты получаешь доступным для аллокации будет меньше.
С учётом hard eviction 100mb цифры примерно такие для нашего инстанса:
При
--max-pods=80: ~28.7 GB (28714 MB)При
--max-pods=200: ~26.3 GB (26314 MB)При
--max-pods=250: ~25.3 GB (25314 MB)В попытке уместить не умещаемое ты теряешь драгоценную память на ноде.
👍5
#kubernetes #databases #azure #longread
Часть 3 из 4
3. Сетевой стек
Azure CNI 250 IP на ноду, звучит неплохо. Но неявные проблемы - это отдельная песня. Первое: задержки между репликами. Думаешь, раз в одном кластере, сеть летает, а на деле CNI overlay добавляет 1-5 мс, и для синхронной репликации (типа Patroni) это уже ощутимо. Второе: подсеть кластера. Сотни баз, поды плодятся, и твоя дефолт /24 (256 IP) заканчивается на раз-два, а расширить - рестарт кластера и нервы. Третье: пропускная способность. NIC на ноде (12500 Mb/s) делится на всех, и 200 подов с трафиком - это бутылочное горлышко.
4. Бекапы
Мы разобрались(нет) с первыми болями и дошли до масштабирования.
Подняли dev кластер, развесили taints/toleration, скейлинг нод и подов, задеплоили оператора, на аппы повесили клеймы кластеров/БД, рассчитали, что вам надо, допустим по 4 кластера на ноду. Везде всё умещается.
Время учится делать бекапы. Допустим вы решили пойти путем через velero(а оно чертовски удобное).
Поставили расписание снепшотов, радостно проверили пару баз и ушли домой.
Утром приходите и видите - все запланированные бекапы не сработали. Копаясь в ивентах и логах вы поняли, что не хватило дисков.
с Azure Disk и VolumeSnapshot нюанс: для восстановления из снапшота нужен новый PVC, а дисков и так не хватает. Сами снапшоты PVC не требуют, но при развёртывании - да.
А если расписания в Velero, то без костылей никак: все снепшоты штатно запускаются разом - и по всему кластеру дисков не найти. Пока новые ноды в нужных зонах/регионах запустятся, джоба велеро просто упадёт по таймауту.
Разносишь по времени, ограничиваешь параллельность - выкручиваешься.
Уже на этих аргументах, подкрепленных моей болью, поеданием полной ложки коричневой субстанции я предлагаю завершить монолог "почему много баз в кубере это плохо", но мы идём дальше.
Часть 3 из 4
3. Сетевой стек
Azure CNI 250 IP на ноду, звучит неплохо. Но неявные проблемы - это отдельная песня. Первое: задержки между репликами. Думаешь, раз в одном кластере, сеть летает, а на деле CNI overlay добавляет 1-5 мс, и для синхронной репликации (типа Patroni) это уже ощутимо. Второе: подсеть кластера. Сотни баз, поды плодятся, и твоя дефолт /24 (256 IP) заканчивается на раз-два, а расширить - рестарт кластера и нервы. Третье: пропускная способность. NIC на ноде (12500 Mb/s) делится на всех, и 200 подов с трафиком - это бутылочное горлышко.
4. Бекапы
Мы разобрались(нет) с первыми болями и дошли до масштабирования.
Подняли dev кластер, развесили taints/toleration, скейлинг нод и подов, задеплоили оператора, на аппы повесили клеймы кластеров/БД, рассчитали, что вам надо, допустим по 4 кластера на ноду. Везде всё умещается.
Время учится делать бекапы. Допустим вы решили пойти путем через velero(а оно чертовски удобное).
Поставили расписание снепшотов, радостно проверили пару баз и ушли домой.
Утром приходите и видите - все запланированные бекапы не сработали. Копаясь в ивентах и логах вы поняли, что не хватило дисков.
с Azure Disk и VolumeSnapshot нюанс: для восстановления из снапшота нужен новый PVC, а дисков и так не хватает. Сами снапшоты PVC не требуют, но при развёртывании - да.
А если расписания в Velero, то без костылей никак: все снепшоты штатно запускаются разом - и по всему кластеру дисков не найти. Пока новые ноды в нужных зонах/регионах запустятся, джоба велеро просто упадёт по таймауту.
Разносишь по времени, ограничиваешь параллельность - выкручиваешься.
Уже на этих аргументах, подкрепленных моей болью, поеданием полной ложки коричневой субстанции я предлагаю завершить монолог "почему много баз в кубере это плохо", но мы идём дальше.
😁6👍3
#kubernetes #databases #azure #longread
Часть 4 из 4
5. Операторы и типы баз данных.
"ой, а ты же даже ничего не сказал про типы базы данных(MySQL, PostgreSQL, MongoDB etc), ты ничего не сказал про операторы и разницу между ними, как же так?".
Каждый из операторов, которые я трогал в 2024-2025 годах обладал своими минусами.
Пожалуй отдельно могу отметить только https://cloudnative-pg.io/. Он невероятно чертовски хорош и очень быстро развивается.
Остальные почти все не годятся вам с дефолтными параметрами.
Например zalando оператор по дефолту с выключенной фичей DCS.
https://github.com/zalando/postgres-operator/blob/master/charts/postgres-operator/values.yaml#L454
Это гарантирует вам регулярную проблему с
Почитать вам https://patroni.readthedocs.io/en/master/dcs_failsafe_mode.html
Другой дефолтный параметр вообще превратит ваш кластер в постоянно расползающийся лаг, который будет течь как красотки на концерте Энрике Иглесиаса.
6. IOPS
Потом в процессе эксплуатуации доходит, что IOPS в Azure (и в AWS EKS) от размера диска зависит.
Мелкий диск (допустим 128 ГБ) - 500 IOPS, и для активных баз это ни о чём.
Хочешь больше - бери 512 ГБ (2300 IOPS) или 1 ТБ (5000 IOPS).
База мелкая, а из-за трёх реплик платишь за объём втридорога.
То есть в том случае, если ваш тип базы данных потребляет много IOPS, то вам придётся брать большие скоростные диски, а это уже не так весело и совсем не так дёшево.
"Так каков итог?" - спросите вы. Можно или нельзя пихать БД в managed кубер AKS/EKS?
Мой ответ такой:
- когда много баз - нельзя. Аргументы выше.
- когда базы очень большие(размер, большое потребление ресурсов CPU/Memory) - совершенно нельзя. Аргумент мне не хватило времени написать, может позже накатаю пост. не обещаю, много работы.
- когда OPS команда неквалифицированная. При ресторах будут большие проблемы, а DRP вам не всегда сможет помочь.
Это основные тезисы и рекомендации.
Мы можем сделать фактор репликации 2 или даже 1 реплику, но это уже не про HA.
Мы можем сделать 1 кластер на все базы, но это уже не про изоляцию и безопасность.
Выбор за каждым.
Update:
Апдейтнул пост, добавив, что рекомендации только для AKS/EKS.
Ничего не смогу сказать за других облачных провайдеров, у меня нет этого опыта.
Там могут не быть этих корнер кейсов(но могут быть другие).
Ничего не могу сказать за managed k8s, меня вселенная бережёт от работы с ними.
Часть 4 из 4
5. Операторы и типы баз данных.
"ой, а ты же даже ничего не сказал про типы базы данных(MySQL, PostgreSQL, MongoDB etc), ты ничего не сказал про операторы и разницу между ними, как же так?".
Каждый из операторов, которые я трогал в 2024-2025 годах обладал своими минусами.
Пожалуй отдельно могу отметить только https://cloudnative-pg.io/. Он невероятно чертовски хорош и очень быстро развивается.
Остальные почти все не годятся вам с дефолтными параметрами.
Например zalando оператор по дефолту с выключенной фичей DCS.
https://github.com/zalando/postgres-operator/blob/master/charts/postgres-operator/values.yaml#L454
Это гарантирует вам регулярную проблему с
demoting self because DCS is not accessible and I was a leader и тем, что аппликейшны не смогут подключаться к кластеру (помогает рестарт аппликейшна, как ни странно).Почитать вам https://patroni.readthedocs.io/en/master/dcs_failsafe_mode.html
Другой дефолтный параметр вообще превратит ваш кластер в постоянно расползающийся лаг, который будет течь как красотки на концерте Энрике Иглесиаса.
6. IOPS
Потом в процессе эксплуатуации доходит, что IOPS в Azure (и в AWS EKS) от размера диска зависит.
Мелкий диск (допустим 128 ГБ) - 500 IOPS, и для активных баз это ни о чём.
Хочешь больше - бери 512 ГБ (2300 IOPS) или 1 ТБ (5000 IOPS).
База мелкая, а из-за трёх реплик платишь за объём втридорога.
То есть в том случае, если ваш тип базы данных потребляет много IOPS, то вам придётся брать большие скоростные диски, а это уже не так весело и совсем не так дёшево.
"Так каков итог?" - спросите вы. Можно или нельзя пихать БД в managed кубер AKS/EKS?
Мой ответ такой:
- когда много баз - нельзя. Аргументы выше.
- когда базы очень большие(размер, большое потребление ресурсов CPU/Memory) - совершенно нельзя. Аргумент мне не хватило времени написать, может позже накатаю пост. не обещаю, много работы.
- когда OPS команда неквалифицированная. При ресторах будут большие проблемы, а DRP вам не всегда сможет помочь.
Это основные тезисы и рекомендации.
Мы можем сделать фактор репликации 2 или даже 1 реплику, но это уже не про HA.
Мы можем сделать 1 кластер на все базы, но это уже не про изоляцию и безопасность.
Выбор за каждым.
Update:
Апдейтнул пост, добавив, что рекомендации только для AKS/EKS.
Ничего не смогу сказать за других облачных провайдеров, у меня нет этого опыта.
Там могут не быть этих корнер кейсов(но могут быть другие).
Ничего не могу сказать за managed k8s, меня вселенная бережёт от работы с ними.
👍11