K8s Q A Labels And Selectors: различия между версиями
Sirmax (обсуждение | вклад) (Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы =Labels and Selectors=») |
Sirmax (обсуждение | вклад) |
||
Строка 3: | Строка 3: | ||
=Labels and Selectors= |
=Labels and Selectors= |
||
+ | (аннотации - отдельно https://habr.com/ru/companies/slurm/articles/739920/) |
||
+ | ==Labels== |
||
+ | Labels представляют собой пары ключ/значение, которые назначаются объектам |
||
+ | (например, подам) в кластере Kubernetes. |
||
+ | <BR> |
||
+ | Эти метки предназначены для указания идентифицирующих атрибутов объектов, осмысленных и имеющих отношение к пользователям. |
||
+ | <BR> |
||
+ | Метки чаще всего используются для выбора подмножеств и организации объектов в кластере. |
||
+ | В данном случае под “организацией” следует понимать возможность пользователей сопоставлять свои собственные организационные структуры и системные объекты, |
||
+ | не требуя от клиентов хранить эти сопоставления. |
||
+ | <BR> |
||
+ | |||
+ | Метки могут прикрепляться к объектам во время создания или же добавляться (и изменяться) в любое время. |
||
+ | Каждый объект в кластере Kubernetes может иметь собственный набор ключей/значений. |
||
+ | <BR> |
||
+ | |||
+ | Каждый ключ должен быть уникальным для данного объекта: |
||
+ | <BR> |
||
+ | <PRE> |
||
+ | "metadata": { |
||
+ | "labels": { |
||
+ | "key1" : "value1", |
||
+ | "key2" : "value2" |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | В зависимости от конкретных требований проекта, подхода к разработке и тестированию, используемых технологий, бюджета (и прочих факторов) для доставки приложения конечному пользователю у вас может быть несколько датацентров/кластеров, разные наборы нод в кластере (отличающиеся, например по CPU), несколько различных окружений, множество микросервисов и т. д. С помощью меток можно “задокументировать” запущенные в кластере объекты в понятном для пользователя формате, а также использовать метки в селекторах, что существенно упрощает управление инфраструктурой. |
||
+ | <BR> |
||
+ | |||
+ | Пример наиболее часто используемых меток: |
||
+ | |||
+ | * "release" : "stable", "release" : "canary" |
||
+ | * "environment" : "dev", "environment" : "qa", "environment" : "production" |
||
+ | * "tier" : "frontend", "tier" : "backend", "tier" : "cache" |
||
+ | * "track" : "daily", "track" : "weekly" |
||
+ | |||
+ | Можно использовать свои собственные обозначения, главное помнить, что ключ метки должен быть уникальным для объекта. |
||
+ | <BR> |
||
+ | Корректные имена ключей в метках состоят из двух сегментов: опционального префикса и имени, разделенных символом /. |
||
+ | Имя - обязательная часть - должно начинаться и заканчиваться буквенно-цифровым символом ([a-z0-9A-Z]), |
||
+ | может содержать в себе дефисы (-), подчеркивания (_) и точки (.). Максимально допустимая длина имени ключа - 63 символа. |
||
+ | <BR> |
||
+ | Опциональный префикс (если определен) должен быть DNS-поддоменом (разрешается использование точек) не длиннее 253 символов и заканчиваться символом /. |
||
+ | <BR> |
||
+ | |||
+ | Например, префикс kubernetes.io/ зарезервирован для основных компонентов Kubernetes. |
||
+ | <BR> |
||
+ | |||
+ | Значения меток, так же как и имена ключей, должны начинаться и заканчиваться буквенно-цифровым символом ([a-z0-9A-Z]), содержать в себе дефисы (-), подчеркивания (_) и точки (.). Максимально допустимая длина значения метки - 63 символа. |
||
+ | <BR> |
||
+ | ==selector== |
||
+ | С использованием селектора меток (label selector) в кластере Kubernetes пользователь может идентифицировать набор объектов. Селектор - это примитив основной группировки в Kubernetes. В данный момент API поддерживает два вида селекторов - основанных на точном соответствии (equality-based) и на соответствии набору (set-based). Если в селекторе указывается несколько соответствий, то они должны быть перечислены через запятую - в данном случае для их объединения будет использоваться логический оператор AND (&&). |
||
+ | |||
+ | Селектор, основанный на точном соответствии поддерживает только три возможных оператора сравнения - =, == и != - первые два из них означают равенство, третий - неравенство. Например: |
||
+ | |||
+ | environment = production |
||
+ | tier != frontend |
||
+ | В данном примере селектор выберет все ресурсы, у который ключ environment соответствует значению production, а также те ресурсы, у которых ключ tier не равен frontend (в том числе ресурсы, у которых нет ключа tier). |
||
+ | |||
+ | Селектор, основанный на соответствии набору также поддерживает три возможных оператора - in, notin и exists (последний используется только для проверки наличия/отсутствия ключа). Например: |
||
+ | |||
+ | environment in (production, qa) |
||
+ | tier notin (frontend, backend) |
||
+ | partition |
||
+ | !partition |
||
+ | В данном примере, первая строка позволит выбрать все ресурсы, у которых есть ключ environment со значениями production или qa. Вторая строка выбирает ресурсы у которых есть ключ tier и любые значения кроме frontend и backend. Третья строка служит для выбора всех ресурсов, у которых в метках есть ключ partition (значения не проверяются), а четвертая - наоборот, выбирает ресурсы которые не имеют ключа partition. |
||
+ | |||
+ | Есть возможность комбинировать оба типа селекторов, например: |
||
+ | |||
+ | tier in (frontend, backend),environment!=qa |
||
+ | Несколько примеров использования селекторов с утилитой kubectl: |
||
+ | |||
+ | kubectl get pods -l environment=production,tier=frontend |
||
+ | kubectl get pods -l 'environment in (production),tier in (frontend)' |
||
+ | kubectl get pods -l 'environment in (production, qa)' |
||
+ | kubectl get pods -l 'environment,environment notin (frontend)' |
||
+ | Набор подов для сервиса (service) определяется с помощью селектора. Аналогично, набор подов, которыми управляет Replication Controller также определяется с помощью селектора. Для этих двух объектов может быть использован только селектор на основе точного соответствия (equality-based) - об этом мы уже упоминали в статье Знакомство с Kubernetes. Часть 4: Реплики (ReplicaSet). Выглядеть это может примерно так: |
||
+ | |||
+ | selector: |
||
+ | component: redis |
||
+ | Для более новых объектов Kubernetes, например, (Job, Deployment, Replica Set, Daemon Set) может быть использован селектор на основе соответствия набору (set-based). Например: |
||
+ | |||
+ | selector: |
||
+ | matchLabels: |
||
+ | component: redis |
||
+ | matchExpressions: |
||
+ | - {key: tier, operator: In, values: [cache]} |
||
+ | - {key: environment, operator: NotIn, values: [dev]} |
||
+ | На этом с метками и селекторами все, в следующей статье рассмотрим неймспейсы (namespaces) в Kubernetes. |
Версия 15:50, 8 января 2024
Labels and Selectors
(аннотации - отдельно https://habr.com/ru/companies/slurm/articles/739920/)
Labels
Labels представляют собой пары ключ/значение, которые назначаются объектам
(например, подам) в кластере Kubernetes.
Эти метки предназначены для указания идентифицирующих атрибутов объектов, осмысленных и имеющих отношение к пользователям.
Метки чаще всего используются для выбора подмножеств и организации объектов в кластере.
В данном случае под “организацией” следует понимать возможность пользователей сопоставлять свои собственные организационные структуры и системные объекты,
не требуя от клиентов хранить эти сопоставления.
Метки могут прикрепляться к объектам во время создания или же добавляться (и изменяться) в любое время.
Каждый объект в кластере Kubernetes может иметь собственный набор ключей/значений.
Каждый ключ должен быть уникальным для данного объекта:
"metadata": { "labels": { "key1" : "value1", "key2" : "value2" } }
В зависимости от конкретных требований проекта, подхода к разработке и тестированию, используемых технологий, бюджета (и прочих факторов) для доставки приложения конечному пользователю у вас может быть несколько датацентров/кластеров, разные наборы нод в кластере (отличающиеся, например по CPU), несколько различных окружений, множество микросервисов и т. д. С помощью меток можно “задокументировать” запущенные в кластере объекты в понятном для пользователя формате, а также использовать метки в селекторах, что существенно упрощает управление инфраструктурой.
Пример наиболее часто используемых меток:
- "release" : "stable", "release" : "canary"
- "environment" : "dev", "environment" : "qa", "environment" : "production"
- "tier" : "frontend", "tier" : "backend", "tier" : "cache"
- "track" : "daily", "track" : "weekly"
Можно использовать свои собственные обозначения, главное помнить, что ключ метки должен быть уникальным для объекта.
Корректные имена ключей в метках состоят из двух сегментов: опционального префикса и имени, разделенных символом /.
Имя - обязательная часть - должно начинаться и заканчиваться буквенно-цифровым символом ([a-z0-9A-Z]),
может содержать в себе дефисы (-), подчеркивания (_) и точки (.). Максимально допустимая длина имени ключа - 63 символа.
Опциональный префикс (если определен) должен быть DNS-поддоменом (разрешается использование точек) не длиннее 253 символов и заканчиваться символом /.
Например, префикс kubernetes.io/ зарезервирован для основных компонентов Kubernetes.
Значения меток, так же как и имена ключей, должны начинаться и заканчиваться буквенно-цифровым символом ([a-z0-9A-Z]), содержать в себе дефисы (-), подчеркивания (_) и точки (.). Максимально допустимая длина значения метки - 63 символа.
selector
С использованием селектора меток (label selector) в кластере Kubernetes пользователь может идентифицировать набор объектов. Селектор - это примитив основной группировки в Kubernetes. В данный момент API поддерживает два вида селекторов - основанных на точном соответствии (equality-based) и на соответствии набору (set-based). Если в селекторе указывается несколько соответствий, то они должны быть перечислены через запятую - в данном случае для их объединения будет использоваться логический оператор AND (&&).
Селектор, основанный на точном соответствии поддерживает только три возможных оператора сравнения - =, == и != - первые два из них означают равенство, третий - неравенство. Например:
environment = production tier != frontend В данном примере селектор выберет все ресурсы, у который ключ environment соответствует значению production, а также те ресурсы, у которых ключ tier не равен frontend (в том числе ресурсы, у которых нет ключа tier).
Селектор, основанный на соответствии набору также поддерживает три возможных оператора - in, notin и exists (последний используется только для проверки наличия/отсутствия ключа). Например:
environment in (production, qa) tier notin (frontend, backend) partition !partition В данном примере, первая строка позволит выбрать все ресурсы, у которых есть ключ environment со значениями production или qa. Вторая строка выбирает ресурсы у которых есть ключ tier и любые значения кроме frontend и backend. Третья строка служит для выбора всех ресурсов, у которых в метках есть ключ partition (значения не проверяются), а четвертая - наоборот, выбирает ресурсы которые не имеют ключа partition.
Есть возможность комбинировать оба типа селекторов, например:
tier in (frontend, backend),environment!=qa Несколько примеров использования селекторов с утилитой kubectl:
kubectl get pods -l environment=production,tier=frontend kubectl get pods -l 'environment in (production),tier in (frontend)' kubectl get pods -l 'environment in (production, qa)' kubectl get pods -l 'environment,environment notin (frontend)' Набор подов для сервиса (service) определяется с помощью селектора. Аналогично, набор подов, которыми управляет Replication Controller также определяется с помощью селектора. Для этих двух объектов может быть использован только селектор на основе точного соответствия (equality-based) - об этом мы уже упоминали в статье Знакомство с Kubernetes. Часть 4: Реплики (ReplicaSet). Выглядеть это может примерно так:
selector:
component: redis
Для более новых объектов Kubernetes, например, (Job, Deployment, Replica Set, Daemon Set) может быть использован селектор на основе соответствия набору (set-based). Например:
selector:
matchLabels: component: redis matchExpressions: - {key: tier, operator: In, values: [cache]} - {key: environment, operator: NotIn, values: [dev]}
На этом с метками и селекторами все, в следующей статье рассмотрим неймспейсы (namespaces) в Kubernetes.