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

Что такое модуль в Kubernetes?

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

Модули, контейнеры, узлы и кластеры в Kubernetes: сравниваем

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

• Модули и контейнеры. Контейнер объединяет в себе все необходимые библиотеки, зависимости и прочие ресурсы, которые нужны для того, чтобы приложение могло работать само по себе. Что же касается модуля, то он создает «обертку» для зависимостей, с помощью которых Kubernetes может управлять контейнерами приложений. 
• Модули и узлы. Узел в Kubernetes – это понятие, которое относится к «голому железу» или виртуальным машинам, которые отвечают за размещение модулей. Один уpел может запускать несколько модулей контейнеров. И хотя у каждого модуля должен быть узел для запуска, модули размещаются не на всех узлах. У главного узла есть уровень управления, который помогает обеспечивать контроль за планированием модулей, при этом модули располагаются на рабочих узлах.
• Модули и кластеры. Кластер в Kubernetes – это группа узлов, которая состоит, как минимум, из одного главного узла (в случае кластеров с высоким уровнем доступности необходимо иметь больше, чем один главный узел) и, как максимум, 5000 рабочих узлов. Кластеры позволяют производить планирование модулей на различных узлах с разными конфигурациями и операционными системами. 

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

Типы модулей

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

Одноконтейнерные модули

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

Многоконтейнерные модули

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

Преимущества использования модулей Kubernetes

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

Вот некоторые из самых важных преимуществ, которые дают модули Kubernetes:

• Абстрактное представление контейнеров. Модуль – это уровень абстракции для контейнеров, которые он размещает, и, соответственно, Kubernetes способен рассматривать контейнеры в кластере как одно целое, тем самым упрощая процесс управления контейнерами. 
• Совместное использование ресурсов. Контейнеры, которые расположены внутри одного модуля, используют одно и то же пространство имен сети. Это гарантирует тот факт, что они могут взаимодействовать через один локальный хост, а это в свою очередь существенно упрощает подключение к сети. Контейнеры, которые находятся в модуле, могут не только иметь общий доступ к сети, то и совместно использовать тома хранилища. Это особенно полезно, если вы управляете приложениями, фиксирующими состояния. 
• Балансировка нагрузки. Модули могут дублироваться внутри кластера, а служба балансировки нагрузки может выравнивать трафик между этими дубликатами. Балансировка нагрузки в Kubernetes – это простой способ сделать ваше приложение открытым к внешнему сетевому трафику. 
• Масштабируемость. Kubernetes может автоматически увеличивать или уменьшать количество дубликатов модулей в зависимости от факторов, определенных заранее. Таким образом, вы можете доработать систему так, чтобы она могла увеличиваться или уменьшаться в зависимости от рабочей нагрузки. 
• Проверка работоспособности. Система проводит регулярные проверки работоспособности модулей и перезапускается. Помимо этого, Kubernetes перепланирует модули, которые аварийно завершили свою работу или являются неработоспособными. Автоматические проверки работоспособности являются важным фактором поддержания бесперебойной работы приложения. 

Как работают модули?

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

Жизненный цикл

Жизненный цикл модуля зависит от того, для чего он нужен кластеру, а также от объекта Kubernetes, который его создал.

Объекты Kubernetes, такие как job или cronjob, создают модули, которые прекращают свою работу сразу после того, как выполнили свою задачу (например, после создания отчета или выполнения резервного копирования). А вот в случае с такими объектами, как deployment, replicaset, daemonset и statefulset, они создают модули, которые будут работать до тех пор, пока пользователь не прервет их работу самостоятельно. 

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

• Ожидание (Pending). Если модуль отображает статус ожидания, то это значит, что Kubernetes принял его, и контейнеры, которые находятся внутри модуля, сейчас готовятся к запуску. 
• Выполнение (Running). Этот статус означает, что Kubernetes завершил настройку контейнера и назначил модулю узел. Для того, чтобы отображался статус «выполнение», должен запускаться, перезапускаться или работать, как минимум, один контейнер.
• Успешно (Succeeded). Когда модуль завершает какую-либо задачу (например, завершает выполнение операции, связанную с объектом job), он отображает статус «успешно». Это значит, что он закончил свою работу и перезапускаться не будет. 
• Не выполнено (Failed). Статус «не выполнено» говорит о том, что один или несколько модулей завершили свою работу с ненулевым статусом, то есть с ошибкой.
• Неизвестно (Unknown). Этот статус, как правило, указывает на то, что есть некая проблема с подключением к узлу, на котором запущен модуль. 

У модулей есть не только фазы; у них также есть статусы: PodScheduled, Ready, Initialized и Unschedulable. У каждого из этих статусов есть три возможных значения: true (истина), false (ложь) и unknown (неизвестно). 

Журналы

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

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

Контроллеры

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

Демон под названием Controller Manager (инструмент управления контроллерами) ответственен за управление контроллерами. Для того, чтобы отслеживать состояние кластера, он использует управляющие циклы, а для того, чтобы вносить необходимые изменения, он связывается с сервером API.

Вот список самых важных контроллеров Kubernetes:

• ReplicaSet. Создает набор модулей для выполнения одной и той же рабочей нагрузки.
• Deployment. Создает полностью настроенный ReplicaSet и дает возможность произвести дополнительные настройки обновлений и откатов.
• DaemonSet. Регулирует то, на какие узлы возложена ответственность за запуск модуля.
• StatefulSet. Управляет приложениями, фиксирующими состояния, и создает внешнее хранилище и модули, имена которых сохраняются, несмотря на перезапуски.
• Job. Создает модули, которые успешно завершают свою работу после того, как выполнят задачу.
• Cronjob. Помогает планировать Job.

Шаблоны

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

Пользователи могут изменить конфигурацию модуля путем изменения параметров в поле контроллера под названием PodTemplate.

Сеть

Каждому модулю в кластере Kubernetes присваивается уникальный IP-адрес кластера. Этот IP-адрес, вместе с пространством имен сети и портами, используется всеми контейнерами, которые находятся внутри этого модуля. Таким образом, они могут взаимодействовать с помощью локального хоста. 

А для того, чтобы контейнер из одного модуля мог взаимодействовать с контейнером из другого модуля, вам нужна IP-сеть. Модули предлагают виртуальное Ethernet-соединение, которое позволяет им подключиться к виртуальному Ethernet-устройству, которое расположено на узле, и создать сетевой туннель для модулей внутри узла.

Хранилище

Данные модуля хранятся в томах. Это каталоги хранилища, доступ к которым есть у всех контейнеров, находящихся внутри модуля. Есть два основных типа томов хранилища:

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

Пользователь должен указать то, какие тома будет использовать модуль, в отдельном YAML-файле.

Работа с модулями Kubernetes

Пользователи взаимодействуют с модулями с помощью kubectl. Это набор команд, с помощью которого можно контролировать кластеры Kubernetes путем отправки HTTP-запросов в API.

Дальше мы перечислили некоторые самые часто используемые операции по управлению модулями.

Операционная система модуля

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

Вы должны указать операционную систему (linux или windows), которую будут использовать ваши модули, в поле .spec.os.name файла YAML. Kubernetes не будет запускать модули, которые не удовлетворяют этому критерию.

Самостоятельное создание модуля 

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

Если вы хотите самостоятельно создать модуль, то воспользуйтесь командой kubectl run:

kubectl run [pod-name] --image=[container-image] --restart=Never

Параметр --restart=Never не дает модулю постоянно перезапускаться, поскольку это может привести к зацикливанию сбоев. Ниже показан модуль Nginx, который был создан с помощью команды kubectl run.

Развертывание модуля

Лучше всего создавать модули через ресурсы рабочей нагрузки (Deployment, ReplicaSet и т.д.). Например, следующий YAML-файл создает объект deployment для Nginx с пятью репликами модуля. В каждом модуле есть отдельный контейнер, который запускает последний образ nginx. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Для того, чтобы создать модуль из YAML-файла, воспользуйтесь командой kubectl create:

kubectl create -f [yaml-file]

Частичное или полное изменение модуля

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

Перечисление модулей

Вы можете просмотреть доступные модули с помощью следующей команды:

kubectl get pod

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

Перезапуск модуля

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

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

Удаление модуля

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

Помимо этого, вы можете удалить модуль через командную строку, передав YAML-файл, который содержит спецификации модуля команде kubectl delete в качестве параметра:

kubectl delete -f [yaml-file]

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

Просмотр журналов модулей

С помощью команды kubectl logs пользователи могут просмотреть журналы какого-то определенного модуля.

kubectl logs [pod-name]

Назначение модулей узлам

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

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

Мониторинг модулей

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

• Общее количество экземпляров модулей. Этот параметр помогает обеспечивать высокий уровень доступности. 
• Фактическое количество экземпляров модулей в сравнении с ожидаемым количеством. Этот параметр помогает определить тактику перераспределения ресурсов.
• Состояние объекта deployment. Этот параметр помогает выявить ошибки в конфигурации и проблемы с распределением модулей по узлам.

Заключение

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