company_banner

Истории успеха Kubernetes в production. Часть 10: Reddit

    На прошлой неделе было объявлено о том, что отныне все новые сервисы Reddit запускаются в production на инфраструктуре, основанной на Kubernetes-кластерах. Эта значимая веха на пути миграции на K8s одного из популярнейших онлайн-ресурсов, и вот как к ней пришли…



    Ликбез: На сегодняшний день Reddit входит в топ-20 мировых сайтов (и №6 в США) по оценке Alexa. Это онлайн-сообщество американского происхождения составляют более 400 миллионов активных (в течение месяца) пользователей, 12 миллионов публикаций и 2 миллиардов голосов в день.

    О том, почему и как инженеры Reddit пришли к Kubernetes, на KubeCon 2018 в декабре прошлого года рассказал (презентация + видео) Greg Taylor — руководитель Release Engineering Group департамента инфраструктуры проекта.



    Почему пришли к Kubernetes?


    В начале 2016 года у сервиса, реализованного в виде монолитного приложения, было всего около 20 инженеров, которые образовывали 3 команды, одна из которых и является своеобразным героем истории — Infrastructure team. Однако этот год принёс большие перемены: уже к его концу в компании работали более 60 инженеров (а к концу 2018-го года их число увеличилось до 200, т.е. всего за 3 года случился 10-кратный рост штата).

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

    Переходя на архитектуру сервисов вместо большого монолита, в Reddit столкнулись с новой проблемой. Инфраструктурная команда стала узким местом в деятельности разработчиков, которые оказались очень зависимы от неё на разных этапах: при инициализации сервисов, во время их продолжающейся эксплуатации, при отладке и решении проблем производительности. В качестве быстрого исправления проблемы в компании сформировали более самодостаточные команды, названные «инфраструктурно-ориентированными»: участники таких команд имели необходимые навыки в области эксплуатации инфраструктуры, позволявшие преодолевать многие сложности, не дожидаясь действий Infrastructure team, перегруженной бесконечным backlog'ом от многочисленных разработчиков.

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



    Как же разрешилась эта ситуация? В организации ввели понятие владельцев сервисов (service owners), которые могли бы разрабатывать свой сервис с самого начала и до конца, деплоить сервис рано и часто, эксплуатировать сервис (включая вопросы его доступности и производительности). Но как этого добиться?

    Вместо того, чтобы ожидать от команд инженеров безупречных навыков соединять сервисы воедино из десятков кирпичиков, по многим из которых у них может не быть знаний, нужно предложить им хорошо продуманный, предварительно определённый путь для вывода сервисов в production, затрагивающий минимум технологий. Это избавит инженеров от необходимости изучать многочисленные новые технологии и инструменты, которых может оказаться действительно много:



    «Чтобы реализовать эту идею на практике, нам потребовалось „упаковать“ знания, процесс, лучшие практики и многое другое в более доступную форму».

    InfreRedd — Kubernetes в Reddit


    Так и появился InfreRedd — внутренний инфраструктурный продукт Reddit, основанный на Kubernetes.

    Как были удовлетворены три потребности владельцев сервисов, указанные в их определении?

    1. Разработка


    Стандарт для разработки в организации не указывает на выбор конкретного языка или фреймворка, а задаёт общую «форму» сервиса, которой он должен соответствовать. Стандарт — спецификация сервиса, не зависимая от языка программирования, — включает в себя определение RPC-протокола, работу с секретами, отдачу метрик, возможности трассировки и формат выдачи логов. На пример реализации такой спецификации на Python можно посмотреть в проекте baseplate, который, впрочем, вряд ли кому-то пригодится для реального использования, но может стать вдохновением.

    Кроме того, были созданы материалы для быстрого старта при написании новых сервисов: заготовки кода (stubs) для разных языков (Python, Go, Node), а также Dockerfile, конфиги для CI и даже Helm-чарты.

    Для помощи в локальной разработке выбор инженеров Reddit пал на продукт Google — Skaffold, — предлагающий понятный разработчикам цикл edit → rebuild → refresh, который:

    • не требует глубоких знаний Kubernetes;
    • максимально приближен к production;
    • позволяет использовать стандартные чарты/образы;
    • и — в отличие от Minikube, который использовался раньше, — работа с Skaffold не требует огромных ресурсов от рабочих ноутбуков (потому что выкат производится на удалённые кластеры).

    2. Деплой


    Для запуска тестов и сборки артефактов (обычно это Docker-образы) в Reddit используют платформу непрерывной доставки Drone.

    Для деплоя в Kubernetes изначально использовался плагин к Helm для Drone, однако довольно быстро инженеры пришли к тому, что Helm их не устраивает, потому что они хотели систему, которая «лучше понимает состояние создаваемых или обновляемых объектов», а дальнейшая автоматизация процессов деплоя привела к необходимости решения, которое могло бы обращаться к используемому инструментарию и ставить на паузу rollback, если возникали сбои или проблемы с производительностью.

    В итоге, для оркестровки деплоя в Kubernetes был выбран Spinnaker. Для него были созданы шаблоны типовых пайплайнов (на Jsonnet). Далее генерируются Helm-чарты, которые уже и выкатываются в Kubernetes усилиями Spinnaker. Пользователи получают информацию о прогрессе деплоя и помощь для диагностики в случае каких-либо проблем. Вот как в очень общем виде выглядит типовой процесс деплоя в staging/production:



    3. Эксплуатация


    Во-первых, как вообще разделяются обязательства владельцев сервисов и инфраструктурной команды?

    • Service owners: разбираются в основах Kubernetes, деплоят и эксплуатируют свои сервисы;
    • Infrastructure team: поддерживают работоспособность (выкат, поддержку, масштабирование) Kubernetes-кластеров, обеспечение их всеми необходимыми ресурсами, а также консультируют инженеров организации по вопросам проектирования надёжных, производительных, отказоустойчивых сервисов (в частности, регулярно проводятся и обучающие тренинги, записи которых затем распространяются по всей компании).

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

    Другой важный момент эксплуатации — минимизация потенциального ущерба, который может прийти из разных источников. Вот что делают для этого в Reddit:



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

    • Wavefront — для метрик;
    • PagerDuty — для алертов;
    • Zipkin — для трассировки;
    • Sentry — для трекинга исключений и ошибок;
    • централизованная система логирования.

    Статус Kubernetes в Reddit


    Общая статистика по инфраструктуре Kubernetes на момент декабря прошлого года представлялась следующим образом:

    • 7 кластеров (от 3 до 6 новых должны были быть добавлены в несколько следующих месяцев);
    • от трети до половины всех инженерных команд взаимодействуют с Kubernetes;
    • около 20 сервисов Reddit находятся в production с K8s;
    • в рабочий день происходит по 10-20 деплоев этих сервисов в K8s.

    Доступность InfreRedd с Kubernetes для всей организации была запланирована на первый квартал 2019 года, что подразумевало деплой любого нового сервиса в production, обслуживаемый Kubernetes. (На тот момент это происходило примерно для 3 из 4 новых сервисов.)

    Как уже упоминалось в начале статьи, этот milestone был успешно достигнут буквально на прошлой неделе:



    Другие статьи из цикла


    • +29
    • 7,2k
    • 4
    Флант
    326,00
    Специалисты по DevOps и Kubernetes
    Поддержать автора
    Поделиться публикацией

    Комментарии 4

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


      Можно про это подробнее, как и где потом этот токен используется?
        0
        Вот с этого момента подробности рассказывают: youtu.be/z7TIzCAEo0M?t=1132

        P.S. У выступающего не самый легкий для быстрого восприятия английский, поэтому маякните, пожалуйста, если будете рады краткому текстовому переводу на русский здесь в комментариях.
          0
          Будем рады )
            +1
            В случаях, когда service owners требуется получить доступ к production, они пользуются внутренней консольной разработкой (под названием rkube) для инициации процесса аутентификации через OpenID Connect (см. также OpenID Connect Tokens в документации Kubernetes). По своей сути он очень похож на аналогичную реализацию в CLI-утилите gcloud для GCP (инженеры Reddit заимствовали всю идею оттуда).

            После успешной аутентификации в локальный конфиг (.kube/config) на машине разработчика записывается JSON Web Token. Этот токен имеет ограниченное (небольшое) время жизни. В нём содержится подписанный payload, в котором указано имя пользователя и его членство в группах. В свою очередь политики, настроенные на стороне Kubernetes-кластера, ориентированы на выдачу прав по этим самым группам.

            Поскольку для каждого сервиса создаётся своё пространство имён, дальнейшая задача — выдать service owner'ам полные права на нужные namespaces (т.е. соответствующие сервисам, которыми они владеют).

            Итог: service owners могут получить права на свои сервисы и только их.

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

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