На прошлой неделе было объявлено о том, что отныне все новые сервисы 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 был успешно достигнут буквально на прошлой неделе:



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


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


  1. maxim_ge
    26.02.2019 13:21

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


    Можно про это подробнее, как и где потом этот токен используется?


    1. shurup Автор
      26.02.2019 13:31

      Вот с этого момента подробности рассказывают: youtu.be/z7TIzCAEo0M?t=1132

      P.S. У выступающего не самый легкий для быстрого восприятия английский, поэтому маякните, пожалуйста, если будете рады краткому текстовому переводу на русский здесь в комментариях.


      1. gecube
        26.02.2019 21:52

        Будем рады )


        1. shurup Автор
          27.02.2019 08:05

          В случаях, когда 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 могут получить права на свои сервисы и только их.