На прошлой неделе было объявлено о том, что отныне все новые сервисы 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 был успешно достигнут буквально на прошлой неделе:
Другие статьи из цикла
- «Истории успеха Kubernetes в production. Часть 1: 4200 подов и TessMaster у eBay».
- «Истории успеха Kubernetes в production. Часть 2: Concur и SAP».
- «Истории успеха Kubernetes в production. Часть 3: GitHub».
- «Истории успеха Kubernetes в production. Часть 4: SoundCloud (авторы Prometheus)».
- «Истории успеха Kubernetes в production. Часть 5: цифровой банк Monzo».
- «Истории успеха Kubernetes в production. Часть 6: BlaBlaCar».
- «Истории успеха Kubernetes в production. Часть 7: BlackRock».
- «Истории успеха Kubernetes в production. Часть 8: Huawei».
- «Истории успеха Kubernetes в production. Часть 9: ЦЕРН и 210 кластеров K8s».
Автор: shurup
