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

Модуль обозначается с помощью 2 меток:

app, указывает, к какому приложению, компоненту или микросервису принадлежит модуль;
rel, показывает, является ли приложение, запущенное в модуле, стабильной, бета- или канареечной версией.

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

Для создания модуля с двумя метками, создайте новый файл с именем kubia-manual-with-labels.yaml с содержимым:

apiVersion: v1
kind: Pod
metadata:
 name: kubia-manual-v2
 labels:
  creation_method: manual
  env: prod
spec:
 containers:
 – image: vasya/kubia
 name: kubia
 ports:
 – containerPort: 8080
  protocol: TCP

Вы включили метки creation_method=manual и env= prod. Для создания этого модуля выполнить команду:

$ kubectl create -f kubia-manual-with-labels.yaml

Команда kubectl get pods по умолчанию не выводит никаких меток, но их можно увидеть с помощью параметра —show-labels:

$ kubectl get po --show-labels

Вывод только конкретных меток:

$ kubectl get po -L creation_method,env

Чтобы добавить метку creation_method=manual к существующему модулю

$ kubectl label po kubia-manual creation_method=manual

При изменении существующих меток нужно использовать параметр —overwrite.

$ kubectl label po kubia-manual-v2 env=debug –overwrite

Перечисление подмножеств модулей посредством селекторов меток.

Селекторы меток позволяют выбрать подмножество модулей, помеченных определенными метками, и выполнять операцию на этих модулях.
Селектор меток может выбирать ресурсы в зависимости от того:
содержит ли (или не содержит) ресурс метку с определенным ключом;
содержит ли ресурс метку с определенным ключом и значением;
содержит ли ресурс метку с определенным ключом, но со значением, не равным указанному вами.
Для того чтобы просмотреть все модули, созданные вручную (вы пометили их creation_method=manual), выполните команду:

$ kubectl get po -l creation_method=manual

чтобы вывести список всех модулей, которые включают метку env, каким бы ни было его значение:

$ kubectl get po -l env

чтобы вывести список всех модулей, которые не имеют метки env:

$ kubectl get po -l '!env'

чтобы выбрать модули с меткой creation_method с любым значением, кроме manual;

$ kubectl get po -l creation_method!=manual

чтобы выбрать модули с меткой env, установленной в prod или development;

$ kubectl get po -l env in (prod,devel)

чтобы выбрать модули с меткой env, установленной в любое значение, кроме prod или devel.

$ kubectl get po -l env notin (prod,devel)

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

$ kubectl get po -l app=pc, rel=beta

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

Классификация рабочего узла путем добавления метки в узел:

$ kubectl label node gke-kubia-64gfr-node-0sad ssd=true

Используем селектор меток при выведении списка узлов, также как с модулями. Выведем список только тех узлов, которые содержат метку ssd=true:

$ kubectl get nodes -l ssd=true

Приписывание модулей к определенным узлам:

Чтобы развернуть новый модуль, который для выполнения своей работы нуждается в SSD и попросить планировщик выбирать только те узлы, которые предоставляют SSD, добавьте селектор узлов в YAML модуля. Создайте файл с именем kubia-gpu.yaml со следующим содержимым листинга и затем примените kubectl create-f kubia-gpu.yaml для создания модуля.

apiVersion: v1
kind: Pod
metadata:
name: kubia-gpu
spec:
nodeSelector:
gpu: "true"
containers:
– image: vasya/kubia
name: kubia

добавлено поле nodeSelector в секцию спецификации spec. При создании модуля планировщик будет выбирать только те узлы, которые содержат метку ssd=true.