1
resposta

Porque não devo usar o SELECTOR para um PV

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: volume-mysql spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - {key: environment, operator: In, values: [dev]}

1 resposta

Olá, Denis.

Tudo bem?

A sua dúvida sobre o uso do selector em um PersistentVolumeClaim (PVC) é muito pertinente. Vamos entender por que é geralmente desaconselhado usar o selector ao criar um PVC.

O que é o selector?

O selector é uma maneira de filtrar quais PersistentVolumes (PVs) podem ser vinculados ao seu PVC. Ele permite que você especifique critérios específicos, como matchLabels e matchExpressions, para encontrar um PV que atenda a esses critérios.

Por que evitar o selector?

  1. Complexidade Adicional: O uso de selectors adiciona uma camada extra de complexidade. Você precisa garantir que os PVs correspondam exatamente aos critérios definidos no selector, o que pode ser difícil de gerenciar em ambientes dinâmicos.

  2. Provisionamento Dinâmico: Quando você usa selectors, está essencialmente forçando o Kubernetes a encontrar um PV que já exista e que corresponda aos critérios. Isso vai contra a ideia de provisionamento dinâmico, onde o Kubernetes cria automaticamente um PV que atende às necessidades do PVC. No seu caso, você mencionou que está usando provisionamento dinâmico, então o selector não é necessário.

  3. Erros de Vinculação: Se não houver PVs que correspondam aos critérios do selector, o PVC não será vinculado, resultando em falhas. Isso pode causar problemas de disponibilidade para sua aplicação, especialmente em ambientes de produção.

Exemplo Prático

Vamos comparar dois exemplos de PVCs, um com selector e outro sem:

Com selector:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume-mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Sem selector:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume-mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow

No exemplo sem selector, o Kubernetes pode criar um PV que atende automaticamente às necessidades do PVC, simplificando o processo e reduzindo a chance de erros.

Remover o selector do seu PVC facilita o provisionamento dinâmico e reduz a complexidade e a possibilidade de erros de vinculação. Isso é especialmente útil em ambientes onde a flexibilidade e a simplicidade são cruciais.

Espero ter ajudado. Qualquer dúvida manda aqui. Bons estudos.