Это далеко не всегда так плохо, как вы описываете. По крайней мере "фантазеров" и "дойщиков" сразу видно и с ними все понятно. Очень часто я вижу и у архитекторов и у разработчиков большую и абсолютно искреннюю надежду, что микросервисная архитектура значительно упростит их жизнь, на практике же часто выходит боком. Об этом и пытался рассказать.
Но причем тут Kubernetes и микросервисы? Buzzwords anchors?
Тут я вынужден просить прощения — доклад изначально планировался больше про эксплуатацию и про Kubernetes, как и обычно… а получился больше про архитектуру. Кажется я сказал об этом в начале. В любом случае прошу простить.
Для нас Kubernetes — это просто один из инструментов. И очень мощный инструмент. И как и у любого мощного инструмента — у него достаточно высокий входной платеж. Нам, конечно же, удобней делать все проекты в Kubernetes, так-как именно для нас — так быстрей и удобней. Понятно, что в общем случае в первую очередь стоит исходить из возможностей команды и реальных потребностей проекта. Во многих может быть проще и правильней два хоста и docker-compose.
Да! У нас тоже статусы многих разных вещей stacked bar'ами раньше показывались, и что мы только не делали, чтобы это хоть как-то наглядно выглядело, вот так и пришли к созданию этого плагина.
Дополню, на всякий случай. Речь идет совершенно не о том, что приложение обрабатывает SIGKILL ))). Речь о том, что при безусловном завершении всегда выполняется заявленный уровень гарантий: если это ACID — значит ACID, если что-то мягче — значит оно.
На практике — я бы не стал полагаться на PreStop для mission critical задач, это не тот механизм. На практике:
В PreStop мы обычно делаем graceful shutdown, чтобы как можно более мягко приглушить под,
Но при этом, обязательно четко понимая, что любое важное действие в любом случае должно иметь некоторый механизм "retry".
Всем очевидно, что если веб-приложение, которое при обработке HTTP запроса делает два запроса в базу (один на зачисление денег на один счет и второй на их списание с другого), не использует транзакции — у вас в любом случае будут серьезные проблемы. И никакими PreStop хуками эти проблемы не исправишь. Аналогично и со stateful приложением, если оно не в состоянии корректно обработать "kill -9", а требует мягкого выключения — с ним в любом случае будут большие проблемы. При этом это не означает, что нужно всегда mysql выключать по kill -9, конечно же — и вот именно для этого и нужны PreStop хуки.
При этом зачастую сделать приложение с корректными "ретраями" совершенно не так сложно, как может сначала показаться. Современные веб фреймворки очень сильно в этом помогают. Соответственно даже если graceful shutdown не будет выполнен и приложение будет прибито жестко — ничего страшнее retry не происходит.
Нет. Ни 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 значительно продвинулась.
Большая часть показателей, которые экспортируются всеми системами — это "одометры" (тип counter), так что в целом эта проблема более-менее решена. Например, данные по CPU контейнера приходят как counter с количеством потраченных секунд. Соотвественно в основном Prometheus'е у нас данные за каждые 30 секунд, а в longterm за каждые 5 минут, но и по тем и по другим абсолютно корректно считать среднее, предварительно взяв "производную" (см. функцию rate). Дальше вопрос упирается в возможности источника данных — в ядре Linux многие вещи считаются (и есть возможность получать) правильно, в "одометрах", а вот в redis, например, это не так.
Для всяких штук, типа "время ответа по HTTP" (или "размер HTTP ответа"), для которых средний показатель имеет очень ограниченный смысл, мы активно используем Histogram'ы.
distol Какое изменение/нововведение вы больше ждали в новой версии Kubernetes?
В этом релизе нет ничего, чтобы мы прямо ждали-ждали. Много важного, но что-то одно выбрать нельзя.
Как вы думаете стоит ли использовать github.com/sorintlab/stolon (stolon — PostgreSQL cloud native High Availability) в Kubernetes в проде?
Мы не используем, но планируем в этом году. Не обязательно именно stolon, но нам сильно не хватает операторов, в первую очередь для MySQL, PostgreSQL и Redis. Как и с любым сложным комбайном — нужно до конца понимать, как оно работает.
Если это 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 .
А что посоветуете для тех, кто только недавно понял, что контейнеризация и, в частности, 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.
У нас поддерживается одноуровневый JSON и поддерживаются String, Number, Bool и Nil колонки. Как мы это делаем — кратко словами не передашь. Гляньте структуру таблицы, если интересно.
Интересует а как вы обновляете кластера кубернетес, особенно которые на квм\бареметал? А также существует ли регулярная процедура\полиси апдейта? используете ли tectonic ?
Пока руками обновляем, как бы это не казалось странно. Ждем поддержки bare metal в kops. С 1.6 на 1.7 обновились прекрасно. На следующей неделе, вероятно, будем обновляться до 1.8. На четкий полиси обновления самого kubernetes пока не вышли, это цель на начало следующего года. Пока ждем дозревания инструемнтов.
Спасибо больше за статью и проект! Очень нужный стек!
И вам спасибо, за интерес к проекту!
Поддержку вопрос 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, как и обычно… а получился больше про архитектуру. Кажется я сказал об этом в начале. В любом случае прошу простить.
И да и нет. И чем больше я общаюсь с людьми и получаю обратной связи по конкретно этому докладу — скорей нет, чем да. Если вам очевидно — вы молодец!
Для нас Kubernetes — это просто один из инструментов. И очень мощный инструмент. И как и у любого мощного инструмента — у него достаточно высокий входной платеж. Нам, конечно же, удобней делать все проекты в Kubernetes, так-как именно для нас — так быстрей и удобней. Понятно, что в общем случае в первую очередь стоит исходить из возможностей команды и реальных потребностей проекта. Во многих может быть проще и правильней два хоста и docker-compose.
Мы очень давно и активно используем local storage, но до сих пор руки не дошли до local volume provisioner'а.
Да! У нас тоже статусы многих разных вещей stacked bar'ами раньше показывались, и что мы только не делали, чтобы это хоть как-то наглядно выглядело, вот так и пришли к созданию этого плагина.
Дополню, на всякий случай. Речь идет совершенно не о том, что приложение обрабатывает SIGKILL ))). Речь о том, что при безусловном завершении всегда выполняется заявленный уровень гарантий: если это ACID — значит ACID, если что-то мягче — значит оно.
На практике — я бы не стал полагаться на PreStop для mission critical задач, это не тот механизм. На практике:
Всем очевидно, что если веб-приложение, которое при обработке HTTP запроса делает два запроса в базу (один на зачисление денег на один счет и второй на их списание с другого), не использует транзакции — у вас в любом случае будут серьезные проблемы. И никакими PreStop хуками эти проблемы не исправишь. Аналогично и со stateful приложением, если оно не в состоянии корректно обработать "kill -9", а требует мягкого выключения — с ним в любом случае будут большие проблемы. При этом это не означает, что нужно всегда mysql выключать по kill -9, конечно же — и вот именно для этого и нужны PreStop хуки.
При этом зачастую сделать приложение с корректными "ретраями" совершенно не так сложно, как может сначала показаться. Современные веб фреймворки очень сильно в этом помогают. Соответственно даже если graceful shutdown не будет выполнен и приложение будет прибито жестко — ничего страшнее retry не происходит.
Нет. Ни 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 значительно продвинулась.
Я тоже так раньше думал, но нет. Увидим!
Большая часть показателей, которые экспортируются всеми системами — это "одометры" (тип counter), так что в целом эта проблема более-менее решена. Например, данные по CPU контейнера приходят как counter с количеством потраченных секунд. Соотвественно в основном Prometheus'е у нас данные за каждые 30 секунд, а в longterm за каждые 5 минут, но и по тем и по другим абсолютно корректно считать среднее, предварительно взяв "производную" (см. функцию rate). Дальше вопрос упирается в возможности источника данных — в ядре Linux многие вещи считаются (и есть возможность получать) правильно, в "одометрах", а вот в redis, например, это не так.
Для всяких штук, типа "время ответа по HTTP" (или "размер HTTP ответа"), для которых средний показатель имеет очень ограниченный смысл, мы активно используем Histogram'ы.
Спасибо. У нас достаточно большие планы, надеюсь все сложится.
В большинстве случаев мы используем значения по-умолчанию.
В этом же пакете.
В этом релизе нет ничего, чтобы мы прямо ждали-ждали. Много важного, но что-то одно выбрать нельзя.
Мы не используем, но планируем в этом году. Не обязательно именно stolon, но нам сильно не хватает операторов, в первую очередь для MySQL, PostgreSQL и Redis. Как и с любым сложным комбайном — нужно до конца понимать, как оно работает.
Зависит от инфраструктуры.
IMHO — всячески стараться ничего не делать на вырост, акцентируя максимум внимания на фичах, которые позволят проекту вырасти. По нашему опыту, доделать приложение до минимального соответствия https://12factor.net/ обычно сильно проще, чем кажется. Я бы даже не советовал заморачиваться с правильным хранением файлов (в S3 like), пока вы влезаете в одну виртулку. Самые большие проблемы, обычно, возникают с latency до базы / redis / memcached. Пока проект живет на одной виртуалке и ходит по localhost — можно без существенных проблем отправлять по 500 запросов в memcached (базу, etc) с одного входящего запроса юзера. Но как только начинаешь такой проект растаскивать по отдельным инстансам (виртуалкам или железкам — не важно), появляется сетевой latency, и эти 500 запросов, раньше занимавших 10мс, начинают занимать несколько секунд. И эти несколько секунд, при любых флуктуациях в сети, могут легко превращаться и в 10 секунд. Но всем известно, что несет с собой преждевременная оптимизация, так что — лучше просто об этом не думать.
Я бы категорически не рекомендовал делать свою инсталляцию Kubernetes. Надо понимать, что у нас в компании больше 50 человек, из которых как минимум 20 каждый день по 8 часов занимаются чем-то связанным с Kubernetes. Команде из нескольких человек это просто не потянуть. Как вариант — использовать hosted Kubernetes (в Google и Asure уже есть, в AWS должно вот-вот появиться). Если нужно остаться на этой одной виртуалке — вам, наверное, в сторону docker compose.
У нас поддерживается одноуровневый JSON и поддерживаются String, Number, Bool и Nil колонки. Как мы это делаем — кратко словами не передашь. Гляньте структуру таблицы, если интересно.
Мы рады, что вас заинтересовало.
Пока руками обновляем, как бы это не казалось странно. Ждем поддержки bare metal в kops. С 1.6 на 1.7 обновились прекрасно. На следующей неделе, вероятно, будем обновляться до 1.8. На четкий полиси обновления самого kubernetes пока не вышли, это цель на начало следующего года. Пока ждем дозревания инструемнтов.
И вам спасибо, за интерес к проекту!
Нет, но мы четко понимаем, что fluentd — это времянка. Сейчас мы подтвердили, что все работает и что проект нужен. Дальше заменим на что-то более эффективное. Сейчас у нас fluentd раз в секунду вызывает консольный клиент ClickHouse, до эффективности тут очень далеко :). Пока что думаем написать свой небольшой бинарь на go. А следующим шагом — добавить в этот бинарь поддержку query language, чтобы можно было сделать механизм подписок прямо на коллекторах (режим follow, который сейчас работает на polling из ClickHouse).
cephfs не нужен, если на bare metal и есть ceph — то rbd. Вообще, пока что, стараемся локально. Цифры по точному перфомансу (cpu, memory, iops, etc) выложим чуть позже, когда подготовим.