Основные концепции Kubernetes I — Pods, Labels и Replicas

Оригинал статьи


Эта статья — первая из серии статей об основных концепциях Kubernetes. Во второй части мы поговорим о Deployments. Третья статья объясняет понятия Services и в четвертой мы посмотрим на Secrets и ConfigMaps. В пятой и последней мы поговорим о Daemon Sets и Jobs.

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

В этом посте мы рассмотрим самые базовые концепции: podslabelsselectors и replica sets. Я не хотел бы приходить каких-либо конкретных инструкций, а сосредоточиться исключительно на объяснении понятий, их функциональности и каким образом их можно использовать. Здесь будут только базовые понятия и потребуется немного более полное описание Kubernetes, поэтому будьте уверены, я расскажу про другие концепции в следующих статьях.

Pods (модули)

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

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

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

Для типичного пользователя Docker эта концепция совершенно новая. Хотя пользователи Giant Swarm уже давно могут использовать модулями, даже без Kubernetes, лишь немногие на самом деле пользуются этим. Для некоторых это может выглядеть как возврат от “один процесс на контейнер” к “развертыванию всего LAMP вместе”. Однако, это не то, как предполагается использовать модули. Основная мотивация всей концепции модуля — поддержка расположенных вместе, совместно управляемых вспомогательных контейнеров рядом с контейнером приложения. Это включает такие вещи, как журналирование или мониторинг агентов, средства резервного копирования, отслеживание изменения данных (data change watchers), публикации событий (event publishers), прокси и т.д. Если нет уверенности, для чего использовать модули в самом начале, можно использовать их с одним контейнером, как это делалось бы при работе с Docker.

Модуль — самое базовое понятие в Kubernetes. Само по себе, он эфемерен и не может быть перенесен на новую ноду, если умрёт. Если нужно сохранить один или несколько инстансов живыми, необходимо другое понятие — replica sets. Но прежде потребуется понять, что такое labels и selectors.

Метки (labels) и переключатели (selectors)

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

Метки могут использоваться для организации и выбора подмножества объектов. Они часто используются, например, для идентификации релизов (beta, stable), окружений (dev, prod) или ярусов (frontend, backend), но они также достаточно гибкие для использования во многих других случаях. Они помогают получить некоторый порядок в многомерности современных систем развертывания.

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

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

В настоящее время существует два типа переключателей в Kubernetes: equality-based и set-based. Первые используют пары ключ/значение для фильтрации на основе базового равенства (или неравенства). Вторые немного более мощные и позволяют фильтровать ключи в соответствии с набором значений.

Используя переключатели меток, клиент или пользователь может определить и в последствии управлять группой объектов. Это — ключевой примитив для группировки Kubernetes, и он используется во многих местах. Един из примеров его использования — работа с replica sets.

Наборы реплик (replica sets) (и контроллеры репликации (replication controllers))

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

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

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

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

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

Что еще почитать

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