shurup 26 фев 2019 в 11:40

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

5 мин

11K

Блог компании ФлантСистемное администрирование*IT-инфраструктура*DevOps*Kubernetes*

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

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

Теги:

Хабы: