Посмотрел сейчас по гиту - активно в репозиторий с Terraform контрбьютит примерно 30 человек, не считая DevOps-команду (так как обычно это все-таки заботит в основном бэкенд-разработчиков, то фронтендеры изредка что-то добавляют, что им нужно — например, S3-бакеты). В модули же контрибьютят только DevOps-инженеры, просто из-за изначальной идеи, что модули и их удобство - ответственность инфраструктурной команды, а создание компонентов - ответственность разработчиков.
А по поводу сроков ситуация следующая — отвечу подробнее. Мне чуть проще оценить именно сколько занимал раньше и занимает сейчас полноценный деплой проекта в прод. Раньше, когда еще даже мы не централизовали создание всех ресурсов в Terraform, выкатка могла занимать хоть целый рабочий день — когда ты забываешь, что тебе надо определенные настройки в базе провернуть, особенным образом настроить очереди в реббите (например, добавив HA и зеркалирование) — время растягивается. И на самом деле первая задача, которую мы очень хотели решить — это именно создавать все ресурсы сразу "правильно" со всеми нужными настройками и правилами, поэтому и начали появляться модули. Сейчас же, процесс выкатки до прода (при условии, что все регламентные вопросы решены) может варьироваться от нескольких минут до пары часов. Так как у нас (как я описал в статье) присутствует обязательный процесс ревью и апрува от девопсов — выкатка начинает зависеть от свободности инженеров сейчас и вот время реакции на несрочные MR в репозиторий с инфрой - около часа. Но естественно если нужно срочно — это все может эскалироваться и ускоряться, поэтому такая вариативность.
Касаемо целевого интерфейса — пока у нас нет планов по превращению это в UI интерфейс, хотя внутри конечно есть понимание, что возможно это привлечет еще больше пользователей. Есть небольшое "трение" естественно, особенно для людей впервые видящих HCL-коды, поэтому пока цель - максимально упрощать сами модули и делая какие-то еще более удобные интеграции. Например, под типовые проекты Спецотдела есть план сделать модуль "спецпроекта", где бы сразу настраивались все компоненты, от которых обычно он зависит, не редактируя инфраструктуру в разных местах.
Чат-бот же у нас в DevOps пока только один - по созданию обращений в отдел (для их централизации и быстрого пинга дежурных). Были конечно мысли туда завернуть создание ресурсов, но это получается какая-то автоматика над автоматикой — пока в общем тоже неактуально, но всегда думаем, смотрим, где можно что-то пооптимизировать еще.
Обычно окружения поднимаются на домене, содержащим название ветки в git. То есть не произвольный коммит поднимается в качестве стенда, а именно ветка, либо тег.
Нет, чтобы разработчик разбирался не только в том как приложение написано, а еще в том, как это приложение запускать в реальном мире и совместно с DevOps командой принимать те или иные решения.
Это так же, как в victoria metrics можно писать метриками инфлюкса или statsd. То есть ставим любимый инструмент, например, Victoria Metrics или Grafana Mimir и пишем в него разными способами (системы порой бывают разнородные, поэтому приятно иметь возможность интегрировать существующую инфру с новым инструментом мониторинга)
Действительно, после глубокого изучения признаю, что тут была отражена не совсем корректная информация. В самом деле, компактор не занимается дедупликацией данных в S3. Этим занимаются сами инджестеры с использованием кешей (https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/#write-deduplication-disabled).
Судя по всему данные действительно пишутся в нескольких копиях в S3 и дедуплицириуются уже только на квериерах - ссылка1 и ссылка2, сравнивая таймстемпы и тексты логов.
В статью также внес изменения. Еще раз спсаибо за замечание!
P.S. Прошу прощения, что только сейчас отвечаю — пропустил изначально.
Loki поддерживает 2 вида ретеншена - через table manager и через компактор. Ретеншн через table manager полагается на lifecycle policy в S3. Поэтому это обязательно (но при условии что включен непосресдтвенно ретеншн через table_manager). Это нужно для того, чтобы правильно очищались индексы. Иначе Loki может считать что чанки есть (потому что индекс на них ссылается), а по факту их нет - и может выливаться в ошибки при запросах.
Более гибким является настройка ретеншена через компактор - она так же позволяет настраивать его для отдельных тенантов. При этом выставлять в таком случае какие-либо полиси в бакете лучше не стоит - точно так же - чревато потерей данных. Поэтому, если честно, я не вижу причин не использовать ретеншн через компактор.
Резюмируя, настраивать ретеншн нужно через один из двух механизмов - table manager или compactor. При этом для первого нужны lifecycle policy в S3 бакете. Полиси без настройки ретеншена могут привести к ошибкам в запросах.
Получается нужно все равно вешать лейблы на неймспейсы? Это нас как раз не устраивало в том же kubed - хотелось просто описать регулярку, под которую должны попадать нс-ы, чтоб сикрет в них прилетал.
Не рассматривали, спасибо за ссылку. Правда не до конца понимаю, как с помощью kyverno в данном случае решить наш сценарий - чтобы Secret копировался только в нужные неймспейсы, а не во все?
Да, я согласен, что в kubed есть возможность синхронизировать secret или configmap по всем неймспейсам сразу. Но это не подходит для нас. Для нас важно было копировать TLS-сертификат между неймспейсами "текущего" проекта. То есть, например, есть проект A и он раскладывается по веткам на домены main.projectA.example.com, feature-1.projectA.example.com, feature-2.projectA.example.com и т.д. Сертификат для *.projectA.example.com должен быть выпущен в единственном экземпляре (мы условились что будем это делать для ветки main) и в остальные фича-бранчи сертификат должен быть скопирован. А каждая фича-бранч раскладывается в отдельном неймспейса, поэтому нужно уметь указать в какие нс копировать. Ну и нам этот сертификат не нужен, например в неймспейсах для проекта B. Поэтому в общем единственный возможный сценарий использования kubed - это прослатвлять лейблы на нс, а это затруднительно для нас было.
Спасибо за ссылку!
Согласен, пока просто такого сценария у нас не возникало, но добавить можно, спасибо.
Все же GIL мешает запускать потоки из питона. Понятно, что всегда можно всегда на си запустить тред, но во-первых это просто сложнее, во-вторых все равно нет возможности иметь доступ к питонячьим объектам - чтобы к ним обратиться нужно захватить GIL. Отсутствие GIL решает эти проблемы. Да, напишем числодробилку на чем-то производительнее (C, Cython, что угодно), но использовать это будет сильно проще.
Возможность скейлиться по ядрам - самое главное. Условно запустить веб-сервер, который будет использовать все мощности сервера, а не довольствоваться однопоточным asyncio. Сейчас для эмуляции подобного нужно запускать несколько реплик приложения и балансировать между ними. При этом очевидные минусы - это то, что у нас раздельная память у процессов, доп проксирование и т.д.
Также отсутствие GIL позволит не бояться cpu-intensive задач, то есть можно будет просто создать в питоне прям поток, подробить числа в фоне. Сейчас единственный выход - это multiprocessing со своими очевидными минусами.
На мой взгляд нет ничего страшного в деплое баз данных в Kubernetes. Если понимать, что ты делаешь и делать все аккуратно - проблем, сильно отличающих деплой БД в кубе или нет, не будет. Да, с кубом связан несколько иной процесс выкаток, что нужно перезапускать процессы, это может негативно сказываться на например in-memory кэши БД или если вся база данных in memory - понадобится время, чтобы поднять все обратно в память. В остальном, при наличии хорошего инструментария деплой в кубе наоборот позволяет унифицировать процесс выкаток приложений, особенно если их очень много.
Да, в разделе про недостатки деплоя это имелось в виду, дописал явно про StatefulSet, спасибо.
Хотелось бы услышать ваше мнение более развернуто, почему не годится и почему init контейнер лучше? Если деплоится несколько реплик приложения, то в каждом из них запустится процесс миграций, и оно может начать конфликтовать, плюс чисто логически - зачем запускать одно и тоже действие в параллель несколько раз? Выше правильно написали, что миграции должны быть не ломающими, поэтому если будет фоновая задача которая приведет постепенно схему базы в нужное состояние, наоборот будет лучше, чем выкатка пода заблокируется полностью из-за накатки миграций. Но опять же, может что-то упускаю.
Не совсем, metallb лишь выдаст доступный ip-адрес из пула, узел, которого должен привлекать трафик в кластер. Уже логика на этом узле должна как-то запроксировать трафик к нужным подам.
Как написал выше, что зачастую кластера находятся во внутренней сети и просто так трафик не пропустить в кластер. Хочется еще отметить, что в вашем предложении с DaemonSet+hostnetwork есть проблема - а как в итоге клиенту выбрать на какой узел попасть? Помещать в dns все узлы кластера плохой путь - при добавлении/удалении узла из кластера нужно вносить изменения в dns, а они распространяются не моментально. Поэтому желательно иметь какую-то одну точку входа, желательно отказоустойчивую. С подходом внешнего ингресс контроллера можно как избежать лишних проксирований, так и запустить несколько балансировщиков в HA режиме, например с помощью keepalived.
Согласен, про то, что удобно скрыть реализацию и подменять в будущем, спасибо)
Хороший вопрос, спасибо!
Посмотрел сейчас по гиту - активно в репозиторий с Terraform контрбьютит примерно 30 человек, не считая DevOps-команду (так как обычно это все-таки заботит в основном бэкенд-разработчиков, то фронтендеры изредка что-то добавляют, что им нужно — например, S3-бакеты). В модули же контрибьютят только DevOps-инженеры, просто из-за изначальной идеи, что модули и их удобство - ответственность инфраструктурной команды, а создание компонентов - ответственность разработчиков.
А по поводу сроков ситуация следующая — отвечу подробнее. Мне чуть проще оценить именно сколько занимал раньше и занимает сейчас полноценный деплой проекта в прод. Раньше, когда еще даже мы не централизовали создание всех ресурсов в Terraform, выкатка могла занимать хоть целый рабочий день — когда ты забываешь, что тебе надо определенные настройки в базе провернуть, особенным образом настроить очереди в реббите (например, добавив HA и зеркалирование) — время растягивается.
И на самом деле первая задача, которую мы очень хотели решить — это именно создавать все ресурсы сразу "правильно" со всеми нужными настройками и правилами, поэтому и начали появляться модули.
Сейчас же, процесс выкатки до прода (при условии, что все регламентные вопросы решены) может варьироваться от нескольких минут до пары часов. Так как у нас (как я описал в статье) присутствует обязательный процесс ревью и апрува от девопсов — выкатка начинает зависеть от свободности инженеров сейчас и вот время реакции на несрочные MR в репозиторий с инфрой - около часа. Но естественно если нужно срочно — это все может эскалироваться и ускоряться, поэтому такая вариативность.
Касаемо целевого интерфейса — пока у нас нет планов по превращению это в UI интерфейс, хотя внутри конечно есть понимание, что возможно это привлечет еще больше пользователей. Есть небольшое "трение" естественно, особенно для людей впервые видящих HCL-коды, поэтому пока цель - максимально упрощать сами модули и делая какие-то еще более удобные интеграции. Например, под типовые проекты Спецотдела есть план сделать модуль "спецпроекта", где бы сразу настраивались все компоненты, от которых обычно он зависит, не редактируя инфраструктуру в разных местах.
Чат-бот же у нас в DevOps пока только один - по созданию обращений в отдел (для их централизации и быстрого пинга дежурных). Были конечно мысли туда завернуть создание ресурсов, но это получается какая-то автоматика над автоматикой — пока в общем тоже неактуально, но всегда думаем, смотрим, где можно что-то пооптимизировать еще.
Обычно окружения поднимаются на домене, содержащим название ветки в git. То есть не произвольный коммит поднимается в качестве стенда, а именно ветка, либо тег.
Нет, чтобы разработчик разбирался не только в том как приложение написано, а еще в том, как это приложение запускать в реальном мире и совместно с DevOps командой принимать те или иные решения.
Это так же, как в victoria metrics можно писать метриками инфлюкса или statsd. То есть ставим любимый инструмент, например, Victoria Metrics или Grafana Mimir и пишем в него разными способами (системы порой бывают разнородные, поэтому приятно иметь возможность интегрировать существующую инфру с новым инструментом мониторинга)
Да, спасибо, поправил
Спасибо большое за ваш комментарий!
Действительно, после глубокого изучения признаю, что тут была отражена не совсем корректная информация. В самом деле, компактор не занимается дедупликацией данных в S3. Этим занимаются сами инджестеры с использованием кешей (https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/#write-deduplication-disabled).
Судя по всему данные действительно пишутся в нескольких копиях в S3 и дедуплицириуются уже только на квериерах - ссылка1 и ссылка2, сравнивая таймстемпы и тексты логов.
В статью также внес изменения. Еще раз спсаибо за замечание!
P.S. Прошу прощения, что только сейчас отвечаю — пропустил изначально.
Их можно форвардить напрямую в промтейл - https://grafana.com/docs/loki/latest/clients/promtail/configuration/#syslog, если я правильно понял вопрос.
Loki поддерживает 2 вида ретеншена - через table manager и через компактор. Ретеншн через table manager полагается на lifecycle policy в S3. Поэтому это обязательно (но при условии что включен непосресдтвенно ретеншн через table_manager). Это нужно для того, чтобы правильно очищались индексы. Иначе Loki может считать что чанки есть (потому что индекс на них ссылается), а по факту их нет - и может выливаться в ошибки при запросах.
Более гибким является настройка ретеншена через компактор - она так же позволяет настраивать его для отдельных тенантов. При этом выставлять в таком случае какие-либо полиси в бакете лучше не стоит - точно так же - чревато потерей данных. Поэтому, если честно, я не вижу причин не использовать ретеншн через компактор.
Резюмируя, настраивать ретеншн нужно через один из двух механизмов - table manager или compactor. При этом для первого нужны lifecycle policy в S3 бакете. Полиси без настройки ретеншена могут привести к ошибкам в запросах.
Здравствуйте! Для управления временем хранения логов отвечает компактор. Вот тут подробная документация на эту тему - https://grafana.com/docs/loki/latest/operations/storage/retention
Получается нужно все равно вешать лейблы на неймспейсы? Это нас как раз не устраивало в том же kubed - хотелось просто описать регулярку, под которую должны попадать нс-ы, чтоб сикрет в них прилетал.
Не рассматривали, спасибо за ссылку. Правда не до конца понимаю, как с помощью kyverno в данном случае решить наш сценарий - чтобы Secret копировался только в нужные неймспейсы, а не во все?
Так мы ведь и выписываем wildcard сертификаты. В статье описывается подход как скопировать выписанный сертификат между неймспейсами, где он нужен.
Можете пояснить вопрос? Где именно не подошел kustomize?
Да, я согласен, что в kubed есть возможность синхронизировать secret или configmap по всем неймспейсам сразу. Но это не подходит для нас. Для нас важно было копировать TLS-сертификат между неймспейсами "текущего" проекта. То есть, например, есть проект A и он раскладывается по веткам на домены main.projectA.example.com, feature-1.projectA.example.com, feature-2.projectA.example.com и т.д. Сертификат для *.projectA.example.com должен быть выпущен в единственном экземпляре (мы условились что будем это делать для ветки main) и в остальные фича-бранчи сертификат должен быть скопирован. А каждая фича-бранч раскладывается в отдельном неймспейса, поэтому нужно уметь указать в какие нс копировать. Ну и нам этот сертификат не нужен, например в неймспейсах для проекта B. Поэтому в общем единственный возможный сценарий использования kubed - это прослатвлять лейблы на нс, а это затруднительно для нас было.
Спасибо за ссылку!
Согласен, пока просто такого сценария у нас не возникало, но добавить можно, спасибо.
Все же GIL мешает запускать потоки из питона. Понятно, что всегда можно всегда на си запустить тред, но во-первых это просто сложнее, во-вторых все равно нет возможности иметь доступ к питонячьим объектам - чтобы к ним обратиться нужно захватить GIL. Отсутствие GIL решает эти проблемы. Да, напишем числодробилку на чем-то производительнее (C, Cython, что угодно), но использовать это будет сильно проще.
Возможность скейлиться по ядрам - самое главное. Условно запустить веб-сервер, который будет использовать все мощности сервера, а не довольствоваться однопоточным asyncio. Сейчас для эмуляции подобного нужно запускать несколько реплик приложения и балансировать между ними. При этом очевидные минусы - это то, что у нас раздельная память у процессов, доп проксирование и т.д.
Также отсутствие GIL позволит не бояться cpu-intensive задач, то есть можно будет просто создать в питоне прям поток, подробить числа в фоне. Сейчас единственный выход - это multiprocessing со своими очевидными минусами.
Спасибо за комментарий! Отвечу по пунктам
На мой взгляд нет ничего страшного в деплое баз данных в Kubernetes. Если понимать, что ты делаешь и делать все аккуратно - проблем, сильно отличающих деплой БД в кубе или нет, не будет. Да, с кубом связан несколько иной процесс выкаток, что нужно перезапускать процессы, это может негативно сказываться на например in-memory кэши БД или если вся база данных in memory - понадобится время, чтобы поднять все обратно в память. В остальном, при наличии хорошего инструментария деплой в кубе наоборот позволяет унифицировать процесс выкаток приложений, особенно если их очень много.
Да, в разделе про недостатки деплоя это имелось в виду, дописал явно про StatefulSet, спасибо.
Хотелось бы услышать ваше мнение более развернуто, почему не годится и почему init контейнер лучше? Если деплоится несколько реплик приложения, то в каждом из них запустится процесс миграций, и оно может начать конфликтовать, плюс чисто логически - зачем запускать одно и тоже действие в параллель несколько раз? Выше правильно написали, что миграции должны быть не ломающими, поэтому если будет фоновая задача которая приведет постепенно схему базы в нужное состояние, наоборот будет лучше, чем выкатка пода заблокируется полностью из-за накатки миграций. Но опять же, может что-то упускаю.
Не совсем, metallb лишь выдаст доступный ip-адрес из пула, узел, которого должен привлекать трафик в кластер. Уже логика на этом узле должна как-то запроксировать трафик к нужным подам.
Как написал выше, что зачастую кластера находятся во внутренней сети и просто так трафик не пропустить в кластер. Хочется еще отметить, что в вашем предложении с DaemonSet+hostnetwork есть проблема - а как в итоге клиенту выбрать на какой узел попасть? Помещать в dns все узлы кластера плохой путь - при добавлении/удалении узла из кластера нужно вносить изменения в dns, а они распространяются не моментально. Поэтому желательно иметь какую-то одну точку входа, желательно отказоустойчивую.
С подходом внешнего ингресс контроллера можно как избежать лишних проксирований, так и запустить несколько балансировщиков в HA режиме, например с помощью keepalived.