Предисловие

Проект Kubernetes произвел настоящую революцию в индустрии. Чтобы понять важность Kubernetes в современных условиях, достаточно взглянуть на страницу Cloud Native Computing Foundation’s Landscape (landscape.cncf.io), где представлены данные о более чем 600 проектах, существующих в облачном мире на сегодняшний день. Не все эти инструменты были разработаны для Kubernetes и не все из них можно использовать вместе с этой платформой, но все они являются частью огромной экосистемы, в которой Kubernetes — одна из ведущих технологий.

Появление платформы Kubernetes позволило изменить принцип разработки и администрирования приложений: в настоящее время это ключевой компонент в мире DevOps. Благодаря ей разработчики получают гибкость, а администраторы — свободу. Kubernetes можно использовать вместе с любым крупным облачным провайдером, в локальных средах с физической инфраструктурой, а также на отдельном компьютере разработчика. Стабильность, гибкость, мощные интерфейсы прикладного программирования (API), открытый исходный код и активное сообщество разработчиков — это не полный перечень достоинств, благодаря которым данный продукт стал отраслевым стандартом аналогично тому, как Linux стала стандартом в мире операционных систем.

Это замечательное руководство для тех, кто ежедневно работает с Kubernetes или только начинает с ней знакомиться. Джон и Джастин охватили все основные аспекты развертывания, конфигурирования и администрирования Kubernetes, а также учли передовой опыт разработки и выполнения приложений на этой платформе. В то же время вы получите отличный обзор сопутствующих технологий, включая Prometheus и Helm, а также изучите непрерывное развертывание. Таким образом, книга обязательна к прочтению для всех, кто работает в сфере DevOps.

Kubernetes не просто еще один интересный инструмент — это отраслевой стандарт и фундамент для технологий следующего поколения, таких как бессерверные платформы (OpenFaaS, Knative) и машинное обучение (Kubeflow). Благодаря облачной революции меняется вся индустрия информационных технологий, и быть частью этого процесса невероятно захватывающе.

Игорь Дворецкий, Developer Advocate, Cloud Native Computing Foundation, декабрь 2018

Введение

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

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

Чему вы научитесь

Вы узнаете, что такое платформа Kubernetes, откуда она взялась и как в будущем она повлияет на администрирование и разработку ПО, как работают, собираются и управляются контейнеры, как проектировать облачно-ориентированные сервисы и инфраструктуру.

Вы оцените преимущества и недостатки самостоятельного построения и размещения кластеров Kubernetes и использования управляемых сервисов. Поймете возможности и ограничения, а также плюсы и минусы популярных инструментов для установки Kubernetes, таких как kops, kubeadm и Kubespray. Кроме того, получите обоснованный обзор основных решений для управления данной платформой от Amazon, Google и Microsoft.

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

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

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

Для кого предназначена книга

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

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

На какие вопросы отвечает книга

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

• «Меня интересует, почему следует тратить время на эту технологию. Какие проблемы она поможет решить мне и моей команде?»

• «Kubernetes кажется интересной, но имеет довольно высокий порог вхождения. Подготовить простой пример не составляет труда, но дальнейшие администрирование и отладка пугают. Мы бы хотели получить надежные советы о том, как люди управляют кластерами Kubernetes в реальных условиях и с какими проблемами мы, скорее всего, столкнемся».

• «Был бы полезен субъективный совет. Экосистема Kubernetes предлагает начинающим командам слишком много вариантов на выбор. Когда одно и то же можно сделать несколькими способами, как понять, какой из них лучше? Как сделать выбор?»

И, наверное, наиболее важный из всех вопросов:

• «Как использовать Kubernetes, не нарушая работу моей компании?»

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

Условные обозначения

В этой книге вы встретите следующие типографские обозначения.

Рубленый шрифт

Используется для выделения URL-адресов и адресов электронной почты.

Курсивный шрифт

Используется для выделения новых терминов и понятий, на которых сделан акцент.

Моноширинныйшрифт

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

Полужирный моноширинный шрифт

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

Курсивный моноширинный шрифт

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

Этот значок обозначает совет или предложение.

Этот значок обозначает примечание общего характера.

Этот значок обозначает предупреждение или предостережение.

Использование примеров кода

Дополнительный материал (примеры кода, упражнения и т.д.) доступен для загрузки по адресу github.com/cloudnativedevops/demo.

Предназначение этой книги — помочь в решении ваших задач. Если предлагается какой-то пример кода, его разрешается использовать в ваших программах и документации. Связываться с нами, если вы не воспроизводите его существенную часть, не нужно: например, в ситуации, когда вы включаете в свою программу несколько фрагментов кода, приведенного здесь. Однако продажа или распространение CD-ROM с примерами из книг издательства O’Reilly требует отдельного разрешения. Цитировать эту книгу с примерами кода при ответе на вопрос вы можете свободно, но если хотите включить существенную часть приведенного здесь кода в документацию своего продукта, вам следует связаться с нами.

Мы приветствуем ссылку на оригинал, но не требуем ее. Ссылка обычно состоит из названия, имени автора, издательства, ISBN. Например, «“Kubernetes для DevOps: развертывание, запуск и масштабирование в облаке”, Джон Арундел и Джастин Домингус. Питер, 2020. 9785446116027».

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

Благодарности

Мы благодарны многим людям, которые читали черновики этой книги и поделились с нами своими бесценными мнениями и советами, а также помогли нам каким-то другим образом (список может быть неполным): это Эбби Бангсер, Адам Дж. Макпартлен, Адриенна Домингус, Алексис Ричардсон, Эрон Трауринг, Камилла Монтонен, Габриель Насименто, Ханна Клемме, Ганс Финдель, Йан Кросби, Йан Шау, Игорь Дворецкий, Айк Деволдер, Джереми Йейтс, Джером Петаззони, Джессика Дин, Джон Харрис, Джон Барбер, Китти Карат, Марко Ланцини, Марк Элленс, Мэтт Норт, Мишель Бланк, Митчелл Кент, Николас Штейнметц, Найджел Браун, Патрик Дудич, Пол ван дер Линден, Филип Энсаргет, Пьетро Мамберти, Ричард Харпер, Рик Хайнесс, Сатьяджит Бхат, Суреш Вишной, Томас Лиакос, Тим Макгиннис, Тоби Сулливан, Том Холл, Винсент Де Смет и Уилл Теймс.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

1. Революция в облаке

У мира никогда не было момента начала, поскольку он идет по кругу, а у круга нет такого места, где бы он начинался.

Алан Уотс

Прямо сейчас происходит революция. Точнее, три революции.

Первая — создание облака: мы объясним, что это такое и почему это важно.

Вторая — расцвет DevOps: вы узнаете, с чем это связано и как это меняет сферу системного администрирования.

Третья — появление контейнеров. Вместе они формируют новый мир программного обеспечения — облачно-ориентированный мир. И его операционная система называется Kubernetes.

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

Мы считаем, что благодаря эффектам от этих трех взаимосвязанных революций будущее компьютерных вычислений принадлежит облачным контейнеризированным распределенным системам, которые динамически управляются путем автоматизации на платформе Kubernetes (или на чем-то очень похожем). Искусство разработки и выполнения этих приложений — облачно-ориентированный DevOps — это то, что мы будем исследовать на остальных страницах этой книги.

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

Создание облака

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

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

Может показаться, что мы говорим о современности, а не о прошлом столетии, и это не случайно. Слово «революция» означает «круговое движение», и индустрия вычислений в каком-то смысле вернулась к тому, с чего начиналась. С годами компьютеры стали куда более мощными (современные часы Apple Watch эквивалентны примерно трем мейнфреймам, изображенным на рис. 1.1), но разделяемый доступ к вычислительным ресурсам с платой за использование является очень старой идеей. В наши дни мы называем это облаком, и революция, у истоков которой стоя­ли мейнфреймы с разделением времени, вернулась в исходную точку.

Покупаем время

Основная идея облака такова: вместо покупки компьютера вы покупаете вычисления. Иными словами, вместо крупных капиталовложений в физическое оборудование, которое сложно масштабировать, которое легко ломается и быстро устаревает, вы просто покупаете время на компьютере, принадлежащем другим людям, и снимаете с себя заботы о масштабировании, обслуживании и обновлении. Во времена «железных» серверов (назовем их «железным веком») вычислительная мощь требовала капитальных расходов. Теперь это операционные расходы, в чем и состоит разница.

 

Рис. 1.1. Один из первых облачных компьютеров: IBM System/360 Model 91 в Центре космических полетов Годдарда, НАСА

Облако — это не просто удаленные арендуемые вычислительные ресурсы; это также распределенные системы. Вы можете купить непосредственно вычислительный ресурс (такой как сервер Google Compute или функция AWS Lambda) и использовать его для запуска собственного программного обеспечения, но все чаще вы будете арендовать облачные сервисы, а в сущности, доступ к чужому ПО. Например, если вы применяете PagerDuty для мониторинга своих систем и оповещения в случае каких-то сбоев, вы уже используете облачный сервис — то, что называется программное обеспечение как услуга (software as a service, SaaS).

Инфраструктура как услуга

Когда вы используете облачную инфраструктуру для запуска собственных сервисов, вы покупаете инфраструктуру как услугу (infrastructure as a service, IaaS). Она не требует капиталовложений, вам не нужно ее собирать или обновлять. Это всего лишь товар — как электричество или вода. Облачные вычисления совершили революцию во взаимоотношениях между бизнесом и его информационной инфраструктурой.

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

Облачная революция полностью изменила то, как люди используют облака: речь идет о движении DevOps.

Расцвет DevOps

До появления DevOps разработка и системное администрирование ПО представляли собой, в сущности, два отдельных направления, и занимались ими две разные группы людей. Разработчики (developers) писали код и передавали его коллегам-администраторам (operations), которые занимались запуском и эксплуатацией этого кода (то есть предоставляли услуги реальным пользователям, а не просто работали в режиме тестирования). Как и размещение компьютеров на отдельном этаже, это разделение корнями уходит в середину прошлого века. Написание программного обеспечения было узкоспециализированным направлением, равно как и администрирование компьютеров. И пересекались они редко.

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

 

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

Более того, в наши дни под системой подразумевается не только ваш код: это и внутреннее ПО, и облачные сервисы, и сетевые ресурсы, и балансировщики нагрузки, и инструменты мониторинга, и сети доставки содержимого, и брандмауэры, и DNS и т.д. Все эти компоненты тесно связаны между собой и зависят друг от друга. Люди, пишущие программное обеспечение, должны понимать, как оно соотносится с остальной частью системы, а люди, администрирующие систему, должны понимать, как это ПО работает (или не работает).

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

Никто не понимает DevOps

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

Кроме того, по-прежнему нет окончательного понимания, что же такое на самом деле DevOps: должность? Методология? Набор навыков? Джон Уиллис, авторитетный автор книг о DevOps, определяет четыре ключевых аспекта, на которых основана данная концепция: культура, автоматизация, измерение и обмен знаниями (culture, automation, measurement, sharing, вместе CAMS). Брайан Доусон предлагает другое определение, которое он называет троицей DevOps: люди и культура, процесс и практика, инструменты и технологии.

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

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

Благодаря DevOps большая часть традиционного системного администрирования выполняется до того, как код достигает промышленной среды. Выпуск каждой версии подразумевает мониторинг, ведение журнала и A/B-тестирование. Конвейеры CI/CD автоматически выполняют модульные тесты, сканирование безопасности и проверку политик при каждой фиксации изменений. Развертывание происходит автоматически. Контроль, задачи и нефункциональные требования теперь прорабатываются перед выпуском версии, а не во время или после критического сбоя в работе.

Джордан Бах (AppDynamics)1

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

Неважно, как это выглядит на первый взгляд, но проблема всегда в людях.

Джеральд М. Вайнберг. Закон малинового варенья и еще 103 секрета консалтинга

Бизнес-преимущество

С точки зрения бизнеса DevOps имеет следующее описание: «Улучшение качества ПО путем ускорения цикла выпуска версий с помощью облачных методик и автоматизации и с дополнительным преимуществом в виде того, что программное обеспечение на самом деле продолжает работать в промышленных условиях» (The Register, www.theregister.co.uk/2018/03/06/what_does_devops_do_to_decades_old_planning_processes_and_assumptions).

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

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

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

Брайан Доусон (Cloudbees) (Computer Business Review)2

Инфраструктура как код

Когда-то давным-давно разработчики занимались программным обеспечением, а команды системных администраторов отвечали за оборудование и операционные системы, которые на нем работают.

Теперь, когда оборудование находится в облаке, все в каком-то смысле перешло на программный уровень. Движение DevOps привносит навыки написания ПО в мир системного администрирования: дает инструменты и рабочие процессы для быстрого и динамичного совместного построения сложных систем. С этой концепцией неразрывно переплетается идея инфраструктуры как кода.

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

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

Учимся вместе

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

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

• Как развертывать и обновлять программное обеспечение в огромных разнородных сетях с разными серверными архитектурами и операционными системами?

• Как выполнять развертывание в распределенных средах надежным и воспроизводимым образом, используя в основном стандартизированные компоненты?

Мы подошли к третьей революции: к появлению контейнеров.

Пришествие контейнеров

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

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

Последние веяния

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

В качестве альтернативы некоторые языки предоставляют собственные механизмы управления пакетами, такие как JAR-файлы в Java, eggs в Python и gems в Ruby. Однако они работают в пределах одного конкретного языка и не могут полностью решить проблему зависимостей — например, прежде, чем вы сможете запустить JAR-файл, вам все равно нужно установить среду выполнения Java.

Еще одним решением является универсальный (omnibus) пакет, который, как следует из его названия, пытается вместить все нужное приложению в единый файл. Такой пакет содержит программное обеспечение, его конфигурацию, программные компоненты, от которых оно зависит, их конфигурацию, их зависимости и т.д. (например, универсальный пакет Java содержал бы среду выполнения JRE, а также все JAR-файлы для приложения).

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

Как системному администратору, вам придется управлять не только разными форматами пакетов, но и целой флотилией серверов, на которых они будут выполняться.

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

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

«Коробочное» мышление

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

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

Фирма Маклина по транспортировке контейнеров Sea-Land внедрила эту систему и стала очень успешной благодаря значительному снижению стоимости на доставку товаров. Контейнеры быстро приобрели популярность (www.freightos.com/the-history-of-the-shipping-container). Сегодня каждый год перевозятся сотни миллионов контейнеров с товарами стоимостью триллионы долларов.

 

Рис. 1.3. Контейнеры существенно снизили стоимость транспортировки товаров в больших объемах (фото Pixabay, www.pexels.com/@pixabay, под лицензией Creative Commons 2.0)

Размещение программного обеспечения в контейнерах

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

Чем это отличается от образа виртуальной машины? Тот тоже содержит все необходимое для работы приложения — но еще и много чего сверх. Типичный образ занимает около 1 ГиБ3. Для сравнения: хорошо спроектированный образ контейнера может оказаться в сто раз меньше.

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

Что еще хуже, виртуальные машины по-настоящему виртуальные: внутреннее физическое оборудование, в сущности, реализует эмулируемый центральный процессор, на котором выполняется виртуальная машина. Слой виртуализации оказывает существенное отрицательное воздействие на производительность (www.stratoscale.com/blog/containers/running-containers-on-bare-metal): при тестировании виртуализированные рабочие задания выполняются на 30 % медленнее, чем в аналогичных контейнерах.

Для сравнения: контейнеры работают непосредственно на реальном ЦПУ и без дополнительных расходов на виртуализацию — точно так же, как обычные исполняемые файлы.

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

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

Среда выполнения контейнеров соберет все необходимые слои и загрузит только те из них, которые еще не закэшированы локально. Это делает использование ди­скового пространства и пропускной способности сети крайне эффективным.

Динамически подключаемые приложения

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

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

Просто поместите свое приложение в образ контейнера, и оно сможет работать на любой платформе, которая поддерживает стандартный формат контейнеров и имеет совместимое ядро.

В своей статье «Шаблоны проектирования для контейнерных распределенных систем» (https://www.usenix.org/node/196347) разработчики Kubernetes Брендан Бернс и Дэвид Оппенгеймер выразили эту концепцию следующим образом:

Будучи герметично запечатаны, сохраняя в себе свои зависимости и предоставляя атомарный сигнал развертывания («успех»/«провал»), контейнеры значительно улучшили средства для развертывания ПО в вычислительных центрах и облаке. Однако контейнеры имеют потенциал стать чем-то значительно большим, чем просто усовершенствованный механизм развертывания, — мы считаем, что им суждено быть аналогом объектов в объектно-ориентированных программных системах. Тем самым они приведут к развитию шаблонов проектирования распределенных систем.

Дирижирование оркестром контейнеров

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

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

Третьей важной задачей управления кластером является объединение нескольких физических или виртуальных серверов в унифицированную, надежную, отказо­устойчивую и довольно цельную группу.

Термин «оркестратор контейнеров» обычно относится к одному сервису, который занимается планированием и оркестрацией кластера, а также управлением им.

Контейнеризация (использование контейнеров в качестве стандартного метода развертывания и запуска ПО) имеет очевидные преимущества, а стандарт де-факто формата контейнеров позволяет экономить на масштабе самыми разными способами. При всем этом на пути широкого внедрения контейнеров стояла одна преграда: отсутствие стандартной системы оркестрации.

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

Kubernetes

Компания Google использовала контейнеры в крупных масштабах и с промышленными нагрузками задолго до кого бы то ни было. Почти все ее сервисы работали в контейнерах: Gmail, Google Search, Google Maps, Google App Engine и т.д. Поскольку в то время не существовало подходящей системы оркестрации контейнеров, разработчикам Google пришлось ее изобрести.

От Borg до Kubernetes

Чтобы решить проблему запуска большого количества сервисов в глобальном масштабе на миллионах серверов, компания Google разработала закрытую, внутреннюю систему оркестрации контейнеров под названием Borg (pdos.csail.mit.edu/6.824/papers/borg.pdf).

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

В 2014 году компания Google основала открытый проект под названием Kubernetes (от греческого слова

— «рулевой, пилот»). В его рамках планировалось разработать оркестратор контейнеров, доступный для всеобщего использования, который был бы основан на уроках, извлеченных из деятельности Borg и ее преемницы Omega (ai.google/research/pubs/pub41684.pdf).

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

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

Что делает платформу Kubernetes такой ценной

Келси Хайтауэр, штатный сотрудник Google, соавтор книги Kubernetes Up & Running (O’Reilly) и просто легенда в сообществе Kubernetes, дает такой ответ:

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

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

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

Kubernetes облегчает развертывание

За это платформу любят администраторы. Однако и разработчикам она дает некоторые существенные преимущества: значительно сокращает затраты времени и сил на развертывание. Благодаря тому что Kubernetes выполняет плава­ющие обновления по умолчанию, приобрели популярность развертывания с нулевым временем простоя (сначала запускаются контейнеры с новой версией, и после того, как они станут работоспособными, выключаются старые версии).

Kubernetes также предоставляет средства, которые помогают реализовать методики непрерывного развертывания, такие как канареечные обновления: речь о постепенном выкатывании обновлений сервер за сервером для выявления проблем на ранних стадиях (см. подраздел «Канареечные развертывания» на с. 306). Еще одной общепринятой практикой являются сине-зеленые развертывания: параллельный запуск новой версии системы и переключение трафика по мере ее готовности (см. подраздел «Сине-зеленые развертывания» на с. 305).

Скачки нагрузки больше не выведут ваш сервис из строя, потому что Kubernetes поддерживает автомасштабирование. Например, если использование ЦПУ контейнером достигнет определенного уровня, система сможет добавлять новые копии этого контейнера до тех пор, пока показатель не опустится ниже предельного значения. Когда нагрузка снизится, Kubernetes снова уменьшит количество копий, освобождая ресурсы кластера для выполнения других задач.

Поскольку избыточность и отказоустойчивость встроены в Kubernetes, ваше приложение будет более надежным и устойчивым. Некоторые управляемые сервисы могут даже масштабировать вверх и вниз сам кластер Kubernetes в зависимости от нагрузки: благодаря этому вы всегда будете платить только за те ресурсы, которые вам нужны в тот или иной момент (см. пункт «Автомасштабирование» на с. 145).

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

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

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

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

Не исчезнет ли Kubernetes?

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

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

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

Точно так же Kubernetes станет настолько стандартной частью инфраструктуры, что о ее наличии внутри вы даже не будете знать.

Kubernetes не решает все проблемы

Будет ли инфраструктура будущего полностью базироваться на Kubernetes? Наверное, нет. Прежде всего, Kubernetes просто не очень хорошо подходит для некоторых структур (таких как базы данных).

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

Шон Луизель (Cockroach Labs)4

В Kubernetes вполне возможно выполнять рабочие задания с сохранением состояния, получая при этом надежность на корпоративном уровне. Но это требует времени и инженерных усилий, которые могут оказаться чрезмерными для вашей компании (см. подраздел «Не используйте слишком много ПО» на с. 82). Обычно лучшим решением является использование управляемых сервисов.

К тому же некоторые задачи не требуют Kubernetes и могут работать на платформах, которые иногда называют бессерверными (serverless). У них есть более подходящее название: функции как сервис (functions as a service, FaaS).

Облачные функции и фунтейнеры

В качестве примера платформы FaaS можно привести AWS Lambda. Она позволяет выполнять код, написанный на Go, Python, Java, Node.js, C# и других языках, не требуя при этом никакой компиляции или развертывания вашего приложения. Amazon сделает это все за вас.

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

Облачные функции в некоторых случаях более удобны, чем контейнеры (хотя контейнеры могут работать и на некоторых платформах FaaS). Но лучше всего они подходят для коротких автономных задач (например, AWS Lambda ограничивает время выполнения функций 15 минутами, позволяя разворачивать файлы общим размером примерно 50 Мбайт), особенно если те интегрированы с существующими облачными вычислительными сервисами, такими как Microsoft Cognitive Services или Google Cloud Vision API.

Почему нам не нравится называть эту модель бессерверной? Потому что она таковой не является: вы по-прежнему используете сервер, просто не свой, а чужой. Суть в том, что этот сервер вам не нужно выделять и обслуживать — облачный провайдер берет работу на себя.

Конечно же, не всякое рабочее задание подходит для выполнения на платформах FaaS, однако в будущем данная технология, вероятно, станет ключевой для облачно-ориентированных приложений.

Следует также отметить, что облачные функции не ограничиваются публичными платформами FaaS, такими как Lambda или Azure Functions: если у вас уже есть кластер Kubernetes и вы хотите запускать на нем FaaS-приложения, это можно сделать с помощью OpenFaaS (www.openfaas.com) и других открытых проектов. Такой гибрид функций и контейнеров иногда называют фунтейнерами (funtainers). Нам этот термин кажется симпатичным.

У Kubernetes есть более продвинутая платформа доставки ПО — Knative, которая вобрала в себя как контейнеры, так и облачные функции (см. подраздел «Knative» на с. 302). На сегодняшний день она находится на стадии активной разработки. Это многообещающий проект, который в будущем может размыть или вовсе стереть границу между контейнерами и функциями.

Облачная ориентированность

Термин «облачно-ориентированный» (cloud native) становится все более популярным сокращением, которое описывает современные приложения и сервисы, пользующиеся преимуществами облаков, контейнеров и оркестрации (часто с открытым исходным кодом).

В самом деле, в 2015 году была основана организация Cloud Native Computing Foundation, или CNCF (www.cncf.io), обязанная, по утверждению основателей, «сформировать сообщество вокруг набора высококачественных проектов, которые оркестрируют контейнеры в рамках микросервисной архитектуры».

Являясь частью Linux Foundation, CNCF объединяет разработчиков, конечных пользователей и поставщиков, в том числе основных публичных облачных провайдеров. Самым известным проектом под эгидой CNCF является сама Kubernetes, но эта организация также взращивает и продвигает множество других ключевых компонентов облачно-ориентированной экосистемы: Prometheus, Envoy, Helm, Fluentd, gRPC и т.д.

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

Облачно-ориентированные приложения работают в облаке, с этим никто не спорит. Но если мы возьмем существующее приложение и просто запустим его на облачном вычислительном сервере, от этого оно не станет облачно-ориентированным. То же самое можно сказать о запуске в контейнере или использовании таких облачных сервисов, как Cosmos DB от Azure или Pub/Sub от Google. Хотя это можно назвать важными аспектами облачной ориентированности.

Рассмотрим несколько характеристик облачно-ориентированных систем, с которыми может согласиться большинство людей.

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

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

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

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

• Наблюдаемость. Облачно-ориентированные приложения по своей природе труднее поддаются исследованию и отладке. Поэтому наблюдаемость является ключевым требованием к распределенным системам: мониторинг, ведение журнала, трассирование и сбор показателей помогают инженерам понять, чем занимаются их системы (и что они делают не так).

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

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

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

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

Будущее системного администрирования

Системное администрирование и проектирование инфраструктуры — это работа, требующая высокой квалификации. Ставит ли ее под угрозу облачно-ориентированное будущее? Мы считаем, что нет.

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

Это не значит, что все текущие позиции системных администраторов останутся нетронутыми. Когда-то сисадминам не требовались навыки программирования, если не считать программированием создание крайне простых скриптов командной оболочки. В облаке такое не пройдет.

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

Распределенный DevOps

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

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

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

Некоторые элементы останутся централизованными

Есть ли у DevOps предел? Или традиционные централизованные отделы IT и системного администрирования полностью исчезнут, превратившись в группу внутренних консультантов, которые обучают персонал и решают инфраструктурные задачи?

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

Планирование продуктивности разработчиков

Суть в том, что у самообслуживания есть свои пределы, и DevOps нацелен на повышение продуктивности разработчиков, а не на замедление их работы за счет дополнительных и ненужных обязанностей.

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

Вместо системного администрирования (operations) мы предпочитаем говорить о планировании продуктивности разработчиков (developer productivity engineering, или DPE). Команды DPE делают все необходимое для того, чтобы разработчики могли выполнять свои обязанности лучше и быстрее: управляют инфраструктурой, создают инструменты, решают проблемы.

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

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

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

Мэтт Клейн

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

Вы — будущее

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

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

Теперь читайте дальше.

Резюме

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

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

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

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

• DevOps также ставит код во главу угла и делает доступными проверенные методики разработки ПО в мире инфраструктуры и системного администрирования.

• Контейнеры позволяют развертывать и запускать ПО в виде небольших самодостаточных модулей. Это облегчает и удешевляет построение крупных разносторонних распределенных систем за счет объединения контейнеризированных микросервисов.

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

• Kubernetes является стандартом де-факто системы оркестрации контейнеров и уже сегодня готова к использованию в промышленных условиях.

• Термин «облачно-ориентированный» удобен для разговора об облачных контейнеризированных распределенных системах, состоящих из взаимодействующих микросервисов, которые, словно код, динамически управляются автоматизированной инфраструктурой.

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

• Построение и обслуживание платформ и инструментов, которые делают DevOps возможным во всех остальных командах, все еще имеет смысл поручать отдельной центральной команде.

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

2. Первые шаги с Kubernetes

Чтобы сделать что-то по-настоящему стоящее, мне надо не отступать и трястись при мыслях о холоде и опасности, а с радостью дерзать и идти вперед изо всех сил.

Ог Мандино

Хватит теории, давайте начнем работать с Kubernetes и контейнерами. В этой главе вы создадите простое контейнеризированное приложение и развернете его в локальном кластере Kubernetes, запущенном на вашем компьютере. По ходу вы познакомитесь с некоторыми очень важными облачными технологиями и концепциями: Docker, Git, Go, реестром контейнеров и утилитой kubectl.

Эта глава интерактивная! Мы нередко будем просить вас что-либо установить на компьютер, ввести команды и запустить контейнеры — именно для того, чтобы вы могли следовать нашим примерам. Мы считаем, что так обучать гораздо эффективнее, чем просто объяснять на словах.

Запускаем наш первый контейнер

Как вы уже узнали из главы 1, контейнер является одной из ключевых концепций в облачно-ориентированной разработке. Основным инструментом для построения и выполнения контейнеров выступает Docker. В этом разделе мы будем использовать программу Docker Desktop, чтобы создать простое демонстрационное приложение, локально запустить и поместить его образ в реестр контейнеров.

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

Установка Docker Desktop

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

Установим среду Docker Desktop и воспользуемся ею для выполнения простого контейнеризированного приложения. Если у вас в системе уже есть Docker, пропускайте этот раздел и перелистывайте сразу к подразделу «Запуск образа контейнера» на с. 53.

Загрузите версию Docker Desktop Community Edition (hub.docker.com/search/?type=edi­tion&offering=community), которая подходит для вашего компьютера, и затем следуйте инструкциям для своей платформы, чтобы установить и запустить Docker.

На сегодняшний день среда Docker Desktop недоступна для Linux, поэтому пользователям данной операционной системы необходимо установить Docker Engine (www.docker.com/products/container-runtime) и затем Minikube (см. раздел «Minikube» на с. 62).

Когда вы это сделаете, у вас должна появиться возможность открыть терминал и выполнить следующую команду:

docker version

Client:

Version:      18.03.1-ce

...

Этот вывод в деталях может иметь некоторые различия в зависимости от вашей платформы, но если пакет Docker корректно установлен и запущен, вы должны увидеть нечто похожее. В системах Linux вместо этого вам, возможно, придется выполнить команду sudodockerversion.

Что такое Docker

На самом деле Docker (docs.docker.com) — это сразу несколько разных, но связанных между собой инструментов: формат образов для контейнеров, библиотека среды выполнения контейнеров, управляющая их жизненным циклом, утилита командной строки для упаковки и запуска контейнеров, а также API для управления контейнерами. Подробности здесь нас заботить не должны, поскольку, несмотря на свою значимость, Docker является лишь одним из многих компонентов Kubernetes.

Запуск образа контейнера

Что именно представляет собой образ контейнера? Для наших целей технические подробности не очень-то и важны, но вы можете относиться к образу как к ZIP-файлу. Это единый двоичный файл с уникальным идентификатором, который хранит все, что необходимо для работы контейнера.

Неважно, как запускается ваш контейнер — напрямую с помощью Docker или в Kubernetes: достаточно лишь указать ID или URL его образа, и система сама его найдет, загрузит, распакует и запустит.

Мы написали небольшое демон