Volumes persistentes e aprovisionamento do GKE

Esta página apresenta uma vista geral dos volumes persistentes (PVs), das reivindicações de volumes persistentes (PVCs) e das classes de armazenamento no Google Kubernetes Engine (GKE). Foca-se no armazenamento com base em discos persistentes do Compute Engine.

Aprende a criar, gerir e resolver problemas de armazenamento persistente de forma eficaz nos seus clusters do GKE para ajudar a garantir a segurança dos dados, a elevada disponibilidade e o desempenho ideal.

Esta página destina-se a especialistas de armazenamento que criam e atribuem armazenamento, bem como configuram e gerem a segurança, a proteção, o acesso e as autorizações de dados. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizador do GKE.

PersistentVolumes

Os recursos PersistentVolume são usados para gerir o armazenamento duradouro num cluster. No GKE, um PersistentVolume é normalmente suportado por um disco persistente.

Em alternativa, pode usar outras soluções de armazenamento, como o NFS. O Filestore é uma solução NFS no Google Cloud. Para saber como configurar uma instância do Filestore como uma solução de PV NFS para os seus clusters do GKE, consulte o artigo Aceda a instâncias do Filestore com o controlador CSI do Filestore na documentação do Filestore.

O ciclo de vida do PersistentVolume é gerido pelo Kubernetes. Um PersistentVolume pode ser aprovisionado dinamicamente. Não tem de criar nem eliminar manualmente o armazenamento subjacente.

Os recursos PersistentVolume são recursos de cluster que existem independentemente dos pods. Isto significa que o disco e os dados representados por um PersistentVolume continuam a existir à medida que o cluster muda e à medida que os Pods são eliminados e recriados. Os recursos PersistentVolume podem ser aprovisionados dinamicamente através do PersistentVolumeClaims ou podem ser criados explicitamente por um administrador do cluster.

Para saber mais sobre os recursos PersistentVolume, consulte a documentação de volumes persistentes do Kubernetes e a referência da API de volumes persistentes.

PersistentVolumeClaims

Uma PersistentVolumeClaim é um pedido e uma reivindicação de um recurso PersistentVolume. PersistentVolumeClaim os objetos pedem um tamanho específico, um modo de acesso e StorageClass para o PersistentVolume. Se existir ou for possível aprovisionar um PersistentVolume que satisfaça o pedido, o PersistentVolumeClaim é associado a esse PersistentVolume.

Os pods usam reivindicações como volumes. O cluster inspeciona a reivindicação para encontrar o volume associado e monta esse volume para o pod.

A portabilidade é outra vantagem da utilização do PersistentVolumes e do PersistentVolumeClaims. Pode usar a mesma especificação de Pod em diferentes clusters e ambientes porque PersistentVolume é uma interface para o armazenamento de apoio real.

StorageClasses

As implementações de volumes, como o controlador da interface de armazenamento de contentores (CSI) do disco persistente do Compute Engine são configuradas através de recursos StorageClass.

O GKE cria um StorageClass predefinido para si que usa o tipo de disco persistente equilibrado (ext4). O StorageClass predefinido é usado quando um PersistentVolumeClaim não especifica um StorageClassName. Pode substituir o StorageClass predefinido fornecido pelo seu. Para ver instruções, consulte o artigo Altere a StorageClass predefinida.

Pode criar os seus próprios recursos StorageClass para descrever diferentes classes de armazenamento. Por exemplo, as classes podem ser mapeadas para níveis de qualidade de serviço ou para políticas de cópia de segurança. Este conceito é, por vezes, denominado "perfis" noutros sistemas de armazenamento.

Se estiver a usar um cluster com pools de nós do Windows, tem de criar um StorageClass e especificar um StorageClassName no PersistentVolumeClaim porque o fstype predefinido (ext4) não é suportado com o Windows. Se estiver a usar um Persistent Disk do Compute Engine, tem de usar o NTFS como o tipo de armazenamento de ficheiros.

Quando define um StorageClass, tem de indicar um fornecedor. No GKE, recomendamos que use um dos seguintes aprovisionadores:

Aprovisione dinamicamente volumes persistentes

Na maioria das vezes, não precisa de configurar diretamente objetos PersistentVolume nem criar discos persistentes do Compute Engine. Em alternativa, pode criar um PersistentVolumeClaim e o Kubernetes aprovisiona automaticamente um disco persistente para si.

O manifesto seguinte descreve um pedido de um disco com 30 gibibytes (GiB) de armazenamento cujo modo de acesso permite que seja montado como leitura/escrita por um único nó. Também cria um Pod que consome o PersistentVolumeClaim como um volume.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Quando cria este objeto PersistentVolumeClaim com kubectl apply -f pvc-pod-demo.yaml, o Kubernetes cria dinamicamente um objeto PersistentVolume correspondente.

Uma vez que a classe de armazenamento standard-rwo usa o modo de associação de volumes WaitForFirstConsumer, o PersistentVolume não é criado até que um pod seja agendado para consumir o volume.

O exemplo seguinte mostra o PersistentVolume criado.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Partindo do princípio de que não substituiu a classe de armazenamento standard-rwo, este PersistentVolume é suportado por um novo disco persistente do Compute Engine vazio.

Elimine o armazenamento persistente

Durante o aprovisionamento dinâmico, pode controlar se o armazenamento persistente é eliminado quando um PersistentVolumeClaim (PVC) é eliminado. Para o fazer, defina o campo reclaimPolicy na configuração StorageClass como Delete ou Retain.

  • reclaimPolicy: Delete: esta é a política predefinida. Quando o PVC é eliminado, o objeto PersistentVolume (PV) e o disco subjacente (como um disco persistente do Compute Engine) são eliminados automaticamente. Use esta política para cargas de trabalho temporárias ou para requisitos de conformidade em que os dados têm de ser limpos após a conclusão de uma tarefa.

  • reclaimPolicy: Retain: se definir esta política, o PV e o disco subjacente não são eliminados quando elimina o PVC. O estado da PV é alterado para Released. Os dados são preservados, mas o volume não pode ser usado por um novo PVC até que um administrador o reclame manualmente.

Gerir manualmente os volumes retidos

Quando um PersistentVolume tem o estado Released, tem de decidir manualmente o que fazer com os dados e o disco subjacentes.

  • Para eliminar permanentemente o armazenamento: tem de eliminar o recurso do Kubernetes PersistentVolume e o disco subjacente do Compute Engine.

    1. Eliminar o PersistentVolume: bash kubectl delete pv <your-pv-name>
    2. Encontre o nome do disco subjacente descrevendo o ficheiro de configuração YAML para o PV e procurando o campo volumeHandle ou um campo semelhante.
    3. Elimine o Persistent Disk do Compute Engine: bash gcloud compute disks delete <your-disk-name> --zone=<your-zone>

  • Para reutilizar o volume: a recuperação de um volume com o estado Released para utilização por outro PVC é uma tarefa avançada que envolve a limpeza manual dos dados do disco e a edição do objeto PersistentVolume para o tornar novamente Available. Para mais informações sobre o procedimento detalhado, consulte a documentação oficial do Kubernetes sobre como reclamar um PersistentVolume.

Para evitar ou mitigar a perda de dados, também recomendamos que ative a cópia de segurança do GKE e agende cópias de segurança regulares do seu cluster do GKE.

Resolução de problemas de eliminação inesperada de discos

Se observar que os seus discos persistentes subjacentes estão a ser eliminados quando não espera que isso aconteça, a causa mais comum é um campo reclaimPolicy definido como Delete na configuração StorageClass usada pelo seu PersistentVolumeClaim.

Para diagnosticar este problema, conclua os seguintes passos:

  1. Verifique o StorageClass do seu PVC: bash kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.storageClassName}'

  2. Inspeccione o campo reclaimPolicy: bash kubectl get sc <your-storageclass-name> -o yaml

  3. Alinhe a política com a sua intenção:

    • Se a política for Delete e a sua aplicação exigir que os dados persistam, tem de atualizar a aplicação para usar uma configuração StorageClass que defina a política como Retain.
    • Se a política for Delete e a sua aplicação for efémera ou estiver sujeita a regras de conformidade que exijam a limpeza de dados, a configuração está correta e a funcionar conforme esperado.

Para mais informações, consulte a documentação do Kubernetes sobre a recuperação.

Faça a gestão do armazenamento persistente durante a eliminação do cluster

Quando um cluster do GKE é eliminado, o GKE retém os recursos com a política de recuperação Delete ou Retain.PersistentVolume

Para remover recursos PersistentVolume quando elimina um cluster, pode eliminar manualmente o espaço de nomes dos recursos PersistentVolumeClaim, o que aciona a eliminação de objetos PersistentVolume com a política Delete. Em alternativa, pode eliminar recursos PersistentVolumeClaim individuais. No entanto, o GKE não aguarda a conclusão destas atividades de eliminação antes de começar a eliminar o cluster. Assim, se eliminar um espaço de nomes e, de seguida, eliminar imediatamente o cluster, os recursos PersistentVolume com políticas Delete podem não ser eliminados.

Após a eliminação do cluster, pode ver os recursos PersistentVolume restantes na consola Google Cloud .

Para ver os recursos não usados, como recursos PersistentVolume não usados, pode ver recomendações para recursos inativos.

Modos de acesso

Os recursos do PersistentVolume suportam os seguintes modos de acesso:

  • ReadWriteOnce: o volume pode ser montado como leitura/escrita por um único nó.
  • ReadOnlyMany: o volume pode ser montado só de leitura por muitos nós.
  • ReadWriteMany: o volume pode ser montado como leitura/escrita por muitos nós. Os recursos do PersistentVolume suportados por discos persistentes do Compute Engine não suportam este modo de acesso.
  • ReadWriteOncePod: o volume só pode ser montado como leitura/escrita por um único pod.

Usar discos persistentes do Compute Engine como ReadOnlyMany

ReadWriteOnce é o exemplo de utilização mais comum para discos persistentes e funciona como o modo de acesso predefinido para a maioria das aplicações. Os discos persistentes do Compute Engine também suportam o modo ReadOnlyMany, para que muitas aplicações ou muitas réplicas da mesma aplicação possam consumir o mesmo disco em simultâneo. Um exemplo de utilização é a publicação de conteúdo estático em várias réplicas.

Para obter instruções, consulte o artigo Use discos persistentes com vários leitores.

Use discos persistentes pré-existentes como PersistentVolumes

Os recursos PersistentVolume aprovisionados dinamicamente estão vazios quando são criados. Se tiver um disco persistente do Compute Engine existente preenchido com dados, pode introduzi-lo no cluster criando manualmente um recurso PersistentVolume correspondente. O disco persistente tem de estar na mesma zona que os nós do cluster.

Consulte este exemplo de como criar um volume persistente suportado por um disco persistente pré-existente.

Implementações versus StatefulSets

Pode usar modelos PersistentVolumeClaim ou VolumeClaim em controladores de nível superior, como Implementações ou StatefulSets, respetivamente.

As implementações são concebidas para aplicações sem estado pelo que todas as réplicas de uma implementação partilham o mesmo PersistentVolumeClaim. Uma vez que os pods de réplica criados são idênticos entre si, apenas os volumes com o modo ReadWriteMany podem funcionar nesta definição.

Mesmo as implementações com uma réplica que usem o volume ReadWriteOnce não são recomendadas. Isto deve-se ao facto de a estratégia de implementação predefinida criar um segundo pod antes de desativar o primeiro pod numa recriação. A implementação pode falhar devido a um impasse, uma vez que o segundo pod não pode ser iniciado porque o volume ReadWriteOnce já está em uso, e o primeiro pod não é removido porque o segundo pod ainda não foi iniciado. Em alternativa, use um StatefulSet com volumes ReadWriteOnce.

Os StatefulSets são o método recomendado de implementação de aplicações com estado que requerem um volume único por réplica. Ao usar StatefulSets com modelos de PersistentVolumeClaim, pode ter aplicações que podem ser dimensionadas automaticamente com PersistentVolumeClaims únicos associados a cada pod de réplica.

Discos persistentes regionais

Os discos persistentes regionais são recursos multizonais que replicam dados entre duas zonas na mesma região e podem ser usados de forma semelhante aos discos persistentes zonais. No caso de uma interrupção zonal ou se os nós do cluster numa zona ficarem não agendáveis, o Kubernetes pode fazer failover das cargas de trabalho que usam o volume para a outra zona. Pode usar discos persistentes regionais para criar soluções de elevada disponibilidade para cargas de trabalho com estado no GKE. Tem de garantir que as zonas principal e de ativação pós-falha estão configuradas com capacidade de recursos suficiente para executar a carga de trabalho.

Os discos persistentes SSD regionais são uma opção para aplicações, como bases de dados, que requerem disponibilidade e desempenho elevados. Para mais detalhes, consulte o artigo Comparação do desempenho do armazenamento de blocos.

Tal como os discos persistentes zonais, os discos persistentes regionais podem ser aprovisionados dinamicamente conforme necessário ou aprovisionados manualmente com antecedência pelo administrador do cluster. Para saber como adicionar discos persistentes regionais, consulte o artigo Aprovisionar discos persistentes regionais.

Zonas em discos persistentes

Os discos persistentes zonais são recursos zonais e os discos persistentes regionais são recursos multizonais. Quando adiciona armazenamento persistente ao cluster, a menos que seja especificada uma zona, o GKE atribui o disco a uma única zona. O GKE escolhe a zona aleatoriamente. Assim que um disco persistente é aprovisionado, todos os pods que fazem referência ao disco são agendados para a mesma zona que o disco persistente. No entanto, os pods ou as implementações não reconhecem inerentemente a zona dos discos persistentes pré-existentes. Para garantir que os pods são agendados corretamente com discos persistentes pré-existentes, use métodos de posicionamento zonal, como nodeAffinity, nas especificações do pod ou da implementação para segmentar as zonas adequadas.

Modo de associação de volume WaitForFirstConsumer

Se aprovisionar dinamicamente um disco persistente no seu cluster, recomendamos que defina o WaitForFirstConsumer modo de associação de volume na sua StorageClass. Esta definição indica ao Kubernetes para aprovisionar um disco persistente na mesma zona em que o pod é agendado. Respeita as restrições de agendamento de pods, como a antiafinidade e os seletores de nós. A antiafinidade nas zonas permite que os pods StatefulSet sejam distribuídos por várias zonas, juntamente com os discos correspondentes.

Segue-se um exemplo StorageClass para o aprovisionamento de discos persistentes zonais que define WaitForFirstConsumer:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Para ver um exemplo que usa discos persistentes regionais, consulte o artigo Aprovisionar discos persistentes regionais.

O que se segue?