Docker для фронтендера. часть 2. что ты такое?

Как это работает

Virtuozzo Linux устанавливает будущий сервер виртуализации, далее администратор создает, настраивает и запускает контейнеры или виртуальные машины — каждая из которых превратится в виртуальный сервер (Virtual Private Server).

Дальше все зависит от поставленных задач — например, можно превратить виртуальные серверы в веб-серверы и продавать их (типичное решение для VPS-провайдера). Виртуальные серверы могут работать под управлением различных дистрибутивов Linux (а внутри виртуальной машины можно запустить вообще любую ОС, даже Windows Server 2012 R2) — ты можешь выбрать из предустановленных шаблонов тот, который больше нравится. После того как виртуальный сервер запущен, уже никто не ограничивает администратора в установке и настройке программного обеспечения. В виртуальные серверы дистрибутивы Linux устанавливаются как полноценные, а не как урезанные копии.

Схема виртуализации изображена на рис. 1. Сам рисунок позаимствован из документации по Virtuozzo. Так, у нас есть железо сервера, есть уровень виртуализации и есть контейнеры.

Рис. 0. Немного историиРис. 1. Схема виртуализации

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

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

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

Docker

Когда мы говорим о контейнерах в современных IT-системах, прежде всего мы подразумеваем Docker — open-source-технологию, благодаря своей популярности ставшую в IT синонимом слова «контейнер».

Основные сущности Docker

Dockerfile

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

Image

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

Volume

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

Registry

Репозиторий, используемый для хранения Docker-образов. Registry может быть как публичным, так и приватным, защищённым механизмом аутентификации.

Процесс разработки в среде Docker

Типичный процесс разработки в среде Docker выглядит следующим образом: разработчики устанавливают на свои машины Docker, загружают собранный заранее образ с установленной средой сборки и выполнения приложения, а затем запускают контейнер командой, которая также пробросит в него директорию с исходниками. Для установки Docker не требуется особого железа — он может быть установлен на вполне заурядной машине. Однако у него имеются ограничения по версиям ОС — Windows 7 64bit или выше для ПК с поддержкой Hyper-V, macOS Sierra 10.12 для устройств от Apple и версией ядра 3.10 для систем с Linux. Контейнеры Docker являются родной технологией для ОС Linux и запускаются на других с помощью виртуальных машин под её управлением.

Инструкции по установке Docker на разных платформах: Windows, Mac, Linux Ubuntu.

Чтобы запустить ваш первый контейнер на Docker, после его установки введите в командной строке docker run hello-world — эта команда загрузит образ hello-world с Docker hub’а (публично доступный Docker registry), создаст контейнер, используя этот образ, и выдаст приветственную фразу:

Принципы работы

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

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

Рисунок 2. Пример того, как может выглядеть докер-файл для простого приложения, написанного на языке Python

После написания докер-файла и запуска команды сборки образ Docker собирается и отправляется в реестр (registry). Реестр может быть как приватным (внутри организации), так и публичным (например, Docker Hub).

Рисунок 3. Архитектура работы Docker

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

Комплексное корпоративное приложение требует обеспечения отказоустойчивости, балансировки, контроля трафика, бесшовного обновления, автоматического восстановления и т. д. С этими задачами прекрасно справляются средства оркестровки: Kubernetes или OpenShift. Оркестратор состоит из рабочих (worker) нод, на которых исполняется продуктивное приложение, и мастер-ноды, которая обеспечивает централизованное управление системой.

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

Рисунок 4. Пример конвейерной последовательности («пайплайна») CI / CD

Принципы работы контейнера Windows

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

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

Узел контейнера. Физический или виртуальный компьютер под управлением Windows Server 2016, настроенный для работы с контейнерами Windows. На хосте работают один или несколько контейнеров Windows.

Образ контейнера. По мере того как в файловую систему или реестр контейнера вносятся изменения (например, при установке программного обеспечения), они регистрируются в «песочнице». Во многих случаях может потребоваться зарегистрировать это состояние, чтобы применить внесенные изменения при создании новых контейнеров. В этом и заключается суть образа: после остановки работы контейнера можно либо отключить «песочницу», либо преобразовать ее в новый образ контейнера. Предположим, вы развернули контейнер в образе Windows Server Core. Затем вы устанавливаете в этот контейнер MySQL. Создание нового образа на базе этого контейнера будет происходить аналогично его развертыванию. Этот образ будет содержать только внесенные изменения (MySQL) и при этом работать в виде слоя поверх образа ОС контейнера.

«Песочница». После запуска контейнера все операции записи (изменения файловой системы и реестра либо установка программного обеспечения) регистрируются на уровне «песочницы». 

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

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

Использование контейнеров Windows

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

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

Так как контейнер содержит все необходимое для запуска приложения, он отличается высокой переносимостью и может запускаться на любом компьютере под управлением Windows Server 2016. Можно создать и протестировать контейнер локально, а затем развернуть его образ на сервере поставщика услуг, а также в частном или общедоступном облаке компании. Адаптивность контейнеров позволяет использовать современные модели разработки приложений в крупномасштабных виртуализированных и облачных средах.

Контейнеры позволяют масштабировать веб-сервисы эффективнее, так как новые экземпляры стартуют в разы быстрее, чем виртуальные машины (плюс виртуальной машине, в отличие от контейнера, еще нужно время на provisioning).

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

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

Размер имеет значение?

Раньше размер и количество контейнеров был решающим фактор в выборе между Кубом и Докером. Но последнее обновление Докера значительно сократило разрыв. Обе системы поддерживают кластеры, состоящие из 1000 узлов и 30 000 контейнеров.

Так что же выбрать? Если выберешь Куб, то после мучений с развертыванием, сможешь похвастаться, что 99% вызовов API отвечают в течение одной секунды. С другой стороны, Докер гораздо проще в настройке.

В марте 2016 года Докер сообщил о независимом тесте Куба и Докера. В результате теста было обнаружено, что при одинаковом количестве контейнеров Докер в 5 раз быстрее, чем Куб. А все это из-за сложности самого Куба. Да, он большой и нерасторопный.

Докер — быстрее в 5 раз

Локализация разработки

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

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

• этот сетап кто-то должен создать (и задокументировать)
• от стабильности этого сетапа зависит процесс разработки (а значит — надо мониторить)
• если этим сетапом будут пользоваться много разработчиков, он может начать тормозить (а значит — придется масштабировать)
• усложняется процесс конфигурирования: необходимость переключаться между дев- и прод-окружениями
• ну и как же не упомянуть аргумент “не покодить в самолете” 🙂

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

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

Типичный случай: пустые инстансы , , , в которых не хранится ничего важного

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

Рынок контейнеризации стремительно растет

Размер мирового рынка коммерческого контейнерного программного обеспечения будет расти в 2018-2023 гг. в среднем на 30% ежегодно, превысив к концу периода $1,6 млрд — такой прогноз дается в отчете Technology Multi-Tenant Server Software Market Tracker аналитиков IHS Markit. Лидирует компания Red Hat с 44% долей рынка.

Распределение рынка ПО контейнеризации

Аналитики Gartner также прогнозируют значительный рост доходов от глобального программного обеспечения и услуг по управлению контейнерами, хотя и более скромны в оценках. Они полагают, что выручка соответствующего сегмента рынка в 2020-2024 гг. вырастет с $465,8 млн до $944 млн.

Наиболее популярны средства контейнеризации у провайдеров облачных сервисов, они, по данным IHS Markit, применяют контейнерные технологии более чем на трети своих серверов. Для сравнения, телекоммуникационные компании и корпоративный сектор используют контейнерное ПО примерно на 8% мультитенантных серверов (то есть, выделенных под обслуживание пользователей из разных организаций).

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

Главные действующие лица

Сфера контейнеризации быстро развивается, но в ней уже появилось два стандарта «де-факто». Это формат контейнеров Docker и программное обеспечение для оркестрации контейнеров Kubernetes.

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

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

Как свидетельствуют данные исследования компании StackRox, которая в 2018-2020 гг. изучала динамику внедрения контейнеров, Kubernetes доминирует на рынке: 86% респондентов используют его для оркестрации контейнеров.

Популярность средств оркестрации контейнеров (допускалось более одного ответа)

При этом, если сравнивать положение с весной 2019 г, то можно отметить две тенденции. Во-первых, понизилась популярность «самоуправляемых» контейнеров Kubernetes (на 20%), все больше заказчиков хотят воспользоваться услугами в этой области. Во-вторых, популярность практически всех остальных вариантов использования Kubernetes выросла: Amazon EKS — на 37%, Azure AKS — на 31%, Google GKE — на 75%. А конкурирующие варианты, наоборот, стали менее привлекательны — популярность сервиса Amazon ECS на основе продукта Elastic упала на 7%.

Зачем нужна оркестрация: как работать со множество контейнеров в Big Data системах

Оркестрация контейнеров в Big Data системах нужна для следующих действий :

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

Современный рынок свободного и проприетарного ПО предлагает множество систем оркестрации контейнеров. Наиболее популярными и подходящими для надежных и высоконагруженных Big Data систем считаются Kubernetes, Apache Mesos и Red Hat OpenShift. Для не слишком больших проектов подойдут Docker Swarm, Nomad, Fleet, Aurora. Также заслуживают внимания облачные решения Amazon EC2 Container Service и Microsoft Azure Container Service .

Работа множества распределенных сервисов Big Data невозможна без системы оркестрации контейнеров

Источники

1. https://ru.wikipedia.org/wiki/Контейнерная_виртуализация
2. https://habr.com/ru/company/redhatrussia/blog/416169/
3. https://habr.com/ru/company/it-grad/blog/279229/
4. https://www.cloud4y.ru/about/news/obzor-tekhnologii-konteynerizatsii/
5. https://habr.com/ru/company/it-grad/blog/279229/
6. https://www.xelent.ru/blog/chto-takoe-orkestratsiya-konteynerov/

Преимущества контейнерных перевозок

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

Среди преимуществ:

• Стоимость. Отсутствие промежуточных погрузо-разгрузочных работ позволяет существенно экономить.
• Контроль. С помощью современных систем слежения можно контролировать перемещение товара. Это упрощает планирование, позволяет корректировать работу при задержках.
• Универсальность тары. Контейнеры имеют стандартные параметры, могут транспортироваться службами разных стран. Модули рассчитаны на многократное использование.
• Надежность. Контейнеры имеют прочную конструкцию, защищают груз от воздействия окружающей среды и вандализма.
• Автоматизация работ. Применение спецтехники для погрузки и разгрузки значительно ускоряет процессы, сокращает затраты на услуги грузчиков.

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

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

Изоляция

Раз интернеты еще не развалились — то значит какое-то решение умные люди придумали, правда? Этим решением были различные технологии изоляции. Если у нас имеется “проблема коммуналки”, когда логически не связанные друг с другом приложения делят единое окружение, как чуждые друг другу жильцы коммуналки делят санузел и кухню, то надо эту коммуналку расселить.

Виртуализация

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

Это позволит нам установить на виртуальную машину операционную систему по вкусу, а за ней и весь комплект зависимостей нашего приложения. Нам не нужно ломать голову над тем, как тут будут уживаться несколько приложений, мы выделим каждому по своей виртуальной машине. Ура! Коммуналочки расселены! Победа? Или пока только одной проблемой меньше?

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

Контейнеризация

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

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

• файловую систему
• память с деревом процессов
• сетевую активность

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

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

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

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

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

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

Преимущества и недостатки контейнеров в Big Data

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

• стандартизация – благодаря базе открытых стандартов контейнеры могут работать во всех основных дистрибутивах Linux, Microsoft и других популярных ОС;
• независимость контейнера от ресурсов или архитектуры хоста, на котором он работает, облегчает переносимость образа контейнера из одной среды в другую, обеспечивая непрерывный конвейер DevOps-процессов от разработки и тестирования к развертыванию (CI/CD pipeline);
• изоляция – приложение в контейнере работает в изолированной среде и не использует память, процессор или диск хостовой ОС, что гарантирует изолированность процессов внутри контейнера и обеспечивает некоторый уровень безопасности. Подробнее про безопасность в контейнерных технологиях, в частности, про уязвимости Kubernetes, мы написали в отдельных материалах.
• возможность повторного использования – все компоненты, необходимые для запуска приложения, упаковываются в один образ, который может запускаться многократно;
• быстрота развертывания – на создание и запуск контейнера требуется гораздо меньше времени, чем на экземпляр виртуальной машины или настройку полноценного рабочего окружения;
• повышение производительности труда – если каждый микросервис сложной системы упаковать в отдельный контейнер, за который отвечает один разработчик, то можно распараллелить рабочие задачи без взаимных зависимостей и конфликтов;
• упрощение мониторинга — управление версиями контейнерных образов позволяет отслеживать обновления, избегая проблем с синхронизацией.

Тем не менее, при всех вышеотмеченных достоинствах, контейнерной виртуализации свойственны следующие недостатки:

• «упаковка» в контейнер гораздо большего количества ресурсов, чем требуется приложению, что приводит к разрастанию образа и большому размеру контейнера ;
• проблема с обеспечением информационной безопасности – несмотря на то, что многие системы работы с контейнерами (Kubenetes, Docker и пр.) включают средства защиты от взлома и потери данных, например, изоляция пространства имен, гибкие механизмы сетевых политик и ролевой авторизации пользователей по ключу, а также прочие инструменты, о которых мы подробнее рассказываем в следующей статье, использование контейнеров не всегда безопасно. Например, некоторые важные подсистемы ядра операционной системы Linux функционируют вне контейнера (переферийные устройства, SELinux, Cgroups и вся файловая система внутри системного раздела /sys). Благодаря этому можно взломать операционную систему, если клиент (пользователь или приложение) контейнера имеет root-права . Подробнее об этом читайте в нашей следующей статье.
• проблема обеспечения качества при увеличении числа контейнеров, включая распределение рабочей нагрузки – для решения этой задачи используются системы оркестрации контейнеров, о которых мы поговорим далее.

Как и у любой технологии, у контейнеризации есть 2 стороны

Оркестрирование контейнеров: Kubernetes

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

Node (master и slave)

Узлы, из которых состоит кластер Kubernetes. Master-нода осуществляет контроль над кластером через планировщик и менеджер контроллеров, обеспечивает интерфейс взаимодействия с пользователями посредством API-сервера и содержит хранилище etcd, где находится конфигурация кластера, статусы его объектов и метаданные. Slave-нода предназначена исключительно для запуска контейнеров, для этого на ней установлены два сервиса Kubernetes — сетевой маршрутизатор и агент планировщика.

Pod

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

ReplicaSet

Объект, описывающий и контролирующий соответствие запущенного на кластере количества реплик Pod’ов. Установка количества реплик больше одной требуется для повышения отказоустойчивости и масштабирования приложения. Общепринято создавать ReplicaSet с помощью Deployment.

StatefulSet

Действует по тому же принципу, что и ReplicaSet, однако дополнительно позволяет описывать и сохранять при перезапуске уникальный сетевой адрес Pod’ов или их дисковое хранилище.

DaemonSet

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

Job и CronJob

Объекты, запускающие соответственно однократно и регулярно по расписанию указанный Pod и отслеживающие результат завершения его работы.

Service

Инструмент для публикации приложения в качестве сетевого сервиса, в том числе реализующий балансировку нагрузки между Pod’ами приложения.