Быстрее что именно?

Быстрее что именно?

Ссылку уже дали

перфоманс немного отличается, например https://github.com/kunalkushwaha/ctr-powertest#performace

Кто-нибудь что-нибудь знает о containerum?

Кто-нибудь что-нибудь знает о containerum?

могу ссылку на доклад дать

@dmkrasnoff

да он не отвечает(

это тот доклад, где говорят что кубу не нужны контейнеры?

@Tazik_Evtanazik я ответил?

а kubeadm init может не запускать бинарники внутри CRI? а запускать самостоятельно systemd сервисы со скедулером и apiserver ?

Кто-нибудь что-нибудь знает о containerum?

Я там работал. Можешь в личку поспрашивать что интересно

плохой сис админ, забавный ник

ник все же класнный)

Если что всегда могу людям сказать "ну а чего вы ждали от badsysadm"?

без хельма пробовал?

Пробовал?

делаю helm install --name prometheus-operator --set rbacEnable=false --namespace=monitoring stable/prometheus-operator получаю Error: release prometheus-operator failed: customresourcedefinitions.apiextensions.k8s.io "alertmanagers.monitoring.coreos.com" already exists делаю kubectl delete crd alertmanagers.monitoring.coreos.com prometheuses.monitoring.coreos.com prometheusrules.monitoring.coreos.com servicemonitors.monitoring.coreos.com потом опят пытаюсь ставить но получаю тоже предупреждение

Убери из Helm Chart'а.

потом поставить их если поставит норм?

Нет. Забыть про них.

У тебя CRD сам prometheus-operator создаёт.

чооо?

1) https://github.com/kubedb/project/issues/330 эту багу мы нашли за месяц до создания этого issue где-то через полчаса тестирования. Там сочетание несколько оптимистичного восприятия гарантий, которые дает функционал выбора лидера в client-go и кучи башнянки, которая запихивается в образ, дергается из обвязки на go и имеет свойство ни на что не реагировать. Повторный перезапуск всего, кстати, при отсутствии в объявлении postgres-кластера источников для восстановления из бэкапа с высокой долей вероятности приведет к снова рабочей схеме "мастер + слейвы", но с идеально пустыми базами. Мы решили это радикально, переписав башнянку на го с использованием контекстов для своевременной отмены одного сценария, чтобы начать другой и вынесли логику из коллбэков лидер-электора в отдельный event loop, а коллбэки теперь просто отсылают сообщения в каналы. 2) Не умеет в pg_rewind, поэтому бывший мастер восстанавливается из бэкапа полностью 3) Не хватает альтернативы proxy из stolon, там просто перевешиваются лейблы на поды при смене лидера, но kube-proxy соединения-то не рвет. 4) С точки зрения кодовой базы: отвратительное управление зависимостями через glide с кучей форкнутых апстримовых либ, включая kubernetes/apiserver(!) c пустячными изменениями типа "а вот тут побольше логов, пожалуйста", которые в большинстве своем находятся в github.com/kmodules, но импортятся через kmodules.xyz/<package_name>, для чего используется алиасомагия glide'а. Зачем - непонятно. Плюс еще куча подобных подвохов. Теперь мы мучаемся, отдирая все это гвоздодером. 5) Никаких апгрейдов постгреса на новую мажорную версию, да

вы в основной проект котрибутите, или форкнули?

https://sourcegraph.com/github.com/coreos/prometheus-operator@e1d10ea5f2389afb21594b8c19197c52a9cee348/-/blob/pkg/prometheus/operator.go#L1417

Форкнул

а нафиг тогда они описаны в манифестах?

Паблик? сижу на столоне, из коробки не хватает снапшотов/бэкапов по расписанию, много движений ручками

Паблик? сижу на столоне, из коробки не хватает снапшотов/бэкапов по расписанию, много движений ручками

Хороший вопрос. У нас не описаны.

ну в смысле у них в манифестах, которые лежат в репозитории, они описаны

Хочу больше инфы. Список того, что ок и того что не ок

хотя если у тебя крд рядом с их использованием, то их можно применять все вместе

из того что ок - работает стабильно =) как внутри кластера так и снаружи, не ок - нет prod ready образов приходится свои билдить, не хватет пренудительного переключения мастера, pg_rewing на тестах не работал, в рамках куба sentinel - лишний элемент, proxy думал тоже - упустил что он не рвет соединения

Кстати, да. Но у мы по-очереди выкатку Prometheus Operator и Custom Objects его сделали.

из того что ок - работает стабильно =) как внутри кластера так и снаружи, не ок - нет prod ready образов приходится свои билдить, не хватет пренудительного переключения мастера, pg_rewing на тестах не работал, в рамках куба sentinel - лишний элемент, proxy думал тоже - упустил что он не рвет соединения

а как детектите момент когда появились крд?

я бы поспорил, что sentinel лишний - впиливание его функций в kubedb в тамошний аналог кипера мне не понравилось - это усложняет логику, замедляет фейловер, ну и еще и не работало, да

а как детектите момент когда появились крд?