Хабрахабр

[Перевод] Конвергенция с Kubernetes

Тотальная стандартизация

Он ответил: Я готовил этот материал для выступления на конференции и спросил у нашего технического директора, в чем главная фишка Kubernetes для нашей организации.

Разработчики сами не понимают, сколько лишней работы делали.

Видимо, его вдохновила недавно прочитанная книга «Factfulness» — сложно заметить незначительные и непрерывные изменения к лучшему, и мы постоянно упускаем из виду свой прогресс.

Но переход на Kubernetes точно нельзя назвать незначительным.

Примерно 70% нашего HTTP-трафика создается в приложениях на кластерах Kubernetes. Почти 30 наших команд запускают все или некоторые рабочие нагрузки на кластерах. NET и физических серверов на AWS и с монолитной системы на микросервисы. Наверное, это самая масштабная конвергенция технологий с моего прихода в компанию после того, как в 2010 году группа Forward купила uSwitch, когда мы перешли с .

В конце 2017 все команды использовали свою инфраструктуру AWS. И все произошло очень быстро. Прошло чуть больше года, и все изменилось. Они настраивали балансировщики нагрузки, экземпляры EC2, обновления кластеров ECS и все в таком духе.

Мы не меняли организацию, чтобы использовать Kubernetes. Мы потратили на конвергенцию минимум времени, и в итоге Kubernetes помог нам решить насущные проблемы — наше облако разрасталось, организация усложнялась, и мы с трудом вписывали в команды новых людей. Наоборот — мы использовали Kubernetes, чтобы изменить организацию.

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

Он открыл мне глаза. Много лет назад я был на конференции по Clojure и слышал лекцию Майкла Найгарда об архитектуре, которую нельзя привести в конечное состояние. Без нового ножа нечего и думать о салате. Аккуратная и упорядоченная система выглядит карикатурно, когда он сравнивает телемагазины с товарами для кухни и крупномасштабную архитектуру ПО — существующая система похожа на тупой нож, и выходит какая-то каша вместо ровных ломтиков.

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

наслоение перемен в некоем подобии стабильности.

И uSwitch отличный тому пример.

Мы перешли на AWS по многим причинам — наша система не справлялась с пиковыми нагрузками, а развитию организации мешала слишком жесткая система и тесно связанные друг с другом команды, которые формировались под конкретные проекты и разделялись по специализации.

Мы создавали новые сервисы с проксированием через существующий балансировщик нагрузки и постепенно душили старое приложение. Мы не собирались все бросить, перенести все системы и начать заново. В итоге мы взяли долгосрочные продукты и стали формировать под них команды из разработчиков, дизайнеров, аналитиков и т. Мы хотели сразу показать отдачу и в первую же неделю провели A/B-тестирование первой версии нового сервиса в продакшене. И сразу увидели результат. д. В 2010 году это казалось настоящей революцией.

Команды прогрессировали быстро — теперь они работали независимо друг от друга и состояли из специалистов во всех нужных областях. Год за годом мы добавляли новые команды, сервисы и приложения и постепенно «душили» монолитную систему. Мы выделили несколько команд только для конфигурации балансировщика нагрузки. Мы свели к минимуму взаимодействие команд для выпуска продукта.

Мы ставили перед ними задачу, и они сами находили решение, ведь они лучше всех разбирались в вопросе. Команды сами выбирали методы разработки, инструменты и языки. С AWS такие перемены стали проще.

Все это здорово описано в недавно вышедшей книге «Accelerate». Мы интуитивно следовали принципам программирования — слабо связанные друг с другом команды будут реже общаться, и нам не придется тратить драгоценные ресурсы на координацию их работы.

В итоге, как и описывал Майкл Найгард, у нас получилась система из множества слоев изменений — некоторые системы были автоматизированы c Puppet, некоторые с Terraform, где-то мы использовали ECS, где-то — EC2.

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

Но в 2017 году мы поняли, что многое изменилось.

Она предлагает массу вариантов и возможностей — но не без последствий. Сейчас инфраструктура AWS гораздо сложнее, чем в 2010. Сегодня любой команде, которая работает с EC2, приходится выбирать VPC, конфигурацию сети и еще много всего.

д. Мы испытали это на себе — команды стали жаловаться, что тратят все больше времени на обслуживание инфраструктуры, например обновление экземпляров в кластерах AWS ECS, EC2 машины, переход с балансировщиков ELB на ALB и т.

Я использовал избитую метафору про айсберг, чтобы показать, как мы создаем и обслуживаем ПО: В середине 2017 года на корпоративном мероприятии я призвал всех стандартизировать работу, чтобы повысить общее качество систем.

д. Я сказал, что большинство команд в нашей компании должно заниматься созданием сервисов или продуктов и сосредоточиться на решении задач, коде приложений, платформах и библиотеках и т. Под водой остается много работы — интеграция логов, повышение наблюдаемости, управление секретами и т. Именно в таком порядке. д.

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

Но не все сервисы AWS одинаковы. В основании пирамиды у нас была инфраструктура Amazon Web Services. И есть другие, относительно низкоуровневые сервисы, например EC2. У них есть Backend-as-a-Service (BaaS), например для аутентификации и хранения данных. Я хотел изучить данные и понять, что у команд есть основания жаловаться и они действительно тратят больше времени на работу с низкоуровневыми сервисами и принимают множество не самых важных решений.

Рост для таких сервисов, как RDS, Redshift и т. Я разделил сервисы на категории, с помощью CloudTrail собрал всю доступную статистику, а потом использовал BigQuery, Athena и ggplot2, чтобы увидеть, как изменилось положение дел для разработчиков за последнее время. мы считаем желаемым (и ожидаемым), а рост для EC2, CloudFormation и т. д. — наоборот. д.

Я добавил сглаживающие линии, чтобы показать тренд. Каждая точка на диаграмме показывает 90-й (красный), 80-й (зеленый) и 50-й (синий) процентили для количества низкоуровневых сервисов, которые наши люди использовали каждую неделю в течение определенного периода.

За два года число служб удвоилось для 50% сотрудников и почти утроилось для 20%. И хотя мы стремились к высокоуровневым абстракциям при развертывании ПО, например, с помощью контейнеров и Amazon ECS, наши разработчики регулярно использовали все больше и больше служб AWS и недостаточно абстрагировались от сложностей управления системами.

Команды стремились к автономности, но как при этом нанимать новых людей? Это ограничивало рост нашей компании. Нам нужны были сильные разработчики приложений и продуктов и знания об усложняющейся системе AWS.

Мы хотели расширять команды и при этом сохранить принципы, с которыми добились успеха: автономность, минимальная координация и самообслуживаемая инфраструктура.

С Kubernetes мы достигли этой цели благодаря абстракциям с фокусом на приложения и возможности обслуживать и настраивать кластеры для минимальной координации команд.

Абстракции с фокусом на приложения

Допустим, вы управляете версиями приложений в виде развертывания. Концепции Kubernetes легко сопоставить с языком, который использует разработчик приложения. А через пользовательские ресурсы можно расширять и специализировать этот язык в зависимости от того, что вам нужно. Вы можете запустить несколько реплик за сервисом и сопоставить их с HTTP через Ingress.

В принципе, в этом примере есть все необходимое для развертывания и запуска веб-приложения. С этими абстракциями команды работают продуктивнее. Остальным занимается Kubernetes.

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

Мне кажется, отсутствие общих концепций серьезно мешало работе этой команды. В 2010 году в uSwitch были традиционные команды для обслуживания монолитной системы, а совсем недавно у нас был ИТ-отдел, который частично управлял нашим аккаунтом AWS.

Описать суть приложения было сложно или даже невозможно. Попробуйте сказать что-то полезное, если у вас в словарном запасе одни экземпляры EC2, балансировщики нагрузки и подсети. Мы не могли описать приложение на общем для всех языке. Это мог быть пакет Debian, развертывание через Capistrano и так далее.

На собеседовании мне посоветовали прочитать «Проблемно-ориентированное проектирование» Эрика Эванса. В начале 2000-х я работал в лондонском ThoughtWorks. С тех пор я вспоминаю о ней почти в каждом проекте и системе. Я купил книгу по пути домой и начал читать еще в поезде.

Kubernetes как раз обеспечивает такой единый язык для разработчиков и команд по обслуживанию инфраструктуры, и это одно из главных его преимуществ. Одна из главных концепций книги — единый язык, на котором общаются разные команды. Плюс его можно расширять и дополнять другими предметными областями и направлениями бизнеса.

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

Необходимый минимум взаимодействия

Авторы книги «Accelerate» выделяют характеристики слабосвязанной архитектуры, с которой ИТ-команды работают эффективнее:

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

Идеала мы пока не достигли, но стараемся как можем: Нам нужны были централизованные программные мультитенантные кластеры для всех команд, но при этом мы хотели сохранить эти характеристики.

  • У нас есть несколько рабочих кластеров, и команды сами выбирают, где запускать приложение. Мы пока не используем федерацию (ждем поддержки AWS), зато у нас есть Envoy для балансировки нагрузки на балансировщиках Ingress в разных кластерах. Большую часть этих задач мы автоматизируем с помощью конвейера непрерывной поставки (у нас это Drone) и других сервисов AWS.
  • У всех кластеров одинаковые пространства имен. Примерно по одному на каждую команду.
  • Доступ к пространствам имен мы контролируем через RBAC (управление доступом на основе ролей). Для аутентификации и авторизации мы используем корпоративное удостоверение в Active Directory.
  • Кластеры масштабируются автоматически, и мы делаем все возможное, чтобы оптимизировать время запуска узла. На это все равно уходит пара минут, но, в целом, даже при больших рабочих нагрузках мы обходимся без координации.
  • Приложения масштабируются автоматически на базе метрик на уровне приложения из Prometheus. Команды разработчиков управляют автоматическим масштабированием своего приложения по метрикам запросов в секунду, операций в секунду и т. д. Благодаря автомасштабированию кластера система подготавливает узлы, когда спрос превышает возможности текущего кластера.
  • Мы написали в Go инструмент командной строки под названием u, который стандартизирует аутентификацию команд в Kubernetes, использование Vault, запросы временных учетных данных AWS и так далее.

Не уверен, что с Kubernetes автономности у нас стало больше, но она определенно осталась на высоком уровне, и при этом мы избавились от некоторых проблем.

На диаграмме показано общее количество пространств имен (примерно равное количеству команд) в наших рабочих кластерах. Переход на Kubernetes был быстрым. Первый появился в феврале 2017 года.

У нас были причины торопиться — мы хотели избавить небольшие команды, сосредоточенные на своем продукте, от забот об инфраструктуре.

Переход занял всего несколько дней, и они снова занялись делом. Первая команда согласилась перейти на Kubernetes, когда на их сервере приложений закончилось место из-за неправильной настройки logrotate.

Кластеры Kubernetes упрощают интеграцию с нашей системой управления секретами (Hashicorp Vault), распределенной трассировкой (Google Cloud Trace) и подобными инструментами. В последнее время команды переходят на Kubetnetes ради улучшенных инструментов. Все наши команды получают еще больше эффективных функций.

А вот продолжение этой диаграммы по сегодняшний день. Я уже показывал диаграмму с процентилями количества служб, которые наши сотрудники использовали каждую неделю с конца 2014 по 2017 годы.

Радует, что теперь у половины сотрудников дела идут так же, как в начале 2015 года. Мы достигли прогресса в управлении сложной структурой AWS. Но я надеюсь на подвижки и здесь. В команде облачных вычислений у нас 4–6 сотрудников, где-то 10% от общего числа — неудивительно, что 90-й процентиль почти не сдвинулся с места.

Наконец я расскажу о том, как изменился наш цикл разработки, и снова вспомню недавно прочитанную книгу Accelerate.

Время выполнения считается от запроса до доставки готового решения. В книге упоминается два показателя бережливой разработки: время выполнения и размер пакета. Чем меньше размер пакета, тем эффективнее работа: Размер пакета — это объем работы.

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

В книге предлагается измерять размер пакетов частотой развертывания — чем чаще развертывание, тем меньше пакеты.

Данные не совсем точные — некоторые команды отправляют выпуски прямо в главную ветвь репозитория, некоторые используют другие механизмы. У нас есть данные для некоторых развертываний. Сюда входят не все приложения, но данные за 12 месяцев можно считать показательными.

В остальном мы видим, что частота развертывания возрастает, а значит размер пакета уменьшается. Провал на тридцатой неделе — это Рождество. С марта по май 2018 частота выпусков почти удвоилась, а в последнее время мы иногда делаем больше ста выпусков в день.

Скорее всего, на частоту выпусков повлияли все эти факторы. Переход на Kubernetes — это только часть нашей стратегии стандартизации, автоматизации и усовершенствования инструментов.

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

Традиционно считается, что при расширении команды повышается общая производительность, но падает индивидуальная производительность разработчика.

Если взять те же данные о частоте развертываний и составить диаграмму зависимости от количества пользователей, видно, что мы можем увеличивать частоту выпусков, даже если у нас будет больше людей.

Переход на Kubernetes стал для наших разработчиков самой значимой и быстрой конвергенцией технологий. В начале статьи я упомянул книгу «Factfulness» (которая вдохновила нашего технического директора). Хорошо, что у нас есть данные, и они показывают, что мы добились желаемого, — наши люди занимаются своим продуктом и принимают важные решения в своей сфере. Мы двигаемся маленькими шажками, и легко не заметить, насколько все изменилось к лучшему.

У нас были микросервисы, AWS, устоявшиеся команды под продукты, разработчики, отвечающие за свои сервисы в продакшене, слабосвязанные команды и архитектура. Раньше нам и так было неплохо. Но нет предела совершенству. Я говорил об этом в докладе «Our Age of Enlightenment» («Наш эпоха просвещения») на конференции в 2012 году.

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

Поэтому для поддержания жизни мы должны все время есть, чтобы победить неизбежную энтропию.
Мы боремся с энтропией, поставляя больше энергии для роста, инноваций, обслуживания и ремонта, который становится все сложнее по мере старения системы, и эта битва лежит в основе любых серьезных дискуссий о старении, смертности, устойчивости и самодостаточности любых систем, будь то живой организм, компания или общество. Чтобы поддерживать порядок и структуру в развивающейся системе, нужен постоянный приток энергии, а она порождает беспорядок.

Надеюсь, наши последние усилия еще хоть ненадолго сдержат энтропию. Думаю, сюда же можно добавить ИТ-системы.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть