Watch config не устроил именно своей автоматикой, хотелось тут ручного управления. Плюс в той версии, когда мы смотрели первый раз (0.14), в нем были баги.
Да. Скрипт выводит diff между старым и новым конфигом и текст ошибки от vector. Чаще всего можно однозначно и легко
Пока не сталкивались, но планируем решать как в Prometheus operator - делить автоматом на чанки и хранить сразу в нескольких конфигмарах.
Код релоадера у нас теперь написан на Go. Лежит вот здесь.
Пока ещё никто не спрашивал. В будущем рассмотрим такую возможность.
Сейчас можно установить Deckhouse в уже существующий кластер и включить там только один модуль для сборки логов, но это больше для тестирования подходит, не для использования в production.
Добрый день! Мне тоже нравится статья, которую вы привели в пример. Она более всеобъемлющая, да и картинки там очень хорошие.
Статья, которая я написал, более узконаправленная, сфокусированная лишь на небольшом кусочке OIDC. Она должна отвечать на вопросы по типу: "А как мне получить токен, если у меня два сервера, на которых нет браузера?" Изначально она была страницей документации для dexidp.io, в разработке которого мы принимаем участие, но получилась более художественной, чем нужно.
В любом случае, спасибо большое за обратную связь!
В ближайших планах по storage для baremetal в порядке приоритетов: 1. local-storage provisioner (какой именно и как выглядеть будет пока не решили) 2. ceph-csi
По порядку на оба вопроса: 1. У нас в Deckhouse сейчас нет готового решения для backup'ов. Есть перспективные open source проекты, в сторону которых мы смотрим, но пока без конкретики. 2. По событиям пока тоже не решен вопрос. Если коротко, то задача на эту тему есть в беклоге, но мы его немного отложили ради публичного релиза.
Да, всё верно, тут хорошее замечание. В статье есть скрипт с примером бекапов. Он делает как раз то, что вы описали. Если не делать nodetool drain, все должно пройти гладко.
Если вопрос конкретно про нас, то мы обслуживаем большое число Kubernetes-кластеров, где Cassandra, например, используется для инсталляций Jaeger, поэтому удобно (эффективно для управления), чтобы всё было сделано унифицировано. Другой кейс — уже упомянут выше, когда регулярно (и автоматически) нужно выкатывать однотипные окружения (для целей разработки), имеющие в своём составе Cassandra. Какие потребности у других — может быть, они расскажут об этом сами. Статья написана не для ответа на вопрос, «зачем», а о том, «как» это можно делать на сегодняшний день (и для тех, кому это нужно уже сейчас или в скором времени).
Призывов проводить миграцию (тем более — как самоцель) здесь нет.
Чтобы осуществлять переезд с одной инфраструктуры на другую, нужно четко понимать зачем.
Если есть понимание, что переезд будет натягиванием совы на глобус — лучше оставить птичку в покое.
Суть статьи — помочь с пониманием нюансов, если кто-то захочет перевезти свою Cassandra в Kubernetes.
P.s.: В ходе написания статьи ни одна сова не пострадала.
multiDC можно достичь заведением нод kubernetes кластера в нескольких DC. Повесить на ноды специфичные для DC label’ы/taint’ы. Указать для cassandra toleration и affinity. Для этого, как указано в статье, нам придется использовать более чем один statefulset. Практически все операторы это вопрос решают.
Возникает вопрос по поводу того, как гарантировать доступность master нод, но это уже другая история :)
Конкретно в нашем случае — удобнее готовить новый узел. Инфраструктура в наших kubernetes кластерах выстроена так, что при добавлении ноды мы автоматически получаем всё необходимое: настройку системных параметров, мониторинг и т. д.
Чтобы на этом (уже готовом для работы) узле оказалась Cassandra, зачастую нужно сделать только две вещи:
1. Определиться, где будут лежать данные.
2. Увеличить количество нод в statefulset’е (или другой абстракции оператора) на 1.
Спасибо за отзыв! Приятно видеть, что ещё кого-то волнует тема.
Смотрим иногда на kopf. Кажется перспективным, да и код выглядит красиво. Все никак руки не дойдут попробовать :)
Более серьёзные операторы сейчас, все же, стараемся писать на Go.
Алертов не так много. Все лежат здесь.
Есть ещё dashboard для Grafana.
Решает проблемы доставки телеметрии в разные источники. Такого софта много. Сейчас на подходе, например OpenTelemetry collector.
Promtail - сразу мимо. Он не производительный, он узконаправленный. Даже свою маленькую проблему он решает плохо.
Если взять fluentbit v3, то это самое близкое, что сейчас есть на рынке, похожее на vector, но большинство необходимых фичей появились не так давно.
Вообще современному fluentbit я говорю "да". Это хороший проект. Есть инсайд, что его используют внутри AWS и GCP для процессинга данных.
У него есть несколько минусов, которые вижу сразу, но это уже отдельная стать! За вопрос большое спасибо.
Watch config не устроил именно своей автоматикой, хотелось тут ручного управления. Плюс в той версии, когда мы смотрели первый раз (0.14), в нем были баги.
Да. Скрипт выводит diff между старым и новым конфигом и текст ошибки от vector. Чаще всего можно однозначно и легко
Пока не сталкивались, но планируем решать как в Prometheus operator - делить автоматом на чанки и хранить сразу в нескольких конфигмарах.
Код релоадера у нас теперь написан на Go. Лежит вот здесь.
Отдельно сейчас нет.
Пока ещё никто не спрашивал. В будущем рассмотрим такую возможность.
Сейчас можно установить Deckhouse в уже существующий кластер и включить там только один модуль для сборки логов, но это больше для тестирования подходит, не для использования в production.
У нас свой, это часть платформы https://deckhouse.io/
Про техническое решение почитать можно тут. А здесь есть примеры custom resources.
Пометку, что хотелось бы увидеть сравнение, в блокнотике себе сделал.
Это нужна ещё одна статья. К сожалению, время на доклад было ограничено.
Добрый день! Мне тоже нравится статья, которую вы привели в пример. Она более всеобъемлющая, да и картинки там очень хорошие.
Статья, которая я написал, более узконаправленная, сфокусированная лишь на небольшом кусочке OIDC. Она должна отвечать на вопросы по типу: "А как мне получить токен, если у меня два сервера, на которых нет браузера?" Изначально она была страницей документации для dexidp.io, в разработке которого мы принимаем участие, но получилась более художественной, чем нужно.
В любом случае, спасибо большое за обратную связь!
В ближайших планах по storage для baremetal в порядке приоритетов:
1. local-storage provisioner (какой именно и как выглядеть будет пока не решили)
2. ceph-csi
По порядку на оба вопроса:
1. У нас в Deckhouse сейчас нет готового решения для backup'ов. Есть перспективные open source проекты, в сторону которых мы смотрим, но пока без конкретики.
2. По событиям пока тоже не решен вопрос. Если коротко, то задача на эту тему есть в беклоге, но мы его немного отложили ради публичного релиза.
По обеим вопросам можно завести issue на Github. Мы будем периодически их проверять, обсуждать, брать в работу.
https://github.com/deckhouse/deckhouse/issues/new
Добрый день. Ingress от Istio в планах, как альтернатива. Будем на него смотреть, изучать.
Призывов проводить миграцию (тем более — как самоцель) здесь нет.
Если есть понимание, что переезд будет натягиванием совы на глобус — лучше оставить птичку в покое.
Суть статьи — помочь с пониманием нюансов, если кто-то захочет перевезти свою Cassandra в Kubernetes.
P.s.: В ходе написания статьи ни одна сова не пострадала.
Возникает вопрос по поводу того, как гарантировать доступность master нод, но это уже другая история :)
Чтобы на этом (уже готовом для работы) узле оказалась Cassandra, зачастую нужно сделать только две вещи:
1. Определиться, где будут лежать данные.
2. Увеличить количество нод в statefulset’е (или другой абстракции оператора) на 1.
Спасибо за отзыв! Приятно видеть, что ещё кого-то волнует тема.
Смотрим иногда на kopf. Кажется перспективным, да и код выглядит красиво. Все никак руки не дойдут попробовать :)
Более серьёзные операторы сейчас, все же, стараемся писать на Go.