• 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    0

    В данном случае – через NATS идет индексация в Elastic, если я ничего не путаю. Но вообще, мы исторически используем NATS как основную шину связи между нашими микросервисами, через которую летают все "общие" объекты. Но тут важный момент, что вся система "инцидент менеджмента" — для нас это только один микросервис, пусть и состоящий из многих компонентов (куча разных входящих API-шек, обработчики, воркеры разных сортов, интерфейсы разные — их, тоже можно было назвать микросервисами, но у нас они лежат в одном репе, катаются всегда вместе и версионируются вместе — так сильно удобней при нашем размере команды разработки), но есть и другие наши внутренние системы, с которыми связь по NATS'у. Например, эта система ("инцидент менеджмента") является первоисточником для всех инцидентов, и соответственно она валит информацию по инцидентам в NATS, а некоторые другие микросервисы подписываются на эту информацию (и могут держать у себя реплицированную копию данных). Благодаря этому функционалу, например, у нас в тикетах показываются статусы связанных инцидентов… но это долгая история и совсем не о том.

  • 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    0

    Логика обобщена и сведена всего к двум видам связей "группировка" и "причина", соответственно в любом алерте мы можем указывать любое количество аннотаций одного из четырех типов:


    • group_for – настоящий алерт является "папкой" (на самом деле оно граф, но не суть) для алерта, указанного в значении.
    • grouped_by – тоже самое, что предыдущее, только в обратную сторону.
    • cause_of – настоящий алерт является причиной для алерта, указанного в значении,
    • caused_by – тоже самое, что предыдущее, только в обратную сторону.

    Соответственно у алерта получается пачка аннотаций следующего вида (xxx и yyy – просто имена связей):


    annotations:
      cause_of/xxx: "TriggerName,label=val1,label2=val2"
      grouped_by/yyy: "AnotherTriggerName,label2=val4"

    Дальше уже из этих штук строится граф, а из графа пытаемся искать root-cause.


    Дальше вопрос, где эти аннотации лежат. Варианта два:


    1. Прямо сразу в самом алерте. Если это Prometheus – вполне работает. Соответственно сразу с алертом лежат известные в нем возможные связи.
    2. В системе мониторинга есть механизм входного ремаппинга. Мы указываем выражение на mql и дальше говорим, что всем алертам, подходящим под это выражение, проставить такие-то аннотации (там можно и много чего другого менять, но в том числе и вот это). Эти правила лежат в отдельном git'е в достаточно логичной структуре, разбитые по проектам. Вместе с ними же лежит и документация по проектам (см. выше).

    Дальше, соответственно, всем что можно лежит в алертах. Все что надо кастомное налепить – лежит в конкретном проекте.

  • 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    +2

    Там достаточно типовой стек и достаточно типовая, по современным меркам, архитектура. Более менее полно ответить на этот вопрос в одном сообщении – боюсь просто невозможно. Но я попробую...


    Сейчас там – Redis, MySQL, NATS, Elastic и пачка микросервисов на RoR. Redis используется для "горячих" очередей, в MySQL хранятся все данные, в том числе и архив. Elastic используется для поиска и аналитики. Все сделано специально максимально просто, но с возможностью upgrade, когда понадобится. Например, когда возникнет реальная потребность, Redis'ы достаточно просто заменяются на kafka – это решает и вопрос надежности и вопрос масштабируемости очередей, обработчики (как и все другие сервисы на RoR, они все stateless) у нас и так масштабируются (правда надо будет локализовать данные и кеш, но это детали). Архивные данные из MySQL очень просто убираются в Cassandra, а вот с горячими данными (по открытым-прямо-сейчас алертам и инцидентам), у нас есть завязка на транзакции в MySQL – и тут просто не получится, но мы знаем целую пачку абсолютно рабочих workaround'ов, в целом все сводится к тому, чтобы локализовать обработку некоторых событий по одному проекту в одном процессе, что позволит обойтись без потребности синхронизации и локов в БД, тогда Cassandra подойдет и для горячих данных.


    Все компоненты живу в Kubernetes, развернутом по железу в OVH. Statefull сервисы используют local storage (и, соответственно, прибиты гвоздями к нодам).

  • 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    +4

    Не знаю как ответить. Мне казалось, наоборот, что доклад достаточно хорошо получился. Понятно, что я рассказываю о нашей внутренней системе, которой нельзя просто так взять и воспользоваться, но я очень старался рассматривать именно проблемы и принципы решений, которые для нас заработали. Что не так то?

  • 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    +2
    1. А вы не делаете первичную диагностику по событиям, на которые должны реагировать дежурные? Ну, например, запускаете синтетическую проверку веб-интерфейса, смотрите хелс-чеки соседних сервисов, проверяете время отклика чего-нибудь, чтобы затем привязать эту информацию к событию, чтобы дежурный видел больше контекста.

    Мы знаем о двух возможных подходах к этому вопросу:


    1. В момент поступления алерта запустить какую-то автоматическую проверку. Грубо говоря, если сервис не отвечает, автоматом запустить tracerout с нескольких точек.
    2. Всегда запускать трейсроут и если он не проходит – слать алерт, но этот алерт делать с низким severity (грубо говоря, debug). Дальше остается в основном алерте удобно и наглядно показывать дебажные.

    Технически, у нас реализована поддержка обоих подходов.


    • В первом случае в JSON-алерт достаточно указать URL в специальной аннотации и он будет дернут и подтянут к инциденту при его поступлении. То есть если нужно сделать tracerout, то пишем на чем-то простейший сервис, которому GET-параметром передаем IP, а он возвращает трейс, и дальше ссылочки на эту штуку добавляем в алерты.
    • Второй кейс можно сделать по-простому, просто показывая в любом алерте соседние из проекта (и это у нас сделано давно), но по-хорошему показывать только действительно связанные. Для этого у нас совсем недавно была окончательно доделана поддержка "графов" – у алерта мы можем указать сколько угодно аннотаций caused_by, соответственно, если у нас горит два алерта, один о недоступности сервиса, второй о том что он трейсится (скорей, что не пингается, но не суть), то они автоматом объединятся в один инцидент.

    Пока что получается так, что мы первым способом практически не пользуемся. А второй способ, наоборот, используется все больше и больше.

  • 10 лет on-call. Чему мы научились? (обзор и видео доклада)
    +3
    1. Можете подробнее рассказать как у вас работает документации по событиям? Судя по скриншоту — это некий гитлаб. Правильно понял, что к каждому событию привязывается ссылка на гитлаб на основе лейбла или наборов лейблов события? Или дежурные сами выполняют поиск по гитлабу и ищут подходящий к событию документ?

    У нас есть "язык запросов" (mql) к системе, который позволяет искать инциденты по значениям их лейблов и аннотаций. В документации указывается mql и ко всем инцидентам, подходящим под запрос, добавляется документация.


    Чтобы было понятно, процитирую примеры из нашей внутренней доки по mql:


    • project = tfprod — инциденты по проекту tfprod.
    • project =~ foo and ~trigger='disk-usage' — инциденты по проектам foo* с триггером disk-usage.
    • (project = "foo" or project = 'bar') and trigger = 'cpu-usage' and ~server != gitlab-runner — инциденты проектов foo и bar с триггером cpu-usage, но исключая те, у которых сервер gitlab-runner.
      • Можно переписать через регулярное выражение: project =~ "(foo|bar)" and trigger = 'cpu-usage' and ~server != gitlab-runner
    • ~node = * — инциденты, у которых присутствует лейбл node (с любым значением).
    • issue = 222222 and team = b — инциденты по тикету 222222 в команде B.
    • user =~ Иванов — инциденты, назначенные (или предложенные к назначению при передаче) на пользователя с именем, фамилией или почтой, содержащей Иванов.
    • summary = "something bad happened" OR description =~ "wtf"
    • source = okmeter AND severity <= S3 — поиск инцидентов okmeter с уровнем severity меньше или равным 3 (найдётся S1, S2, S3).
    • @summary = 'hello' OR @ip = * — поиск инцидентов, у которых в хотя бы одном алерте summary равен hello или есть аннотация ip.
    • alerts_count >= 10 — поиск инцидентов с количеством алертов больше или равным 10.
  • Представляем werf 1.0 stable: при чём тут GitOps, статус и планы
    +1

    Я открыл главную и кажется понял, в чем проблема. У нас там большими буквами в самом верху написано "CLI tool to construct CI/CD pipelines". Это полный провал с нашей стороны. Должно быть так: "CLI tool to use in your CI/CD pipelines`".

  • Представляем werf 1.0 stable: при чём тут GitOps, статус и планы
    +2

    Привет.


    А поясни, плиз, при чем здесь "travis, circleci, gitlab ci до argocd и teckton pipelines"? У нас нет вообще ничего про CI часть и никогда не будет.


    Есть задача: "вот есть реп, нужно сделать, чтобы в кубе было тоже самое, что в репе". Привести kubernetes в состояние с git. Чтобы это сделать нужно, всего то, вызвать docker build, docker tag, docker push и helm install. В этом смысле – конечно, перекрывается. Ну а дальше много нюансов.


    Что касается tekton и, вцелом, интеграции с другими CI-системами. Сейчас у нас есть два пути – штатная поддержка gitlab ci и возможность использовать что угодно через переменные окружения, есть только важный момент, что мы сейчас ограничены работой на одном хосте (см. в статье выше). Прямо сейчас мы пилим поддержку Github Actions. Явная поддержка Tekton обязательно в планах, но несколько позже, пока ничего не могу сказать по срокам

  • Использование werf для выката комплексных Helm-чартов
    +4

    Спасибо за вопрос. Он возникает уже не первый раз, значит требует подробного ответа.


    Никак не относимся. Мы не пробовали ни Argo-CD ни Flux – хотя они и решают в целом ту же область задач, но они это делают по-другому, используя чуть другие подходы.


    • По Flux лучше всего цитировать их собственную доку:


      What Flux does

      Flux is most useful when used as a deployment tool at the end of a Continuous Delivery pipeline. Flux will make sure that your new container images and config changes are propagated to the cluster.

    • По ArgoCD – я могу ошибаться, но это в первую очередь конструктор пайплайнов.


    • Werf же старается не решать вопросы CI, предполагая, что есть некоторая внешняя CI-система (Gitlab CI, Jenkins, etc), в которой описаны пайплайны, и первичная задача в werf "синхронизировать" состояние Git c состоянием Kubernetes, а именно: собрать и пушнуть образы, применить манифесты для Kubernetes. Причем сделать это удобно и гарантировано.



    Почему так? Ну во-первых по историческим причинам. А во-вторых – у меня (как у "владельца продукта") есть следующий взгляд:


    1. Если вы используете Gitlab CI – у вас уже есть "Pipeline as a Code". Github запустил Github Actions, и когда станут доступны self-hosted runner'ы (они анонсированы, будут бесплатно) – получается, что в Github тоже появляется удобно сделанный "Pipeline as a Code". Что еще нужно кроме Gitlab и Github? Ну еще есть Bitbucket и пока что там все сильно хуже, но они подтянутся (или умрут) и этот вопрос тоже будет решен.
    2. Для по-настоящему эффективной работы функционал CI должен быть плотно проинтегрирован с SCM и с управлением задачами: должна быть двух сторонняя связь. В идеале – в задаче мы должны видеть конечный результат (выкаты связанных MR/PR, проходят ли тесты по ним и пр.). То есть это не простое автозакрытие задачи при принятии, а сквозная видимость в обе стороны (Issue <-> MR <-> Pipeline). Это означает, что CI фактически должен быть частью SCM/трекера. И именно так происходит в Gitlab и Github. То есть большая часть пользователей будет с удовольствием использовать или Gitlab или Github, которые будут решать все три задачи под ключ и надо ориентироваться именно на это. Плюс я думаю Atlassian подтянется и доделает свой стек, и там тоже будет 3-in-1.
    3. Мир сложный, и сколько людей – столько мнений. Мне очень нравится, в этом смысле, философия Unix, и, хотя werf это и интеграционная утилита (мы используем и helm и docker), мы все таки решаем одну основную задачу: "синхронизация Git c Kubernetes". Соответственно, если по каким-то причинам вам удобней Jenkins (у которого, кстати, Pipeline'ы тоже можно в SCM хранить, пусть и менее элегантно), или любую другую систему – да пожалуйста, werf это идеальный вариант для вас. Это просто консольная тула, которая синкает Git-комит с Kubernetes'ом. При чем оптимизированная для работы под управлением CI.

    Таким образом, да – werf, сам по себе, не реализовывает в полной мере GitOps. Но в сочетании с любой "Pipeline as a Code" тулой, связка в полной мере решает этот вопрос. И будучи простой консольной тулой werf дает гораздо большую гибкость. Мы на сайте написали: A missing part of a CI/CD system.


    Сейчас мы находимся на финишной прямой к выпуску 1.0 stable. Сразу после этого у нас есть Milestone, который мы называем "поддержка TOP10 CI-систем". В рамках этого Milestone мы хотим написать практические руководства о том, как правильно использовать werf под наиболее популярными CI системами (плюс сделать удобную поддержку, так же как это сейчас сделано для Gitlab). Мы посмотрим, возможно одной из этих систем будет Argo CD.

  • Kubernetes 1.15: обзор основных новшеств
    0

    aks-engine

  • Kubernetes 1.15: обзор основных новшеств
    +2

    В настоящий момент мы ставим на новые кластера 1.11 и обновляем все существующие тоже до 1.11. На глаз: примерно половина на 1.11 и вторая половина на 1.10 и 1.9. С одной стороны – все норм и все работает, поэтому не форсируем, с другой стороны – есть очень большая пачка расширенных фич, которые мы не можем использовать и это нас очень расстраивает (например, ipvs и kubelet dynamic config мы до сих пор не можем использовать, ну и куча еще всего).


    Однако, мы решили форсировать этот вопрос и прямо сейчас готовим обновление 1.11 -> 1.13 (за одну операцию через две версии, там есть нюансы, но в целом так можно), должны закончить на этой неделе. И на следующей будем делать обновление 1.13 -> 1.15. Под "делать обновление" в нашем случае подразумевается проработка на тестовых стендах и подготовка инструкций для наших DevOps-команд. Сейчас мы поддерживаем три способа инсталляции: kubeadm (bare metal и все виды простых VM), kops (AWS, GCE) и aks (Azure).


    В целом, буквально через несколько недель, планируем выйти на следующую политику:


    1. Не позднее чем через месяц после релиза мы должны:
      • ставить новые кластера уже на эту версию,
      • иметь возможность обновить любой из существующих кластеров на эту версию.
    2. Мы поддерживаем кластера не более чем трех последних версий (с выходом 1.15 это будут 1.12, 1.13 и 1.14) и если кластер старше – мы форсируем обновление (даже если фичи не нужны – все равно требуется обновление).

    Плюс, скорей всего придем к тому, что для нечетных версий будем готовить обновление через одну версию, чтобы там, где не нужны фичи можно было обновляться в два раза реже.

  • Базы данных и Kubernetes (обзор и видео доклада)
    0

    Пока нет.

  • Микросервисы: размер имеет значение, даже если у вас Kubernetes
    +1

    К сожалению мне нечего вам предложить. Мы никогда не выбирали между Kubernetes и чем-то другим. Зашел с первого взгляда, так сказать. Просто эволюционно шли шли и пришли.

  • Микросервисы: размер имеет значение, даже если у вас Kubernetes
    +2

    Это далеко не всегда так плохо, как вы описываете. По крайней мере "фантазеров" и "дойщиков" сразу видно и с ними все понятно. Очень часто я вижу и у архитекторов и у разработчиков большую и абсолютно искреннюю надежду, что микросервисная архитектура значительно упростит их жизнь, на практике же часто выходит боком. Об этом и пытался рассказать.

  • Микросервисы: размер имеет значение, даже если у вас Kubernetes
    0
    Но причем тут Kubernetes и микросервисы? Buzzwords anchors?

    Тут я вынужден просить прощения — доклад изначально планировался больше про эксплуатацию и про Kubernetes, как и обычно… а получился больше про архитектуру. Кажется я сказал об этом в начале. В любом случае прошу простить.

  • Микросервисы: размер имеет значение, даже если у вас Kubernetes
    +3

    И да и нет. И чем больше я общаюсь с людьми и получаю обратной связи по конкретно этому докладу — скорей нет, чем да. Если вам очевидно — вы молодец!

  • Микросервисы: размер имеет значение, даже если у вас Kubernetes
    +3

    Для нас Kubernetes — это просто один из инструментов. И очень мощный инструмент. И как и у любого мощного инструмента — у него достаточно высокий входной платеж. Нам, конечно же, удобней делать все проекты в Kubernetes, так-как именно для нас — так быстрей и удобней. Понятно, что в общем случае в первую очередь стоит исходить из возможностей команды и реальных потребностей проекта. Во многих может быть проще и правильней два хоста и docker-compose.

  • Kubernetes 1.12: обзор основных новшеств
    0

    Мы очень давно и активно используем local storage, но до сих пор руки не дошли до local volume provisioner'а.

  • Представляем новый плагин для Grafana — Statusmap panel
    +3

    Да! У нас тоже статусы многих разных вещей stacked bar'ами раньше показывались, и что мы только не делали, чтобы это хоть как-то наглядно выглядело, вот так и пришли к созданию этого плагина.

  • Kubernetes: жизнь пода
    +2
    в состоянии корректно обработать "kill -9"

    Дополню, на всякий случай. Речь идет совершенно не о том, что приложение обрабатывает SIGKILL ))). Речь о том, что при безусловном завершении всегда выполняется заявленный уровень гарантий: если это ACID — значит ACID, если что-то мягче — значит оно.

  • Kubernetes: жизнь пода
    +2

    На практике­ — я бы не стал полагаться на PreStop для mission critical задач, это не тот механизм. На практике:


    • В PreStop мы обычно делаем graceful shutdown, чтобы как можно более мягко приглушить под,
    • Но при этом, обязательно четко понимая, что любое важное действие в любом случае должно иметь некоторый механизм "retry".

    Всем очевидно, что если веб-приложение, которое при обработке HTTP запроса делает два запроса в базу (один на зачисление денег на один счет и второй на их списание с другого), не использует транзакции — у вас в любом случае будут серьезные проблемы. И никакими PreStop хуками эти проблемы не исправишь. Аналогично и со stateful приложением, если оно не в состоянии корректно обработать "kill -9", а требует мягкого выключения — с ним в любом случае будут большие проблемы. При этом это не означает, что нужно всегда mysql выключать по kill -9, конечно же — и вот именно для этого и нужны PreStop хуки.


    При этом зачастую сделать приложение с корректными "ретраями" совершенно не так сложно, как может сначала показаться. Современные веб фреймворки очень сильно в этом помогают. Соответственно даже если graceful shutdown не будет выполнен и приложение будет прибито жестко — ничего страшнее retry не происходит.

  • Kubernetes 1.11: обзор основных новшеств
    +2

    Нет. Ни IPVS, ни CoreDNS, ни containerd не принесут какой-то конкретной пользы в наших кейсах.


    Более того, мы несколько застряли на 1.8, но сделали это вполне осознанно — на практике, в 1.8 нас все более-менее устраивает, и мы сейчас уделяем большую часть внимания другим вопросам. Однако, так-как в 1.11 наконец-то появился online PV resizing, мы скорей всего обновимся до конца лета.


    Из связанного с 1.11, мы считаем, что не так важно какой DNS, как важно его правильно поставить — если на каждое подключение к redis у нас добавляется дополнительный латенси на DNS resolve, то это прямо беда (понятно, что надо делать постоянные соединения, но замените пример с redis на что-то другое). Мы думаем над схемой, когда основной DNS стоит на каждом узле (DaemonSet) плюс запасной стоит в Deployment'е — такая схема убирает сетевой латенси, сохраняя при этом отказоустойчивость. Сделать такой вариант в отдельно взятом кластере, особенно развернутом вручную, не составляет никакого труда, а вот чтобы сделать универсальное решение, работающее в динамически масштабируемых кластерах на любом клауде и на железе, нужна возможность централизованного управления конфигами kubelet, которая в 1.11 значительно продвинулась.

  • Мониторинг и Kubernetes (обзор и видео доклада)
    0

    Я тоже так раньше думал, но нет. Увидим!

  • Мониторинг и Kubernetes (обзор и видео доклада)
    0

    Большая часть показателей, которые экспортируются всеми системами — это "одометры" (тип counter), так что в целом эта проблема более-менее решена. Например, данные по CPU контейнера приходят как counter с количеством потраченных секунд. Соотвественно в основном Prometheus'е у нас данные за каждые 30 секунд, а в longterm за каждые 5 минут, но и по тем и по другим абсолютно корректно считать среднее, предварительно взяв "производную" (см. функцию rate). Дальше вопрос упирается в возможности источника данных — в ядре Linux многие вещи считаются (и есть возможность получать) правильно, в "одометрах", а вот в redis, например, это не так.


    Для всяких штук, типа "время ответа по HTTP" (или "размер HTTP ответа"), для которых средний показатель имеет очень ограниченный смысл, мы активно используем Histogram'ы.

  • Мониторинг и Kubernetes (обзор и видео доклада)
    +4

    Спасибо. У нас достаточно большие планы, надеюсь все сложится.

  • Улучшая надёжность Kubernetes: как быстрее замечать, что нода упала
    0

    В большинстве случаев мы используем значения по-умолчанию.

  • Лучшие практики CI/CD с Kubernetes и GitLab (обзор и видео доклада)
    0

    В этом же пакете.

  • Kubernetes 1.10: обзор основных новшеств
    +1
    distol Какое изменение/нововведение вы больше ждали в новой версии Kubernetes?

    В этом релизе нет ничего, чтобы мы прямо ждали-ждали. Много важного, но что-то одно выбрать нельзя.


    Как вы думаете стоит ли использовать github.com/sorintlab/stolon (stolon — PostgreSQL cloud native High Availability) в Kubernetes в проде?

    Мы не используем, но планируем в этом году. Не обязательно именно stolon, но нам сильно не хватает операторов, в первую очередь для MySQL, PostgreSQL и Redis. Как и с любым сложным комбайном — нужно до конца понимать, как оно работает.

  • Наш опыт с Kubernetes в небольших проектах (обзор и видео доклада)
    +1

    Зависит от инфраструктуры.


    • Если это AWS — там есть proxy protocol (у service нужно поставить специальную аннотацию и nginx сказать слушать proxy protocol, он это умеет штатно).
    • Если bare metal — мы делаем daemon set с hostNetwork, таким образом IP-адрес не теряется, но есть простой при обновлении самого ingress (или при падении). Проблему простоя решаем очень хитро, iptables с помощью модуля сокет, если 80 порт не слушается, перекидывает трафик на другой порт, на котором слушает nginx в режиме TCP-proxy, который добавляет proxy protocol и отправляет трафик в отдельный деплоймент с nginx ingress. Таким образом, у нас на фронтах ingress'ы в daemonset плюс дополнительный nginx tcp fallback в daemonset, плюс есть отдельный deployment nginx'ов. Тут можно посмотреть: https://github.com/flant/kubernetes-nginx-ingress .
  • Инфраструктура с Kubernetes как доступная услуга
    +1
    А что посоветуете для тех, кто только недавно понял, что контейнеризация и, в частности, Docker — это круто, хотел бы в новом проекте сразу заложить масштабируемую архитектуру, но для кого сразу заказывать N серверов у вас — дорого и неразумно, ведь все сервисы пока что спокойно уместятся на одной виртуалке?

    IMHO — всячески стараться ничего не делать на вырост, акцентируя максимум внимания на фичах, которые позволят проекту вырасти. По нашему опыту, доделать приложение до минимального соответствия https://12factor.net/ обычно сильно проще, чем кажется. Я бы даже не советовал заморачиваться с правильным хранением файлов (в S3 like), пока вы влезаете в одну виртулку. Самые большие проблемы, обычно, возникают с latency до базы / redis / memcached. Пока проект живет на одной виртуалке и ходит по localhost — можно без существенных проблем отправлять по 500 запросов в memcached (базу, etc) с одного входящего запроса юзера. Но как только начинаешь такой проект растаскивать по отдельным инстансам (виртуалкам или железкам — не важно), появляется сетевой latency, и эти 500 запросов, раньше занимавших 10мс, начинают занимать несколько секунд. И эти несколько секунд, при любых флуктуациях в сети, могут легко превращаться и в 10 секунд. Но всем известно, что несет с собой преждевременная оптимизация, так что — лучше просто об этом не думать.


    Т.е. если докер для разработки мы используем и хотели бы автоматизировать деплой также с использованием контейнеров. Но пока что на один сервер и только в будущем масштабироваться. Тоже Kubernetes?

    Я бы категорически не рекомендовал делать свою инсталляцию Kubernetes. Надо понимать, что у нас в компании больше 50 человек, из которых как минимум 20 каждый день по 8 часов занимаются чем-то связанным с Kubernetes. Команде из нескольких человек это просто не потянуть. Как вариант — использовать hosted Kubernetes (в Google и Asure уже есть, в AWS должно вот-вот появиться). Если нужно остаться на этой одной виртуалке — вам, наверное, в сторону docker compose.

  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
    0

    У нас поддерживается одноуровневый JSON и поддерживаются String, Number, Bool и Nil колонки. Как мы это делаем — кратко словами не передашь. Гляньте структуру таблицы, если интересно.

  • Инфраструктура с Kubernetes как доступная услуга
    0
    Спасибо за статью!

    Мы рады, что вас заинтересовало.


    Интересует а как вы обновляете кластера кубернетес, особенно которые на квм\бареметал? А также существует ли регулярная процедура\полиси апдейта? используете ли tectonic ?

    Пока руками обновляем, как бы это не казалось странно. Ждем поддержки bare metal в kops. С 1.6 на 1.7 обновились прекрасно. На следующей неделе, вероятно, будем обновляться до 1.8. На четкий полиси обновления самого kubernetes пока не вышли, это цель на начало следующего года. Пока ждем дозревания инструемнтов.

  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
    0
    Спасибо больше за статью и проект! Очень нужный стек!

    И вам спасибо, за интерес к проекту!


    Поддержку вопрос hostmaster, не рассматривали fluentbit как легковесный коллектор?

    Нет, но мы четко понимаем, что fluentd — это времянка. Сейчас мы подтвердили, что все работает и что проект нужен. Дальше заменим на что-то более эффективное. Сейчас у нас fluentd раз в секунду вызывает консольный клиент ClickHouse, до эффективности тут очень далеко :). Пока что думаем написать свой небольшой бинарь на go. А следующим шагом — добавить в этот бинарь поддержку query language, чтобы можно было сделать механизм подписок прямо на коллекторах (режим follow, который сейчас работает на polling из ClickHouse).


    Также хотелось бы деталей по использованию clickhouse в кластере k8s. Какой тип волюмов используете? cephfs? есть ли проблемы с проседанием перфоманса? pod clickhouse привязан к какой-то конкретной ноде?

    cephfs не нужен, если на bare metal и есть ceph — то rbd. Вообще, пока что, стараемся локально. Цифры по точному перфомансу (cpu, memory, iops, etc) выложим чуть позже, когда подготовим.

  • Инфраструктура с Kubernetes как доступная услуга
    0

    Про бэкап невозможно ответить кратко. Но тем не менее. Сейчас borgbackup в отдельном контейнере или поде. Мечтаем сделать operator или admission controller, который будет делать бекап borgbackup'ом согласно аннотациям в pod'ах.

  • Инфраструктура с Kubernetes как доступная услуга
    0

    Простите. Хочется аж прямо минуснуть свой же комментарий.

  • Инфраструктура с Kubernetes как доступная услуга
    +5

    На Highload за 2 дня у меня спросили раз 40. Было два вида вопросов — почему мы (Флант) считаем, что базу стоит ставить в контейнер/kubernetes (это же опасно!!!) и почему мы считаем, что базу НЕ стоит ставить в контейнер/kubernetes (это же удобно). Это означает, что мы всех запутали. Чтобы распутать — наверное напишем отдельный пост на хабре. Но отвечу кратко:


    • Все базы кроме прода — решительно да!
    • Прод — зависит от:
      • Если ваш сетевой сторедж позволяет переваривать ваш объем данных и количество IOPS'ов, и вы в нем уверены, — да,
      • Если это slave (который сам может bootstrap'аться с master) — да,
      • Если ваша база это горизонтально масштабирующийся мультимастер (cassandra, mongo, galera, etc), и вы не боитесь — может быть да,
      • Если… (и тут я понял, что все таки надо это систематизировать и писать статью).

    Итог — мы рекомендуем загонять в Kubernetes все НЕ продовые базы, но пока мы не можем рекомендовать это делать во всех в проде. Думаем, что через 1-4 месяца ситуация может измениться (со стабилизацией local storage).

  • Инфраструктура с Kubernetes как доступная услуга
    +2

    VolCh, спасибо за вопрос!


    Жаль не срослось у нас с вами, когда общались насчёт проекта с прошлой работы — наше руководство не хотело платить за обслуживание, только за внедрение по какой-то разумной часовой ставке специалиста, а обслуживать и развивать дальше своими силами. Одной из причин сменить работу это стало.

    Тут нам есть над чем поработать. С 2008-го года мы продавали, фактически, одну единственную услугу — это полное обслуживание инфраструктуры "под ключ". Не всем компаниям это подходит. Мы прямо сейчас запускаем другой вид услуг — именно консалтинг плюс внедрение. Такой формат гораздо лучше подходит компаниям, у которых уже есть своя сильная команда эксплуатации и им нужно просто быстрей получить опыт. Второй момент — сейчас все очень быстро меняется. Новая версия Kubernetes выходит раз в 3 месяц и с выходом каждой версии появляются возможности, меняются best practice, за этим нужно постоянно следить и переделывать. А кроме новой версии, и у нас и у всего DevOps комьюнити появляется опыт и экспертиза, как более эфеективно решать какие-то вопросы. Мы каждую неделю находим что-то и переделываем сейчас во всех проектах. Вот кроме услуги "консалтинг + внедрение" думаем продавать некоторую "подписку" (там будут текующие best practice, чеклисты по обновлению, проверенные нами helm и пр., а так же возможность задавать нам вопросы).


    есть динамическое создание неймспейсов (стэков в терминах swarm) при появлении ветки в git и удаление при удалении или таймауту, с автоматическим же созданием DNS-имён для каждого сервиса в каждой ветке?

    Да. Достаточно подробно рассказывал об этом позавчера на Highload: http://www.highload.ru/2017/abstracts/3073. Видео будет через некоторое время.


    локальное разворачивание всего проекта или отдельных контейнеров (минимум двух — клиента и сервера, с привязкой к остальным к какому-нибудь контуру на сервере) на машинах у разработчиков с отражением правок на хосте сразу в контейнере без билда

    Пока что можно только развернуть полную-полную копию локально в minikube. Такой вариант слабо подходит для проектов с микросервисной архитектурой, но вполне приемлем для других.


    Основная сложность по моему опыту — конфигурирование приложения, передача ему значений конфигов в зависимости от окружения, которые нельзя просто поместить в репозиторий или аргументом занести в контейнер при билде. В идеале приложение должно быть спсобно все динамические параметры принимать через env переменные или же оркестратор должен генерировать конфиги и пробрасывать в контейнеры в нужном приложению формате.

    На самом деле это не является блокером, есть вполне жизнеспособный workaround. Если переделывать конфигурацию приложения на ENV нет времени, можно без проблем сделать простейший shell-скрипт, который при запуске приложения сгенерит ему конфиг (из переменных окружения).

  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
    +1

    Огромное спасибо за фидбек. Выглядит так, как буд-то вы правы по каждому пункту. Будем благодарны за pull-request или сделаем сами чуть позже.

  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
    +1

    Нет. Классического полнотекстового поиска (токенизация, стемминг, индекс по словам) в ClickHouse, на сколько мне известно, нет. Однако ClickHouse позволяет прогнать данные через простую регулярку, и он может это сделать ооочень быстро. Поиск регуляркой среди 7 млрд записей занимает 6 ядер (12 тредов) на десяток секунд, а если локализовать (указать диапазон времени в несколько часов) — несколько сотен миллисекунд. Соответственно для логов самый раз — индексировать для настоящего полнотекстового поиска очень дорого (это куча места и вычислительных ресурсов, да и большие сложности с ротацией), запросов на запись несоизмеримо больше запросов на чтение (поэтому лучше съесть иногда чуть больше ресурсов на поиск, нежели постоянно на индексацию). Как-то так.