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



    Kubernetes стал для нас той технологией, которая в полной мере позволяет соответствовать строгим требованиям к отказоустойчивости, масштабируемости и качественному обслуживанию проекта. Несмотря на то, что сегодня K8s больше распространен в крупных организациях и проектах, мы научились применять его и в небольших приложениях. Снижение себестоимости обслуживания стало возможным для нас благодаря унификации и обобщению всех компонентов, которые встречаются практически у каждого клиента. Эта статья — взгляд на полученный опыт со стороны бизнес-потребностей и их технической реализации, которая позволяет нам предлагать клиентам качественное решение и поддержку за разумные деньги.

    «Rocket science» как норма


    Начну с общих слов о том, как мы вообще к этому пришли, а обзор технических деталей по предлагаемой инфраструктуре читайте ниже.

    Около 10 официальных лет «Флант» занимается системным администрированием GNU/Linux и бесчисленного множества сопутствующих технологий и программного обеспечения. Все это время мы улучшали свои рабочие процессы, часто сравнивая компанию с заводом, который переходит от ручного труда (необходимости «вручную» заходить на сервер при возникновении множества однообразных проблем) к потоковому производству (типовым конфигурациям, централизованному управлению, автоматическому деплою и т.п.). Даже несмотря на то, что многие обслуживаемые нами проекты сильно отличаются (в стеке применяемых технологий, требованиях к производительности и масштабированию…), у них есть фундамент, который подлежит систематизации. Этот факт позволяет превратить качественное обслуживание в типовое, обеспечивая клиента дополнительными преимуществами за разумные деньги.

    Взращивая внутри компании лучшие практики на основе опыта работы с разными проектами, обобщая и по возможности «программируя» их, мы распространяем эти результаты на другие имеющиеся инсталляции. Раньше ключевым инструментом для этого служила система управления конфигурациями (мы предпочитали Chef). Постепенно внедряя в инфраструктуру Docker-контейнеры, мы пошли на логичный шаг по интеграции их настройки с возможностями Chef (реализовали это в рамках своего инструмента dapp)…

    Но с появлением Kubernetes многое изменилось. Теперь мы описываем конфигурации в Kubernetes и получаем (предлагаем клиентам) инфраструктуру, которая:

    • централизованно управляется,
    • быстро разворачивается,
    • легко дополняется новыми сервисами,
    • не зависит от поставщика ресурсов (облачного провайдера, дата-центра),
    • масштабируется в случаях усложнения проекта или растущих нагрузок,
    • просто интегрируется с современными процессами и технологиями непрерывной интеграции и доставки приложений (CI/CD).

    Такой подход к инфраструктуре — результат наших продолжительных поисков оптимального решения, бесчисленных проб и ошибок, по-настоящему многогранного опыта обслуживания ИТ-систем. Это наше текущее видение разумной «нормы» для проектов разных масштабов.

    Частое ощущение, которое после этого возникает у владельцев бизнеса: «Ну, звучит классно, но это какой-то rocket science, и он не для нас, потому что слишком сложен и дорог». Однако наш опыт показывает, что этот «rocket science» идеально подходит даже для тех, кто думает, что ещё «не на том уровне» для внедрения Kubernetes:

    1. Выгода — инфраструктура, которая не только просто работает, чинится в случае аварий и постепенно (по мере запросов) улучшается… Это инфраструктура, которая по своей «природе» закрывает все потребности по отказоустойчивости, масштабируемости и сопровождению разработки (любые тестовые контуры, деплой, CI/CD). Она построена на лучших практиках DevOps и Open Source-компонентах, являющихся стандартом индустрии.
    2. Сложность — зона нашей ответственности, которая как раз и заключается ровно в том, чтобы, наоборот, сделать результат максимально простым для пользователей, т.е. разработчиков.
    3. Стоимость — обычная ежемесячная абонентская плата за обслуживание такой типовой инфраструктуры для небольшого проекта составляет от 80 до 120 тыс. рублей, что сопоставимо с наймом одного «условно среднего» Linux-инженера.

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

    Технические подробности


    Что за «небольшой проект»?


    Рассматриваемая в статье архитектура уже реализована во множестве проектов различной направленности: это СМИ, интернет-магазины, онлайн-игры, социальные сети, блокчейн-платформы и т.п.

    Что такое небольшой проект, на который она рассчитана? Критерии не являются очень строгими, но обозначают основные тенденции и требования:

    • Это проект, у которого уже больше 1 сервера (верхнюю границу называть неправильно, так как архитектура может быть развернута на множестве серверов).
    • Проекту уже требуется отказоустойчивость, так как он является инструментом бизнеса и приносит прибыль.
    • Проект должен быть готов к высоким нагрузкам, и существует реальная потребность в возможности быстрого масштабирования (например, интернет-магазин должен временно увеличить серверные мощности перед Black Friday).
    • Проекту уже требуется системный администратор, потому что без него ничего не получается.

    Если очень кратко описать архитектуру в целом, то можно сказать, что это «отказоустойчивое и масштабируемое облако Docker-контейнеров, которое находится под управлением Kubernetes». И вот что в неё входит…

    Приложение в Kubernetes


    Здесь и далее я возьму в качестве примера типовой интернет-магазин. Представим себе, что есть 3 сервера, на которых развернут кластер Kubernetes. Kubernetes — это главная составляющая архитектуры, это компонент, который занимается оркестровкой Docker-контейнеров и их управлением. Он отвечает за надежную, отказоустойчивую и масштабируемую работу контейнеров, внутри которых работает приложение клиента. Т.е. по сути это облако из контейнеров, работающее на трех серверах. Если один из серверов, на которых работает облако, выходит из строя, то Kubernetes автоматически перекидывает упавшие контейнеры (работавшие на упавшем сервер) на оставшиеся два сервера — это происходит очень быстро, в течение нескольких секунд.



    Наша цель — падение одного сервера или даже двух серверов в облаке должно быть незаметным событием. Это достигается за счет того, что каждый компонент как минимум однократно продублирован и внутри облака экземпляры одного компонента расположены на разных серверах. При этом резервный компонент готов мгновенно принять нагрузку на себя. Если приложение поддерживает, то возможен вариант, когда все экземпляры компонента работают одновременно, а не в режиме «главный-резерв». Также есть возможность по нажатию кнопки «отмасштабироваться» и получить еще один-два-три и более дополнительных экземпляров этого компонента.

    Представим себе, что интернет-магазин написан на PHP и у него есть следующие компоненты*:

    • база данных MySQL;
    • PHP-бэкенд;
    • кеширование в memcached;
    • очередь RabbitMQ;
    • хранение заказов в Redis;
    • консьюмер;
    • cron-задачи.

    * В действительности же не так важно, интернет-магазин это или сайт СМИ, и даже сами компоненты могут быть совсем иными, но суть останется прежней.

    Как вы уже могли догадаться, часть нашей работы состоит в том, чтобы упаковать приложение (в данном случае ­— интернет-магазин) в Docker-контейнеры, а затем запустить эти контейнеры в облаке Kubernetes. Помимо самого приложения (PHP-бэкенда) в облаке работают и остальные компоненты: memcached, RabbitMQ и т.п.

    Примечание: Мы до сих пор не устанавливаем РСУБД в production внутрь облака Kubernetes по некоторым технологическим причинам. Однако начали делать первые такие инсталляции для маленьких проектов и приложений не в production (dev-контуры и т.п.).



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

    Базы данных


    СУБД выделены в отдельную сущность, так как они в большинстве случаев находятся за пределами Kubernetes и обычно представляют собой 2 или 3 сервера, которые работают в режиме master-slave (MySQL, PostgreSQL, ...) или master-master (Percona XtraDB), с автоматическим или ручным failover на случай аварийной ситуации.

    PHP-бэкенд


    Бэкенд представляет собой код приложения, упакованный в Docker-контейнер. В этом контейнере установлены необходимые приложению библиотеки и софт (например, PHP 7). Тот же самый контейнер используется для запуска консьюмеров и cron-задач. В Kubernetes мы запускаем несколько экземпляров бэкенда, один крон и несколько консьюмеров.

    Memcached


    С memcached у нас исторически сложилось два варианта реализации, которые применяются в различных ситуациях:

    • N отдельных экземпляров memcached (обычно 3). Приложение знает о всех трех memcached и пишет во все три, само обеспечивает failover.
    • Mcrouter — универсальный вариант, который подойдет любому приложению. Логика распределенной записи и failover вынесена из приложения на сторону mcrouter.

    RabbitMQ


    Мы используем штатный кластер RabbitMQ из трех и более узлов с автоматическим failover’ом на уровне Kubernetes.

    Redis


    В основе этого компонента мы используем штатный кластер Redis Sentinel, имеющий некоторую обвязку, которая избавляет приложение от необходимости реализации протокола sentinel.

    Другие сервисы приложения


    Аналогичным образом у нас в арсенале есть такие готовые и протестированные компоненты, как minio, sphinxsearch, elasticsearch и многие другие. Практически любой софт может быть установлен внутри Kubernetes — главное, подходить к этому процессу с умом.

    Служебные компоненты


    Каждый проект имеет также следующие служебные компоненты Kubernetes:

    • Панель управления (dashboard), которая дает разработчикам возможность управления компонентами. Также через нее можно попадать внутрь контейнеров — практически как по SSH.
    • Централизованное хранилище логов. Сбор логов производится в режиме реального времени со всех компонентов во всех контурах, логи пишутся в единую базу данных. Доступен веб-интерфейс с возможностью просмотра всех логов в реальном времени, поиска и фильтрации по различным параметрам. Для этого используется собственное Open Source-решение loghouse, подробнее о котором читайте в этом анонсе.
    • Мониторинг на Prometheus + Okmeter. Prometheus установлен внутри Kubernetes и собирает статистические данные со всех компонентов. Помимо стандартных параметров (память, диск, CPU) также снимаются метрики с Apache/php-fpm, RabbitMQ, Redis и т.п. — каждый компонент отдельно мониторится. Okmeter стоит снаружи Kubernetes и занимается мониторингом самих серверов извне.

    Консалтинг по архитектуре и stateless


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

    Если совсем «на пальцах», то это значит, что каждый компонент приложения не хранит промежуточных данных, либо эти данные мало важны и их можно безболезненно потерять. Это нужно для того, чтобы можно было запустить несколько бэкендов и при внезапном отказе одного из них ничего бы не сломалось, никакие загруженные пользователями файлы бы не удалились и т.д.

    Самые частые причины, которые мешают сделать приложение stateless, — это:

    1. Локальное хранение сессий на бэкенде (в файлах). Это вопрос практически всегда решается простым вынесением сессий в отказоустойчивый memcached (либо через настройки PHP, либо через настройки приложения).
    2. Локальное хранение файлов загрузки на бэкенде. Вопрос решается с помощью использования выделенного хранилища файлов (например, Amazon S3 или хранилища файлов от Selectel) или вариантами с хранилищем на серверах клиента, реализованным на minio или Ceph (S3/Swift API).

    Ответ на возникающие опасения касательного такого stateless-будущего (да, действительно придётся потратить ресурсы разработчиков на изменения в приложении для этого) заключается в том, что оно всё равно неизбежно (для приложений, которым нужно масштабирование) и что приближаться к нему можно поэтапно.

    Другие проблемы и особенности


    CI/CD


    Наконец, возникает логичный вопрос, как же происходит деплой кода приложения в такую инфраструктуру. Устроено это следующим образом:

    1. Код находится под управлением системы версионирования (Git).
    2. Мы используем GitLab*, чтобы после коммита кода вызывать сборку Docker-контейнера.
    3. После стадии сборки в GitLab появляется кнопка «выкатить на production».
    4. Нажимаем эту кнопку — новая версия приложения выкатывается и запускается, старая версия останавливается, выкат происходит бесшовно и незаметно для пользователя сайта. Также во время выката выполняются миграции БД.

    В Kubernetes есть пространства имен (namespaces). Их можно представить себе как отдельные изолированные контуры или окружения, которые запускаются в одном кластере. То есть у нас появляется возможность сделать отдельный контур для staging, для master-ветки… или вообще на каждую ветку делать свой отдельный контур. Контур представляет собой полную копию production: там стоят все те же самые компоненты (MySQL, бэкенды, Redis, RabbitMQ и т.д.). Это достигается за счет того, что вся конфигурация инфраструктуры (конфигурация всех компонентов) описана в специальных YAML-файлах и лежит в репозитории, то есть мы получаем возможность быстро и полностью воссоздать production-среду в любом другом namespace.



    * С примером нашего пайплайна в GitLab CI и техническими подробностями его реализации можно ознакомиться в этой статье.

    Серверы


    Самая типовая инсталляция — это 3 сервера-гипервизора, имеющие примерно такую конфигурацию: E5-1650v4, 128G RAM, 2×500 ГБ SSD. Серверы объединены между собой локальной сетью. Ресурсы каждого сервера разделены с помощью виртуальных машин (Linux KVM + QEMU) на такие части:

    • production-контур;
    • dev-контуры;
    • служебные сервисы Kubernetes (мастеры и фронты);
    • база данных.

    Резервное копирование


    Мы бэкапим все, что требуется в проекте: базы данных, upload-файлы и т.п. Никаких простоев при бэкапе не возникает (для СУБД данные снимаются со slave-сервера и т.п.). План бэкапа и его ежемесячного тестирования согласуется с клиентом — за это отвечает персональный менеджер проекта.

    Мониторинг и взаимодействие


    Это уже не всегда технические вопросы, но они важны для понимания полной картины осуществляемой поддержки:

    • Благодаря имеющимся у нас средствам мониторинга, все алерты стекаются в централизованный интерфейс для дежурных инженеров. Каждый инцидент должен быть обработан, по каждому должно быть резюме. Мы гарантируем реакцию на алерты в течение 15 минут, при этом наше среднее время реакции на алерт — 1 минута (и 10 минут на триаж). Дежурные инженеры круглосуточно на связи по телефону, Slack, почте, системе тикетов (Redmine).
    • У каждого нашего проекта есть выделенный менеджер, а также выделенная команда инженеров, в составе которой есть и ведущий инженер, и рядовые инженеры, и младшие инженеры. Эти люди не меняются — они «живут» с проектом с самого его начала и полностью понимают, как он устроен.
    • Мы предлагаем гарантии по SLA, подразумевающие штрафы за простой критичной для бизнеса инфраструктуры.

    Резюмируя


    Мы верим, что современные инфраструктурные решения категории cloud native могут работать во благо уже сейчас и для всех, а стоимость их применения не должна быть сопоставима с ценой космического корабля. Можно провести аналогию с мобильной связью: если раньше сотовая связь была доступна только избранным, то сегодня это обыденность и данность, а цена за связь невелика.

    Пройдя путь от «ручного» администрирования «всего на Linux» до поддержки современной инфраструктуры на базе Kubernetes, мы стремимся к тому, чтобы сервис, который мы считаем разумной «нормой», был доступным для клиентов с любым бюджетом. Поэтому предлагаем выделенную команду специалистов для внедрения/обслуживания такой инфраструктуры по принципам DevOps (в тесном взаимодействии с разработчиками) с круглосуточной поддержкой и гарантиями по SLA в рамках бюджета на уровне зарплаты системного администратора/DevOps-инженера, нанятого в штат.

    Многие технические аспекты вкратце рассмотренной здесь инфраструктуры (и связанных с ней лучших практик) подлежат значительной детализации, но это история для отдельных статей: и если некоторые из них уже опубликованы в нашем блоге, то запросы на новые — приветствуются в комментариях. Будем рады и вопросам не по технологиям, а процессам, используемым нами в работе и/или предлагаемым клиентам в рамках обслуживания.

    P.S.


    Читайте также в нашем блоге:

    Флант 382,23
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией
    Комментарии 28
    • +2

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


      Уже из спортивного интереса пара вопросов не раскрытых, которые могут кого-то сподвигнуть на переход:


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

      Также хочу отметить для читателей, что сложности по переводу PHP-приложения в стейтлесс многими сильно преувеличиваются, считается необоснованно, что объём работы очень большой. Для сессий часто достаточно настройку в php.ini сменить, а для пользовательских или генерируемых приложением файлов — примонтировать nfs/smb шару в контейнеры, если слова типа "(например, Amazon S3 или хранилища файлов от Selectel) или вариантами с хранилищем на серверах клиента, реализованным на minio или Ceph (S3/Swift API)" вас пугают, как меня. Основная сложность по моему опыту — конфигурирование приложения, передача ему значений конфигов в зависимости от окружения, которые нельзя просто поместить в репозиторий или аргументом занести в контейнер при билде. В идеале приложение должно быть спсобно все динамические параметры принимать через env переменные или же оркестратор должен генерировать конфиги и пробрасывать в контейнеры в нужном приложению формате.

      • +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-скрипт, который при запуске приложения сгенерит ему конфиг (из переменных окружения).

      • 0
        Открывал статью надеясь прочитать как организуется БД в контейнерах :))
        • 0
          Это тема для отдельной статьи :-) Есть какие-то конкретные/специфические вопросы или про организацию «в целом»?
          • 0
            Я в контейнеры пока только въезжаю, по этому мне интересно в целом — как организуется Бд в контейнерах и как хранить данные этой БД.
            • 0
              насколько мне известно, в docker, например, можно «подключить» volume (папку с диска, где запущен контейнер) и там будет жить БД, т.е. обрабатываться все в контейнере, а храниться на docker-хосте

              docs.docker.com/engine/admin/volumes/volumes
              • 0
                Так хранить БД на одном сервере — не надёжно… либо тогда из вольюмов на нескольких серверах надо собирать какую то кластерную хранилку ещё
                • +1
                  как по мне, кластеризировать БД лучше средствами СУБД
              • +1

                Три основных варианта, вроде.


                1. Прибиваем гвоздями инстансы к конкретным хостам с локальными томами. Теряем много плюсов от контейнеризации.
                2. Инстансы подключаются к сетевому хранилищу, прибиваясь к нему. Часто сильно снижает скорость работы БД, но могут быть нюансы, например, если и так логические диски на хостах физически каким-нибудь SAN с доступом по сети являются.
                3. Настраиваем сложный кластер с хранением данных в локальных томах, с автоматическим подключением нового инстанса к кластеру, догонянием инстанса кластера (лучше от переиодически снимаемого снэпшота, а не с ноля, но от базы зависит) и переключением в режим полноценной ноды. Самый сложный вариант, сильно зависящий от конкретной базы, может потребовать доработки клиентов, но полностью использует преимущества контейнеризации и кластеризации
                • 0
                  Мда… видимо по этому
                  СУБД выделены в отдельную сущность, так как они в большинстве случаев находятся за пределами Kubernetes

                  На сколько я могу понять — БД не для контейнеров? По крайней мере в текущей реализации
                  • 0

                    БД не для оркестрации контейнерами.
                    То есть запустить на одном хосте локально в контейнере БД с пробросом папки на хост все еще можно. У вас так же остается возможность версионировать через образ и прочее.


                    А для кластеров на кубе вроде юзают такие штуки: https://coreos.com/operators/

                    • 0
                      Ну вот я более-менее получил ответ на свой вопрос, который меня интересовал :)
                    • +5

                      Если вы в k8s поднимете mysql в StatefulSet с одним инстансом и PersistentVolumeClaim для хранилища — это фактически ничем не будет отличаться от mysql вне k8s.


                      В самой простой ситуации вы прибиваете Volume на каталог хост машины и получаете 1:1 ту же надежность как и вне кластера (машина умерла — БД умерла с ней).


                      Как это можно улучшить уже средствами k8s? Можно использовать сетевое хранилище для PVC, например ceph rbd, aws ebs, iscsi или даже nfs. Таким образом при потере машины, рабочая нагрузка мигрирует на другую, а хранилище перемонтируется. Это не гарантирует отсутствие даунтайма, и потенциально медленнее (сетевое хранилище хуже чем локальный SSD).


                      Дальше в дело вступает репликация. Если ваша БД может комфортно работать в режиме master-master, то вы просто поднимаете N реплик тем же StatefulSet и потеря любой из них не будет вас волновать, мастера догонятся друг от друга. В таком случае можно использовать эфемерное хранилище (тот же локальный диск), т.к. потеря данных одной ноды не критична.


                      Наконец, можно делать R/W + R/O реплики (для mysql это, наверно, оптимальный вариант для быстрого чтения и наименьшего простоя). У k8s прямо в доках есть пример для mysql. Тут первая реплика это R/W с персистентным хранилищем, а последующие — R/O с эфемерным и они догоняются от реплики N-1. Падение машины с первой репликой дает вам даунтайм на запись (пока mysql запускается на другой ноде), потеря R/O реплик полностью незаметна, плюс R/O реплики читают с локального быстрого диска.


                      TL;DR: БД отлично работают в контейнерах, просто надо понимать где вы выигрываете, и что теряете.

                      • 0
                        Спасибо, пойду читать подробности
                      • +5

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


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

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

                        • +1

                          Вы и сейчас запутываете :(


                          Все базы кроме прода — решительно да!

                          Что да то? Стоит или не стоит?
                          Из продолжения, конечно, становится понятно, но это всё равно не дело.

                          • 0
                            Да!
                            • 0

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

                              • 0

                                Лучше просто исправьте его.
                                Кстати, хотелось бы услышать про то, как у вас устроен бэкап.

                                • 0

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

                                  • 0

                                    Аналогично :-)


                                    Но admission controller'ы все еще не могут мутировать ничего кроме image, так что sidecar контейнер вставить не выйдет.

                • +1

                  Спасибо за статью!


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

                  • 0
                    Спасибо за статью!

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


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

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

                    • 0

                      Благодарю за ответ!


                      Руками(через CM) обновлять достаточно время-затратно ;) Нужен постоянный напильник. Когда k8s не профильное направление, невольно хочется готовых production grade тулзов.
                      Как kops работает в aws весьма нравится, будем ждать ) Tectonic имел в виду как инсталлер для бареметал\квм.

                    • 0
                      используете ли tectonic ?

                      Коллега выше забыл написать, что Tectonic (и прочие аналоги) не используем — работаем с upstream-дистрибутивом Kubernetes.
                    • 0
                      А что посоветуете для тех, кто только недавно понял, что контейнеризация и, в частности, Docker — это круто, хотел бы в новом проекте сразу заложить масштабируемую архитектуру, но для кого сразу заказывать N серверов у вас — дорого и неразумно, ведь все сервисы пока что спокойно уместятся на одной виртуалке?

                      Т.е. если докер для разработки мы используем и хотели бы автоматизировать деплой также с использованием контейнеров. Но пока что на один сервер и только в будущем масштабироваться. Тоже 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.

                        • 0

                          Начните с docker-compose, когда натолкн'тесь на ограничения — попробуйте docker swarm кластер из одной ноды. И только когда и в нём станет тесно, тогда смотрите в сторону других решений.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое