Tag Archives: Mimbolovekubernetes
В статье пойдет речь о запуске только одного модуля на каждом узле с помощью набора демонов (DaemonSet).
Наборы реплик (ReplicaSet) используются для запуска определенного количества модулей, развернутых в кластерной инфраструктуре Kubernetes. Но существуют случаи, когда требуется, чтобы модули связанные с обеспечением работы инфраструктуры, выполняющие операции системного уровня работали на каждом узле в кластере. Например, когда требуется на каждом узле запустить сборщик логов или монитор ресурсов. Еще одним хорошим примером является собственный процесс kube-proxy системы Kubernetes, который должен работать на всех узлах, чтобы заставлять службы работать. Наборы демонов (DaemonSet) запускают только одну реплику модуля на каждом узле, в то время как наборы реплик (replicaset) разбрасывают их по всему кластеру случайным образом.
Для запуска модуля на всех узлах кластера создается объект DaemonSet, который похож на объекты ReplicaSet, за исключением того, что модули, созданные набором демонов, уже имеют заданный целевой узел и пропускают планировщик Kubernetes, т.е. они не разбросаны по кластеру случайным образом. Набор демонов гарантированно создает модули по количеству узлов, и разворачивает каждый на своем узле. Падение узла не заставляет объект DaemonSet создавать модуль в другом месте. Но когда новый узел добавляется в кластер, набор демонов немедленно развертывает в нем новый экземпляр модуля.
Объяснение наборов демонов на примере
Развернем демон ssd-monitor, который должен работать на всех узлах, содержащих твердотельный накопитель (SSD). Создадим объект DaemonSet, который запускает этот демон на всех узлах, помеченных как имеющие SSD. Подразумевается, что администраторы кластера добавили метку disk=ssd во все такие узлы, поэтому создадим объект DaemonSet с помощью селектора узлов, который выбирает только узлы с этой меткой.
Создание YAML-определения ресурса DaemonSet: (далее…)
Ресурсы Kubernetes
Namespace* (ns) [v1] — позволяет организовывать ресурсы в неперекрывающиеся группы (для каждого потребителя ресурсов).
Развертывающие рабочие нагрузки
Pod (po) [v1] — основная развертываемая единица, содержащая один или более процессов в расположенных рядом контейнерах. Метки (Labels).
ReplicaSet (rs) — поддерживает одну или несколько реплик модуля.
ReplicationController (rc) [v1] – устаревший и менее функциональный эквивалент ресурса ReplicaSet.
Job [batch/v1] — запускает модули, выполняющие завершаемую задачу.
CronJob [batch/v1beta1] — запускает назначаемое задание один раз или периодически.
DaemonSet (ds) — запускает одну реплику модуля в расчете на узел (на всех узлах или только на тех, которые соответствуют селектору узлов).
StatefulSet (sts) — запускает модули, имеющие внутреннее состояние, со стабильной идентичностью.
Deployment (deploy) — декларативное развертывание и обновление модулей.
Службы
Service (svc) [v1] — предоставляет доступ к одному или нескольким модулям на одной и стабильной паре IP-адреса и порта.
Endpoints (ep) [v1] — определяет, к каким модулям (или другим серверам) предоставляется доступ через службу.
Ingress (ing) [extensions/v1beta1] — предоставляет внешним клиентам доступ к одной или нескольким службам через один доступный извне IP-адрес.
Конфигурация
ConfigMap (cm) [v1] — словарь в формате «ключ-значение» для хранения незащищенных параметров конфигурации приложений и предоставления им доступа к ним.
Secret [v1] — словарь в формате «ключ-значение» для хранения конфиденциальных данных. (далее…)
Создание контроллера репликации.
Контроллер репликации (ReplicationController) – это ресурс Kubernetes, который обеспечивает поддержание постоянной работы его модулей. Если модуль исчезает по любой причине, например, в случае исчезновения узла из кластера или потому, что модуль был вытеснен из узла, контроллер репликации замечает отсутствующий модуль и создает сменный модуль.
Контроллер репликации состоит из трех основных частей:
- селектор меток, определяющий, какие модули находятся в области действия контроллера репликации;
- количество реплик, указывающее на требуемое количество модулей, которые должны быть запущены;
- шаблон модуля, используемый при создании новых реплик модуля.
Подобно модулям и другим ресурсам Kubernetes, создается контроллер репликации при помощи отправки дескриптора JSON или YAML на сервер API Kubernetes ($ kubectl create -f kubia-rc.yaml). Содержимое файла kubia-rc.yaml: (далее…)
Пространства имен (Namespace) Kubernetes предоставляют область видимости для имен объектов. Чтобы все ресурсы небыли в одном пространстве имен Kubernetes, можно разбить их на несколько пространств имен, что также позволяет использовать одни и те же имена ресурсов несколько раз (в разных пространствах имен Kubernetes).
Использование нескольких пространств имен позволяет разбить сложные системы со множеством компонентов на более мелкие отдельные группы. Они могут использоваться для разделения ресурсов в мультитенантной среде, разбивая ресурсы на среды рабочего окружения, среды разработки и контроля качества. Имена ресурсов должны быть уникальными только в пределах пространства имен. Но хотя большинство типов ресурсов организовано в пространства имен, некоторые из них – нет. Одним из них является ресурс узла (Node), который является глобальным и не привязан к одному пространству имен.
Два разных пространства имен могут содержать ресурсы с одинаковыми именами. Если несколько пользователей или групп пользователей используют один кластер Kubernetes и каждый из них управляет своим собственным набором ресурсов, каждый из них должен использовать собственное пространство имен. (далее…)
Метки представляют собой функциональное средство для организации не только модулей, но и других ресурсов Kubernetes. Метка – это произвольная пара «ключ-значение», присоединяемая к ресурсу, которая затем используется при отборе ресурсов с помощью селекторов меток (ресурсы фильтруются на основе того, включают они метку, указанную в селекторе, или нет). Ресурс может иметь несколько меток, если ключи этих меток уникальны в пределах данного ресурса. Метки обычно прикрепляются к ресурсам при их создании, но можно также добавлять дополнительные метки или даже изменять значения существующих меток позже без необходимости повторного создания ресурса.
Модуль обозначается с помощью 2 меток:
app, указывает, к какому приложению, компоненту или микросервису принадлежит модуль;
rel, показывает, является ли приложение, запущенное в модуле, стабильной, бета- или канареечной версией.
Канареечный релиз – это новая версия приложения рядом со стабильной версией, только небольшая часть пользователей попадает в новую версию, чтобы увидеть, как она себя ведет, прежде чем развернуть ее для всех пользователей. Это препятствует доступу слишком большого числа пользователей к плохим релизам.
Добавив эти две метки, вы, по существу, организовали свои модули в двух измерениях (горизонтально по приложениям и вертикально по релизам). (далее…)
0