Посмею поправить Дениса, по поводу StatusBoard и попробовать ответить на ваши вопросы.
StatusBoard уже связан с нашей системой метрик и алертинга — Prometheus.
Когда мы создаём какое-нибудь событие в StatusBoard и указываем maintenance mode — он вешает silence(на конкретные лейблы метрик прометея, в зависимости от сервиса, на которое создано событие) на Prometheus AlertManager и нам не идут ложноположительные алерты.
Про откат:
Т.к. приложения в k8s собираются и деплоятся через CI/CD pipeline, то каждый MR, обычно, порождает создание отдельного Docker image, который хранится во внутреннем Docker Registry и может быть задеплоен в какой-нибудь из кластеров k8s. Все образы версионируются(именами тегов или SHA коммита).
При необходимости отката — можно просто запустить необходимую job'у из pipeline и она установит требуемую версию приложения в нужный кластер. Даже если образ уже удалён из Docker Registry — его всегда можно пересобрать и запушить/задеплоить вновь.
Как один из инженеров в команде Дениса — попробую ответить на вопрос.
У нас не было необходимости мигрировать все приложения сразу. Мы растянули этот процесс на несколько месяцев.
Миграцию приложений проводили сами разработчики приложений. Для них мы подготовили:
Несколько докладов внутри компании.
Документацию. Как, зачем, особенности инсталляции.
Базовый пример, на котором можно поиграться с Kubernetes и взять его за основу для деплоя приложения.
Утилиту для работы с манифестами и их деплоя в Kubernetes.
Нашу поддержку на пути переноса приложений :)
В целом, процесс прошел довольно хорошо. Если при переносе первого приложения в k8s вопросы ещё были, то дальше разработчики уже переносили всё сами, иногда присылая нам MR на ревью каких-то сложных моментов.
Нам оставалось только докидывать ресурсы в k8s namespace'ы команд, чтобы туда заезжали новые приложения.
PS Helm мы попробовали, но он не зашел легко и быстро. Особенно при работе с несколькими инсталляциями k8s(изначально сами пробовали деплоить DEIS через Helm, прежде чем рассказывать о нём внутри компании).
Собственная утилита для деплоя в k8s формирует финальные манифесты из jinja2 шаблонов манифестов и файла конфигурации. Выглядит легко и хорошо встраивается в наш CI/CD процесс.
Я, один из тех, кто заведует ELK инфраструктурой в нашей компании и постараюсь дать информацию по вашему вопросу.
Тестов на потерю GELF сообщений мы не проводили, но и с конкретной проблемой об отсутствии GELF сообщений, пользователи к нам не приходили. Хотя нам приходит порядка 4000 GELF сообщений в секунду.
Вообще — все сообщения, которые нам отправляют по UDP, могут потеряться. И полагаю, что это нормально, т.к. UDP.
Будем считать, что данная проблема обошла на стороной, т.к. ещё не было замечено её влияния на анализ происходящих у нас событий.
StatusBoard уже связан с нашей системой метрик и алертинга — Prometheus.
Когда мы создаём какое-нибудь событие в StatusBoard и указываем maintenance mode — он вешает silence(на конкретные лейблы метрик прометея, в зависимости от сервиса, на которое создано событие) на Prometheus AlertManager и нам не идут ложноположительные алерты.
Про откат:
Т.к. приложения в k8s собираются и деплоятся через CI/CD pipeline, то каждый MR, обычно, порождает создание отдельного Docker image, который хранится во внутреннем Docker Registry и может быть задеплоен в какой-нибудь из кластеров k8s. Все образы версионируются(именами тегов или SHA коммита).
При необходимости отката — можно просто запустить необходимую job'у из pipeline и она установит требуемую версию приложения в нужный кластер. Даже если образ уже удалён из Docker Registry — его всегда можно пересобрать и запушить/задеплоить вновь.
У нас не было необходимости мигрировать все приложения сразу. Мы растянули этот процесс на несколько месяцев.
Миграцию приложений проводили сами разработчики приложений. Для них мы подготовили:
В целом, процесс прошел довольно хорошо. Если при переносе первого приложения в k8s вопросы ещё были, то дальше разработчики уже переносили всё сами, иногда присылая нам MR на ревью каких-то сложных моментов.
Нам оставалось только докидывать ресурсы в k8s namespace'ы команд, чтобы туда заезжали новые приложения.
PS Helm мы попробовали, но он не зашел легко и быстро. Особенно при работе с несколькими инсталляциями k8s(изначально сами пробовали деплоить DEIS через Helm, прежде чем рассказывать о нём внутри компании).
Собственная утилита для деплоя в k8s формирует финальные манифесты из jinja2 шаблонов манифестов и файла конфигурации. Выглядит легко и хорошо встраивается в наш CI/CD процесс.
Я, один из тех, кто заведует ELK инфраструктурой в нашей компании и постараюсь дать информацию по вашему вопросу.
Тестов на потерю GELF сообщений мы не проводили, но и с конкретной проблемой об отсутствии GELF сообщений, пользователи к нам не приходили. Хотя нам приходит порядка 4000 GELF сообщений в секунду.
Вообще — все сообщения, которые нам отправляют по UDP, могут потеряться. И полагаю, что это нормально, т.к. UDP.
Будем считать, что данная проблема обошла на стороной, т.к. ещё не было замечено её влияния на анализ происходящих у нас событий.