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

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

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

О том, почему и как инженеры Reddit пришли к Kubernetes, на KubeCon 2018 в декабре прошлого года рассказал ^[3] (презентация ^[4] + видео ^[5]) 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 ^[6], который, впрочем, вряд ли кому-то пригодится для реального использования, но может стать вдохновением.

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

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

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

2. Деплой

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

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

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

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

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

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

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

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

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

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

Статус Kubernetes в Reddit

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

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

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

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

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

• «Истории успеха Kubernetes в production. Часть 1: 4200 подов и TessMaster у eBay ^[15]».
• «Истории успеха Kubernetes в production. Часть 2: Concur и SAP ^[16]».
• «Истории успеха Kubernetes в production. Часть 3: GitHub ^[17]».
• «Истории успеха Kubernetes в production. Часть 4: SoundCloud (авторы Prometheus) ^[18]».
• «Истории успеха Kubernetes в production. Часть 5: цифровой банк Monzo ^[19]».
• «Истории успеха Kubernetes в production. Часть 6: BlaBlaCar ^[20]».
• «Истории успеха Kubernetes в production. Часть 7: BlackRock ^[21]».
• «Истории успеха Kubernetes в production. Часть 8: Huawei ^[22]».
• «Истории успеха Kubernetes в production. Часть 9: ЦЕРН и 210 кластеров K8s ^[23]».

Автор: shurup

Источник ^[24]