Using Label Selectors

Labels passam a fazer mais sentido quando combinados com os label selectors. O label selector utiliza um conjunto de critérios baseado em labels para consultar objetos do Kubernetes. Por exemplo, podemos fazer com que o label selector selecione todos os Pods que possuem os labels env=dev e tier=frontend ou version, independente do valor atribuído.

For example, you could use a label selector to express “select all Pods with the label assignment env=dev, tier=frontend, and have a label with the key version independent of the assigned value” Não consegui reproduzir a consulta descrita pelo autor, acredito que não seja possível realiza-la com um único comando. O snippet abaixo demonstra uma seleção de labels parecida com o que o autor descreve no texto acima.
# OPÇÃO 01 (Deployment)
# Obs: Este exemplo não representa o selector mostrado na imagem abaixo.
#      Neste exemplo o mesmo Pod precisa ter os labels env, tier e version.
selector:
  matchExpressions:
    - key: env
      operator: In
      values: ["dev"]
    - key: tier
      operator: In
      values: ["frontend"]
    - key: version
      operator: Exists
template:
  metadata:
    labels:
      env: dev
      tier: frontend
      version: v1

# OPÇÃO 02 (Deployment)
# Obs: Este exemplo não representa o selector mostrado na imagem abaixo.
#      Neste exemplo o mesmo Pod precisa ter os labels env, tier e version.
selector:
  matchLabels:
    env: dev
    tier: frontend
  matchExpressions:
    - key: version
      operator: Exists
template:
  metadata:
    labels:
      env: dev
      tier: frontend
      version: v1

O Kubernetes oferece duas maneiras de selecionar objetos pelos seus labels, via linha de comando e/ou no manifesto.

Figure 6-2. Selecting Pods by label criteria

1️⃣ Label Selection from the Command Line

Através da linha de comando, você pode selecionar os objetos pelos seus labels utilizando a flag --selector ou -l de forma abreviada. Os objetos podem ser filtrados por um requisito baseado em igualdade(Equality Based Requirement) ou em conjunto(Set Based Requirement). Ambos os tipos de requisitos podem ser combinados em uma única consulta.

Equality Based Requirement

Um Equality Based Requirement utiliza os operadores =, == e !=. Você pode criar múltiplos filtros, separa-los por virgula e combina-los com uma operação AND. Até este momento, o equality based requirement não consegue expressar a operação OR.

Expressão típica: “select all Pods with the label env=prod”

Set Based Requirement

Um Set Based Requirement pode filtrar um conjunto de valores utilizando os operadores in, notIn e exists. Os operadores in e notIn funcionam baseados em uma operação booleana OR.

Expressão típica: “select all Pods with the label key env and the value prod or dev”

Para demonstrar a funcionalidade, vamos criar três Pods diferentes com labels definidos.

$ kubectl run frontend --image=nginx --restart=Never \\
  --labels=env=prod,team=shiny

$ kubectl run backend --image=nginx --restart=Never \\
  --labels=env=prod,team=legacy,app=v1.2.4

$ kubectl run database --image=nginx --restart=Never \\
  --labels=env=prod,team=storage

$ kubectl get pods --show-labels
	NAME      READY  STATUS   RESTARTS  AGE  LABELS
	backend   1/1    Running  0         37s  app=v1.2.4,env=prod,team=legacy
	database  1/1    Running  0         32s  env=prod,team=storage
	frontend  1/1    Running  0         42s  env=prod,team=shiny

Vamos começar filtrando com o equality requirement, buscamos Pods com o label env=prod.

# Buscando pods com label `env=prod`
$ kubectl get pods -l env=prod --show-labels
	NAME       READY  STATUS   RESTARTS  AGE  LABELS
	backend    1/1    Running  0         37s  app=v1.2.4,env=prod,team=legacy
	database   1/1    Running  0         32s  env=prod,team=storage
	frontend   1/1    Running  0         42s  env=prod,team=shiny

# Buscando pods com label `env=prod` e `team!=shiny`
$ kubectl get pods -l env=prod,team!=shiny --show-labels
	NAME      READY  STATUS   RESTARTS  AGE   LABELS
	backend   1/1    Running  0         41s   app=v1.2.4,env=prod,team=legacy
	database  1/1    Running  0         37s   env=prod,team=storage

# Buscando pods com label `app` definido
kubectl get pods --selector='app' --show-labels
NAME     READY  STATUS   RESTARTS  AGE    LABELS
backend  1/1    Running  0         4m44s  app=v1.2.4,env=prod,team=legacy

# Seleciona Pods com os dois labels `env=prod` e `team=shiny`
$ kubectl get pods -l env=prod,team=shiny --show-labels
NAME       READY   STATUS    RESTARTS   AGE     LABELS
frontend   1/1     Running   0          4m13s   env=prod,team=shiny

A próxima operação de filtro usa um set requirement, buscamos Pods que possuam a chave de label team com valor storage ou shiny.

# Pods cujo label `team` tem valor `shiny` ou `legacy`
$ kubectl get pods -l 'team in (shiny, legacy)' --show-labels
	NAME     READY  STATUS   RESTARTS AGE    LABELS
	backend  1/1    Running  0        7m9s   app=v1.2.4,env=prod,team=legacy
	frontend 1/1    Running  0        7m13s  env=prod,team=shiny

# Pods cujo label `team` não é `shiny` ou `legacy`
$ kubectl get pods -l 'team notin (shiny, legacy)' --show-labels
	NAME       READY   STATUS    RESTARTS   AGE   LABELS
	database   1/1     Running   0          10m   env=prod,team=storage

Por fim, combinamos equality requirement com set requirement.

# Pods cujo label `team` tem valor `shiny` ou `legacy` e label app=v1.2.4
$ kubectl get pods -l 'team in (shiny, legacy)',app=v1.2.4 --show-labels
	NAME     READY  STATUS   RESTARTS  AGE  LABELS
	backend  1/1    Running  0         29m  app=v1.2.4,env=prod,team=legacy

2️⃣ Label Selection in a Manifest

Alguns objetos avançados do Kubernetes como Deployments, Services e Network Policies atuam como proxies de configuração para os Pods. Eles geralmente selecionam um conjunto de Pods pelos seus labels. Por exemplo, em uma Network Policy apenas os Pods com labels correspondentes ao selector receberão as regras de rede. A maneira como como a seção labels é definida no manifesto baseia-se na versão da API do Kubernetes. O manifesto YAML abaixo aplica uma Network Policy utilizando equality based requirement tier=frontend.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-network-policy
spec:
  podSelector:
    matchLabels:
      tier: frontend

# Exemplo Mostrado no Inicio da Página
# OPÇÃO 01 (Deployment)
selector:
  matchExpressions:
    - key: env
      operator: In
      values: ["dev"]
    - key: tier
      operator: In
      values: ["frontend"]
    - key: version
      operator: Exists
template:
  metadata:
    labels:
      env: dev
      tier: frontend
      version: v1

# OPÇÃO 02 (Deployment)
selector:
  matchLabels:
    env: dev
    tier: frontend
  matchExpressions:
    - key: version
      operator: Exists
template:
  metadata:
    labels:
      env: dev
      tier: frontend
      version: v1

Documentação Extra

Pod needs the same key label to work with two different network policies

Untitled

Aplicando Selector para Pods cuja chave dos labels são iguais.

Kubernetes matchExpressions selector explained

In — Label’s value must match one of the specified values.
NotIn — Label’s value must not match any of the specified values.
Exists — Pod must include a label with the specified key (the value isn’t important). When using this operator, the values field should not be specified.
Exists — Pod must include a label with the specified key (the value isn’t important). When using this operator, the values field should not be specified.

DoesNotExist — Pod must not include a label with the specified key. The values property must not be specified.

selector:
  matchLabels:
    tier: frontend
  matchExpressions:
    - {key: name, operator: In, values: [payroll, web]}
    - {key: environment, operator: NotIn, values: [dev]}