Селекторы меток (label selectors) в Kubernetes

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

С помощью селектора меток клиент/пользователь может идентифицировать набор объектов. Селектор меток является основным примитивом группировки в Kubernetes.

В настоящее время API поддерживает два типа селекторов: на основе равенства и на основе набора. Селектор метки может быть сделан из нескольких требований, разделенных запятыми. В случае нескольких требований все должны быть выполнены, поэтому разделитель запятых действует как логический оператор AND (&&).

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

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

Требование на основе равенства

Требования на основе равенства или неравенства позволяют выполнять фильтрацию по ключам и значениям меток. Соответствующие объекты должны удовлетворять всем указанным ограничениям меток, хотя они могут также иметь дополнительные метки. Допускаются три вида операторов =, ==, !=. Первые два представляют равенство (и являются просто синонимами), в то время как последние представляют неравенство. Например:

environment = production
tier != frontend

Первый выбирает все ресурсы с ключом, равным environment, и значением, равным production. Последний выбирает все ресурсы с ключом, равным tier и значением, отличным от frontend, и все ресурсы без меток с ключом tier. Можно фильтровать ресурсы в production, исключая frontend, используя оператор запятой: environment=production,tier!=frontend

Один сценарий использования требования метки на основе равенства состоит в том, чтобы Pod определял критерии выбора узла. Например, приведенный ниже пример Pod выбирает узлы с меткой “accelerator=nvidia-tesla-p100”.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Требования на основе набора

Требования к меткам на основе набора позволяют фильтровать ключи в соответствии с набором значений. Поддерживаются три вида операторов: in, notin и exists (только идентификатор ключа). Например:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

В первом примере выбираются все ресурсы с ключом, равным environment, и значением, равным production или qa. Во втором примере выбираются все ресурсы с ключом, равным tier и значениям, отличным от frontend и backend, и все ресурсы без меток с ключом tier. Третий пример выбирает все ресурсы, включая метку с ключом partition; никакие значения не проверены. В четвертом примере выбираются все ресурсы без метки с ключом partition; никакие значения не проверены. Точно так же разделитель запятых действует как оператор AND. Таким образом, фильтрация ресурсов по ключу partition (независимо от значения) и environment, отличной от qa, может быть достигнута с помощью partition,environment notin (qa). Селектор меток на основе набора является общей формой равенства, так как environment=production эквивалентно environment in (production); аналогично для != и notin.

Требования на основе набора могут быть смешаны с требованиями на основе равенства. Например: partition in (customerA, customerB),environment!=qa.

API

LIST и WATCH фильтрация

Операции LIST и WATCH могут указывать селекторы меток для фильтрации наборов объектов, возвращаемых с использованием параметра запроса. Оба требования (на основе равенства (equality-based) и на основе набора (set-based)) разрешены (представлены здесь так, как они будут отображаться в строке запроса URL):

equality-based requirements: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
set-based requirements: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

Оба стиля селектора меток могут использоваться для вывода списка или просмотра ресурсов с помощью клиента REST. Например, нацеливая apiserver с помощью kubectl и используя равенство, можно написать:

kubectl get pods -l environment=production,tier=frontend

или используя требования на основе набора:

kubectl get pods -l 'environment in (production),tier in (frontend)'

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

kubectl get pods -l 'environment in (production, qa)'

или ограничение отрицательного соответствия с помощью существующего оператора:

kubectl get pods -l 'environment,environment notin (frontend)'

Установить ссылки в объектах API

Некоторые объекты Kubernetes, такие как services и replicationcontrollers, также используют селекторы меток для указания наборов других ресурсов, таких как pods.

Service и ReplicationController

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

Селекторы меток для обоих объектов определяются в файлах json или yaml с использованием карт, и поддерживаются только селекторы требований на основе равенства:

"selector": {
    "component" : "redis",
}

или

selector:
    component: redis

этот селектор (соответственно в формате json или yaml) эквивалентен component=redis или component in (redis).

Ресурсы, которые поддерживают требования на основе набора

Более новые ресурсы, такие как Job, Deployment, Replica Set и Daemon Set, также поддерживают требования на основе набора.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels - это карта пар {key,value} ({ключ, значение}). Один {key,value} в карте matchLabels эквивалентен элементу matchExpressions, чье поле ключа - “key”, оператор - “In”, а массив значений содержит только “value”. matchExpressions представляет собой список требований селектора pod. Допустимые операторы включают In, NotIn, Exists и DoesNotExist. Установленные значения должны быть непустыми в случае In и NotIn. Все требования, как для matchLabels, так и для matchExpressions, объединены AND - все они должны быть выполнены для соответствия.

Выбор наборов узлов

Один вариант использования для выбора по меткам - это ограничение набора узлов, на которые может планироваться pod.

Поиск по этому блогу

Kubernetes блог