Про бэкап невозможно ответить кратко. Но тем не менее. Сейчас borgbackup в отдельном контейнере или поде. Мечтаем сделать operator или admission controller, который будет делать бекап borgbackup'ом согласно аннотациям в pod'ах.
На Highload за 2 дня у меня спросили раз 40. Было два вида вопросов — почему мы (Флант) считаем, что базу стоит ставить в контейнер/kubernetes (это же опасно!!!) и почему мы считаем, что базу НЕ стоит ставить в контейнер/kubernetes (это же удобно). Это означает, что мы всех запутали. Чтобы распутать — наверное напишем отдельный пост на хабре. Но отвечу кратко:
Все базы кроме прода — решительно да!
Прод — зависит от:
Если ваш сетевой сторедж позволяет переваривать ваш объем данных и количество IOPS'ов, и вы в нем уверены, — да,
Если это slave (который сам может bootstrap'аться с master) — да,
Если ваша база это горизонтально масштабирующийся мультимастер (cassandra, mongo, galera, etc), и вы не боитесь — может быть да,
Если… (и тут я понял, что все таки надо это систематизировать и писать статью).
Итог — мы рекомендуем загонять в Kubernetes все НЕ продовые базы, но пока мы не можем рекомендовать это делать во всех в проде. Думаем, что через 1-4 месяца ситуация может измениться (со стабилизацией local storage).
Жаль не срослось у нас с вами, когда общались насчёт проекта с прошлой работы — наше руководство не хотело платить за обслуживание, только за внедрение по какой-то разумной часовой ставке специалиста, а обслуживать и развивать дальше своими силами. Одной из причин сменить работу это стало.
Тут нам есть над чем поработать. С 2008-го года мы продавали, фактически, одну единственную услугу — это полное обслуживание инфраструктуры "под ключ". Не всем компаниям это подходит. Мы прямо сейчас запускаем другой вид услуг — именно консалтинг плюс внедрение. Такой формат гораздо лучше подходит компаниям, у которых уже есть своя сильная команда эксплуатации и им нужно просто быстрей получить опыт. Второй момент — сейчас все очень быстро меняется. Новая версия Kubernetes выходит раз в 3 месяц и с выходом каждой версии появляются возможности, меняются best practice, за этим нужно постоянно следить и переделывать. А кроме новой версии, и у нас и у всего DevOps комьюнити появляется опыт и экспертиза, как более эфеективно решать какие-то вопросы. Мы каждую неделю находим что-то и переделываем сейчас во всех проектах. Вот кроме услуги "консалтинг + внедрение" думаем продавать некоторую "подписку" (там будут текующие best practice, чеклисты по обновлению, проверенные нами helm и пр., а так же возможность задавать нам вопросы).
есть динамическое создание неймспейсов (стэков в терминах swarm) при появлении ветки в git и удаление при удалении или таймауту, с автоматическим же созданием DNS-имён для каждого сервиса в каждой ветке?
локальное разворачивание всего проекта или отдельных контейнеров (минимум двух — клиента и сервера, с привязкой к остальным к какому-нибудь контуру на сервере) на машинах у разработчиков с отражением правок на хосте сразу в контейнере без билда
Пока что можно только развернуть полную-полную копию локально в minikube. Такой вариант слабо подходит для проектов с микросервисной архитектурой, но вполне приемлем для других.
Основная сложность по моему опыту — конфигурирование приложения, передача ему значений конфигов в зависимости от окружения, которые нельзя просто поместить в репозиторий или аргументом занести в контейнер при билде. В идеале приложение должно быть спсобно все динамические параметры принимать через env переменные или же оркестратор должен генерировать конфиги и пробрасывать в контейнеры в нужном приложению формате.
На самом деле это не является блокером, есть вполне жизнеспособный workaround. Если переделывать конфигурацию приложения на ENV нет времени, можно без проблем сделать простейший shell-скрипт, который при запуске приложения сгенерит ему конфиг (из переменных окружения).
Нет. Классического полнотекстового поиска (токенизация, стемминг, индекс по словам) в ClickHouse, на сколько мне известно, нет. Однако ClickHouse позволяет прогнать данные через простую регулярку, и он может это сделать ооочень быстро. Поиск регуляркой среди 7 млрд записей занимает 6 ядер (12 тредов) на десяток секунд, а если локализовать (указать диапазон времени в несколько часов) — несколько сотен миллисекунд. Соответственно для логов самый раз — индексировать для настоящего полнотекстового поиска очень дорого (это куча места и вычислительных ресурсов, да и большие сложности с ротацией), запросов на запись несоизмеримо больше запросов на чтение (поэтому лучше съесть иногда чуть больше ресурсов на поиск, нежели постоянно на индексацию). Как-то так.
Привет, разработчик Tabix. Мы не просто слышали, а ставим вместе с loghouse везде Tabix, чтобы можно было посчитать что-то сложное. Типа, сколько в среднем таких-то сообщений в час с распределением по pod'ам. Ну или коды ответа HTTP, или сколько уникальных пользователей. Большое спасибо вам за Tabix!!
Что касается react/angular — ничего в этом не понимаю, но нам нужно быть максимально совместимыми со стеком Kubernetes. В перспективе хочется сделать бекенд плагином к api-серверу kubernetes, консольный интерфейс плагином к kubectl, а gui плагином к kuberentes dashboard. Последний, кстати, на angular и go — так что мы должны быть на них же, чтобы было проще получить поддержку сообщества kubernetes.
Что касается уведомлений — думали об этом, обязательно будет, но по срокам пока совсем нет никакого понимания. Во многом это сейчас зависит от спроса. Если мы не ошиблись и с проблемами простого и удобного логирования сталкиваемся не только мы, и если loghouse пойдет в массы, думаю можно ждать эту фичу весной.
Что касается авторотации за определенный период — пока нет, но это будет буквально на днях. Можете начинать использовать, а обещаем выкатить новую версию с ротацией до того, как у вас закончится место. В структуре данных все возможности для ротации заложены (есть партиционирование по дням, можно выбрать партиционирование по меньшему периоду). Для начала будет две настройки — сколько дней хранить и какой максимальный размер занимаемого места на диске. Можно будет указывать любую или обе одновременно. Отпишем тут, когда будет готово.
Слишком кратко сказал и был неверно понят. Сценарий "ClickHouse на каждой ноде" означает, что он стоит на каждой ноде Kubernetes. И fluentd читает данные из /var/log/containers и пишет в локально расположенный на этой же машине ClickHouse. Запросы делаются к распределенной таблице, которая собирает данные со всех инстансов. Бонус такого сценария — снижение нагрузки на сеть (практически до нуля) и возможность использовать дешевые локальные диски (которые часто есть в bare metal, но обычно нет в cloud). Если вероятность выхода из строя железки не высокая и логи можно терять в такой (редкой) ситуации, то этот сценарий позволяет сильно сэкономить. И по моему мнению он может быть особенно удобен для небольших кластеров на 3-7 железках, где еще не настал момент выделять отдельные ноды под логирование.
Почему я считаю, что такой сценарий не подходит для aws? Очень просто. Облака есть динамичность. Автоскейлинг. Например, у нас во всех кластерах Kubernetes в aws сейчас работает автоскейлер — днем кластер подростает, ночью сдувается. Если ставить ClickHouse на каждый узел, то при даунскейлинге надо будет пересохранять куда-то данные с этого узла. И в этом случае проще и удобней сделать отдельную (автоскейлинг) группу для кластера ClickHouse.
Но непонятна связка: kubernetes — локальный файлики. "Нода" на которой хранятся файлы это kubernetes node? Получается, что если мой компонент, который сошёл с ума забивает диск на ноде, то все остальные kubernetes pod перестают писать туда логи?
Да, все так. Это штатное поведение Kubernetes, и оно никак не относится к loghouse. Kubernetes штатно кладет лог контейнера всегда в файл в /var/log/containers (подробнее об этом тут). В Kubernetes сейчас это никак не изолировано. Наше решение занимается другой задачей — собирает логи всех контейнеров в одном месте, чтобы можно было удобно централизованно искать.
Еще непонятно что будет если pod будет перемещён на другой node. Согласно документации файлик будет удален. Это правда? Логи все таки можно будет потерять? Или у вас используется PVC для этого?
Под не может быть перемещен на другой узел в Kubernetes. Может быть удален старый под и создан новый. Логи контейнеров удаленных подов хранятся некоторое время до того, как быть удаленными.
Конечно так и сделаем. Планируем три основных архитектуры: standalone clickhouse (быстро и просто), clickhouse на каждой ноде (логи индексируются в локальный инстанс, подходит только для bare metal, где ноды статичны) и clickhouse cluster. Просто не все сразу.
Даже не думали об этом. Это совершенно другое решение. В grafana его пихать смысла нет совсем. Мы делаем OpenSource клон http://papertrailapp.com/ для Kubernetes.
Как не обработает? Обработает! ClickHouse такое может даже на одном узле (правда на совсем простых данных). Цитирую:
We recommend inserting data in packets of at least 1000 rows, or no more than a single request per second. When inserting to a MergeTree table from a tab-separated dump, the insertion speed will be from 50 to 200 MB/s. If the inserted rows are around 1 Kb in size, the speed will be from 50,000 to 200,000 rows per second. If the rows are small, the performance will be higher in rows per second (on Yandex Banner System data -> 500,000 rows per second, on Graphite data -> 1,000,000 rows per second). To improve performance, you can make multiple INSERT queries in parallel, and performance will increase linearly.
fluentd + ELK/Graylog — ну так основная проблема в ELK и Graylog это ELK. Точнее сам Elastic. Мы долго и упорно пытались на разных проектах использовать Elastic, но с ним постоянные проблемы в эксплуатации (разваливающийся кластер при любом чихе) и он употребляет не меренно ресурсов. Бонус ClickHouse в том, что он практически не использует ресурсов. Разница с Elastic где-то на порядок. По сути, ClickHouse при записи создает такую же нагрузку, как простой gzip без параметров.
Потому что это рисователь графиков, а не утилита для мониторинга логов. Однако, у нас стоит в средне-дальнем беклоге план по grafana (и в частности по этому плагину), чтобы можно было делать визуализации по логам.
Да, конечно поддерживает обратное давление! Это штатный функционал fluentd, который на данный момент используется как коллектор.
Поток данных выглядит следующим образом:
приложения пишут логи в stdout (12 factor, принято в kubernetes),
kubernetes (и docker) все это складывают в файлики локально на каждой ноде, и на этом их ответственность заканчивается,
fluentd запущеный на каждом узле читает файл и шлет данные каждую секунду в ClickHouse.
Соответственно, в описаном вами кейсе, скорей всего раньше ляжет нода, на которое такое приложение (забьется место на диске, там логи не жатые), чем ClickHouse в котором есть сжатие. Но в любом случае, если ClickHouse ляжет по любой причине — логи будут ждать локально, до тех пор пока он не вернется.
Про бэкап невозможно ответить кратко. Но тем не менее. Сейчас borgbackup в отдельном контейнере или поде. Мечтаем сделать operator или admission controller, который будет делать бекап borgbackup'ом согласно аннотациям в pod'ах.
Простите. Хочется аж прямо минуснуть свой же комментарий.
На Highload за 2 дня у меня спросили раз 40. Было два вида вопросов — почему мы (Флант) считаем, что базу стоит ставить в контейнер/kubernetes (это же опасно!!!) и почему мы считаем, что базу НЕ стоит ставить в контейнер/kubernetes (это же удобно). Это означает, что мы всех запутали. Чтобы распутать — наверное напишем отдельный пост на хабре. Но отвечу кратко:
Итог — мы рекомендуем загонять в Kubernetes все НЕ продовые базы, но пока мы не можем рекомендовать это делать во всех в проде. Думаем, что через 1-4 месяца ситуация может измениться (со стабилизацией local storage).
VolCh, спасибо за вопрос!
Тут нам есть над чем поработать. С 2008-го года мы продавали, фактически, одну единственную услугу — это полное обслуживание инфраструктуры "под ключ". Не всем компаниям это подходит. Мы прямо сейчас запускаем другой вид услуг — именно консалтинг плюс внедрение. Такой формат гораздо лучше подходит компаниям, у которых уже есть своя сильная команда эксплуатации и им нужно просто быстрей получить опыт. Второй момент — сейчас все очень быстро меняется. Новая версия Kubernetes выходит раз в 3 месяц и с выходом каждой версии появляются возможности, меняются best practice, за этим нужно постоянно следить и переделывать. А кроме новой версии, и у нас и у всего DevOps комьюнити появляется опыт и экспертиза, как более эфеективно решать какие-то вопросы. Мы каждую неделю находим что-то и переделываем сейчас во всех проектах. Вот кроме услуги "консалтинг + внедрение" думаем продавать некоторую "подписку" (там будут текующие best practice, чеклисты по обновлению, проверенные нами helm и пр., а так же возможность задавать нам вопросы).
Да. Достаточно подробно рассказывал об этом позавчера на Highload: http://www.highload.ru/2017/abstracts/3073. Видео будет через некоторое время.
Пока что можно только развернуть полную-полную копию локально в minikube. Такой вариант слабо подходит для проектов с микросервисной архитектурой, но вполне приемлем для других.
На самом деле это не является блокером, есть вполне жизнеспособный workaround. Если переделывать конфигурацию приложения на ENV нет времени, можно без проблем сделать простейший shell-скрипт, который при запуске приложения сгенерит ему конфиг (из переменных окружения).
https://github.com/flant/loghouse/issues/17
Огромное спасибо за фидбек. Выглядит так, как буд-то вы правы по каждому пункту. Будем благодарны за pull-request или сделаем сами чуть позже.
Нет. Классического полнотекстового поиска (токенизация, стемминг, индекс по словам) в ClickHouse, на сколько мне известно, нет. Однако ClickHouse позволяет прогнать данные через простую регулярку, и он может это сделать ооочень быстро. Поиск регуляркой среди 7 млрд записей занимает 6 ядер (12 тредов) на десяток секунд, а если локализовать (указать диапазон времени в несколько часов) — несколько сотен миллисекунд. Соответственно для логов самый раз — индексировать для настоящего полнотекстового поиска очень дорого (это куча места и вычислительных ресурсов, да и большие сложности с ротацией), запросов на запись несоизмеримо больше запросов на чтение (поэтому лучше съесть иногда чуть больше ресурсов на поиск, нежели постоянно на индексацию). Как-то так.
Привет, разработчик Tabix. Мы не просто слышали, а ставим вместе с loghouse везде Tabix, чтобы можно было посчитать что-то сложное. Типа, сколько в среднем таких-то сообщений в час с распределением по pod'ам. Ну или коды ответа HTTP, или сколько уникальных пользователей. Большое спасибо вам за Tabix!!
Что касается react/angular — ничего в этом не понимаю, но нам нужно быть максимально совместимыми со стеком Kubernetes. В перспективе хочется сделать бекенд плагином к api-серверу kubernetes, консольный интерфейс плагином к kubectl, а gui плагином к kuberentes dashboard. Последний, кстати, на angular и go — так что мы должны быть на них же, чтобы было проще получить поддержку сообщества kubernetes.
На практике у нас таких проблем не было. Ответ искать где-то здесь: https://docs.docker.com/engine/admin/logging/overview/. Вот даже тут: https://docs.docker.com/engine/admin/logging/json-file/. Там всякие max-size, max-file и решает вопрос с размером штатно. А вот по интенсивности — мне не известно.
Спасибо за вопросы!
Что касается уведомлений — думали об этом, обязательно будет, но по срокам пока совсем нет никакого понимания. Во многом это сейчас зависит от спроса. Если мы не ошиблись и с проблемами простого и удобного логирования сталкиваемся не только мы, и если loghouse пойдет в массы, думаю можно ждать эту фичу весной.
Что касается авторотации за определенный период — пока нет, но это будет буквально на днях. Можете начинать использовать, а обещаем выкатить новую версию с ротацией до того, как у вас закончится место. В структуре данных все возможности для ротации заложены (есть партиционирование по дням, можно выбрать партиционирование по меньшему периоду). Для начала будет две настройки — сколько дней хранить и какой максимальный размер занимаемого места на диске. Можно будет указывать любую или обе одновременно. Отпишем тут, когда будет готово.
Слишком кратко сказал и был неверно понят. Сценарий "ClickHouse на каждой ноде" означает, что он стоит на каждой ноде Kubernetes. И fluentd читает данные из /var/log/containers и пишет в локально расположенный на этой же машине ClickHouse. Запросы делаются к распределенной таблице, которая собирает данные со всех инстансов. Бонус такого сценария — снижение нагрузки на сеть (практически до нуля) и возможность использовать дешевые локальные диски (которые часто есть в bare metal, но обычно нет в cloud). Если вероятность выхода из строя железки не высокая и логи можно терять в такой (редкой) ситуации, то этот сценарий позволяет сильно сэкономить. И по моему мнению он может быть особенно удобен для небольших кластеров на 3-7 железках, где еще не настал момент выделять отдельные ноды под логирование.
Почему я считаю, что такой сценарий не подходит для aws? Очень просто. Облака есть динамичность. Автоскейлинг. Например, у нас во всех кластерах Kubernetes в aws сейчас работает автоскейлер — днем кластер подростает, ночью сдувается. Если ставить ClickHouse на каждый узел, то при даунскейлинге надо будет пересохранять куда-то данные с этого узла. И в этом случае проще и удобней сделать отдельную (автоскейлинг) группу для кластера ClickHouse.
Да, все так. Это штатное поведение Kubernetes, и оно никак не относится к loghouse. Kubernetes штатно кладет лог контейнера всегда в файл в /var/log/containers (подробнее об этом тут). В Kubernetes сейчас это никак не изолировано. Наше решение занимается другой задачей — собирает логи всех контейнеров в одном месте, чтобы можно было удобно централизованно искать.
Под не может быть перемещен на другой узел в Kubernetes. Может быть удален старый под и создан новый. Логи контейнеров удаленных подов хранятся некоторое время до того, как быть удаленными.
Конечно так и сделаем. Планируем три основных архитектуры: standalone clickhouse (быстро и просто), clickhouse на каждой ноде (логи индексируются в локальный инстанс, подходит только для bare metal, где ноды статичны) и clickhouse cluster. Просто не все сразу.
Даже не думали об этом. Это совершенно другое решение. В grafana его пихать смысла нет совсем. Мы делаем OpenSource клон http://papertrailapp.com/ для Kubernetes.
Я бы ответил кратко — для быстрого прототипирования. До конца года перепишем на Go.
Как не обработает? Обработает! ClickHouse такое может даже на одном узле (правда на совсем простых данных). Цитирую:
fluentd + ELK/Graylog — ну так основная проблема в ELK и Graylog это ELK. Точнее сам Elastic. Мы долго и упорно пытались на разных проектах использовать Elastic, но с ним постоянные проблемы в эксплуатации (разваливающийся кластер при любом чихе) и он употребляет не меренно ресурсов. Бонус ClickHouse в том, что он практически не использует ресурсов. Разница с Elastic где-то на порядок. По сути, ClickHouse при записи создает такую же нагрузку, как простой gzip без параметров.
Потому что это рисователь графиков, а не утилита для мониторинга логов. Однако, у нас стоит в средне-дальнем беклоге план по grafana (и в частности по этому плагину), чтобы можно было делать визуализации по логам.
Да, конечно поддерживает обратное давление! Это штатный функционал fluentd, который на данный момент используется как коллектор.
Поток данных выглядит следующим образом:
Соответственно, в описаном вами кейсе, скорей всего раньше ляжет нода, на которое такое приложение (забьется место на диске, там логи не жатые), чем ClickHouse в котором есть сжатие. Но в любом случае, если ClickHouse ляжет по любой причине — логи будут ждать локально, до тех пор пока он не вернется.
Версия kubernetes?