@yourallah еще вопрос, вы столона в том же кластере что и сам проект? или в отдельном?

Тюньте. Мне пока не надо, но не вижу причин почему тюнить нельзя. Куб не значит что база живет вместе с сотней других контейнеров

Аргумент это утверждение призванное подтвердить правоту.

да я и не спорю, что можно с помощью аффинити прибить базу к определенному набору нод, просто зачем? чем такое решение лучше, чем раскатать базу отдельно ансиблом

а лучше или хуже каждый выбирает для себя сам

да я и не спорю, что можно с помощью аффинити прибить базу к определенному набору нод, просто зачем? чем такое решение лучше, чем раскатать базу отдельно ансиблом

ну вот мы собственно и возвращаемся к https://t.me/kubernetes_ru/44321

я ж вас спросил, что вы будете делать в такой то ситуации. Где аргумент?

Ситуация это про переезд 3 подов в одну ноду? Ничего не буду, такая ситуация невозможна.

вопрос был про аргумент:) где он? опять с темы съехали.

вопрос был про аргумент:) где он? опять с темы съехали.

бд можете держать, тестовую например. почему сразу нельзя? я прям выделал ~прод~

Базу в кубе можно держать, если вы не боитесь, что из-за бага в докере вы её потеряете

Базу в кубе можно держать, если вы не боитесь, что из-за бага в докере вы её потеряете

в том же, зачем в другой кластер его?

в интернеты транслировать будете?

Не знаю. А кстати, почему именно stolon выбрали а не какой-нибудь patroni?

на тот момент вроде patroni не было ещё

А если бы выбирали сейчас, то чтобы выбрали?)

так считать-то не противозаконно, но если уж выносить на публику, аргументируй

Я уже сказал, что мой личный опыт - такое решение не приносит никаких преимуществ по сравнению с раскаткой базы на baremetal, вы не используете практически никакие из основных вещей в кубере (деплойменты с rollout strategy/сервисы/ингресы/hpa/autoscaling). Кубер подразумевает горизонтальное масштабирование крутящегося в нем, а базы горизонтально не масштабируются (в общем случае). Более того, для того чтобы задеплоить туда базу вы потратите гораздо больше времени и получите более сложную конфигурацию. Ну т.е я за то, чтобы решать реальную задачу средствами для решения именно ее. Например, у людей (во всем мире) была проблема - они не могли безопасно (zero-downtime), быстро и масштабируемо в реальном времени деплоить веб-сервисы (ну т.е могли, но по-настоящему это работало только у тех, кто это знатно удобрял миллионами $$$). И люди придумали сначала контейнеры, для создания воспроизводимых сред, а потом оркестрацию контейнеров, пожалуй лучшей из которых является кубер и он решает именно эту проблему. Ни одна из этих проблем не релевантна для БД, зато проблемы, которые релевантны для БД в проде - нужно решать на кубере костылями

альтернативное решение это как раз бд в кубере 😂

Вижу ток один плюс базы в кубаре, это что всякии мониторинг треш можно спокойно развернуть рядом

да я и не спорю, что можно с помощью аффинити прибить базу к определенному набору нод, просто зачем? чем такое решение лучше, чем раскатать базу отдельно ансиблом

Альтернатива — необходимость выбора одного из двух (или нескольких) возможных решений.

Альтернатива — необходимость выбора одного из двух (или нескольких) возможных решений.

Это уже полный зашквар. Если дошел до аффинити в клауде, то диагноз - клауд головного мозга.

Kubectl))))

https://github.com/ahmetb/kubectx

как выставить контейнеру sysctl-параметры буферов IO?

Да хоть на мезос рантайм, гарантий что и там ошибок нет нету)

Всем привет, подскажите, есть ли утилита для переключения разных конфигов, разных кластеров. Спасибо

для любителей GUI еще есть https://kubernetic.com/, ему если подсунуть один файл со слепленными кубконфигами всех нужных кластеров то можно будет мышью кластера переключать и т.д.

Вчера такой холивар про базы на кубе был, а я не успел)) Моё никому не нужное мнение: Запустить кластер какой-нибудь базы в кубере вполне реально, и он даже будет удовлетворительно работать. Преимущества: ну... можно хвастаться что смог и осилил) Недостатки: базы не знают что они в кубернетесе - всякие memory лимиты им противопоказаны. Следовательно, один Под с базой желательно чтоб распоряжался всей нодой, на которой он задеплоин. Например у монги, кроме кэша вайрвтайгера, который можно задать параметром, есть ещё кэш, который просто занимает половину свободной памяти на ноде, я не нашёл как его можно отрегулировать. И тогда смысл занимать весь сервер с кубернетевским оверхэдом для базы? с персистент-волюмами тоже отдельная тема, но которая имеет несколько решений, со своими преимуществами и недостатками. Но вот сил на то, чтобы это всё отладить и предусмотреть все кейсы уйдёт в разы больше, чем просто поднять рядом снэдэлон-кластер БД и забыть про него (ну ещё монтиоринг настроить, причём клиента запустить прямо в кубере - пусть пишет тудаже, где и все метрики кубернетеса)

Подскажите как пошарить сервис в наружу

Доброе утро, а есть варианты, если хочется странного? Кейс: есть две-три ingress only ноды, на которых запускать можно только daemonset с ingress контролерами или другие полезные daemonset. достигается это через drain --ignore daemonsets. Но после перезагрузки ноды это не работает. Можно ли ноду запускать с этой опцией при старте kubelet(не нашел в описание подобного)? Прописывать явные нод селекторы для всего не хочется.

С replicas: 1 делаю maxUnavail: 0 и получается избежать 5xx, но при фейле новой версии она остаётся висеть вечно и не даёт в дальнейшем обновиться.

LoadBalance, NodePort, Ingress

Вчера такой холивар про базы на кубе был, а я не успел)) Моё никому не нужное мнение: Запустить кластер какой-нибудь базы в кубере вполне реально, и он даже будет удовлетворительно работать. Преимущества: ну... можно хвастаться что смог и осилил) Недостатки: базы не знают что они в кубернетесе - всякие memory лимиты им противопоказаны. Следовательно, один Под с базой желательно чтоб распоряжался всей нодой, на которой он задеплоин. Например у монги, кроме кэша вайрвтайгера, который можно задать параметром, есть ещё кэш, который просто занимает половину свободной памяти на ноде, я не нашёл как его можно отрегулировать. И тогда смысл занимать весь сервер с кубернетевским оверхэдом для базы? с персистент-волюмами тоже отдельная тема, но которая имеет несколько решений, со своими преимуществами и недостатками. Но вот сил на то, чтобы это всё отладить и предусмотреть все кейсы уйдёт в разы больше, чем просто поднять рядом снэдэлон-кластер БД и забыть про него (ну ещё монтиоринг настроить, причём клиента запустить прямо в кубере - пусть пишет тудаже, где и все метрики кубернетеса)

касательно монги, вполне рабочий вариант - memlimit на контейнер в X Gb и memlimit для вареного тигра X/2 Gb.