Volumes permanentes e provisionamento do GKE

Nesta página, você encontra uma visão geral dos volumes permanentes (PVs, na sigla em inglês), das declarações de volume permanente (PVCs, na sigla em inglês) e das classes de armazenamento no Google Kubernetes Engine (GKE). O foco é o armazenamento com discos permanentes do Compute Engine.

Você vai aprender a criar, gerenciar e solucionar problemas de armazenamento permanente nos clusters do GKE para garantir a segurança de dados, a alta disponibilidade e o desempenho ideal.

Esta página é destinada a especialistas em armazenamento que criam e alocam armazenamento e configuram e gerenciam a segurança de dados, a proteção, o acesso e as permissões. Para saber mais sobre os papéis comuns e as tarefas de exemplo mencionados no conteúdo doGoogle Cloud , consulte Tarefas e papéis de usuário comuns do GKE.

PersistentVolumes

Os PersistentVolumes são usados para gerenciar o armazenamento durável em um cluster. No GKE, um PersistentVolume normalmente é apoiado por um disco permanente.

É possível 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 NFS PV para seus clusters do GKE, consulte Acessar instâncias do Filestore com o driver CSI do Filestore na documentação do Filestore.

O ciclo de vida do PersistentVolume é gerenciado pelo Kubernetes. Um PersistentVolume pode ser provisionado dinamicamente, então não é preciso criar e excluir manualmente o armazenamento de apoio.

Recursos PersistentVolume são recursos de cluster que existem independentemente dos pods. Isso significa que o disco e os dados representados por um PersistentVolume continuam existindo enquanto o cluster é alterado e os pods são excluídos e recriados. Os recursos PersistentVolume podem ser provisionados de forma dinâmica por um PersistentVolumeClaims ou explicitamente criados por um administrador de cluster.

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

Os PersistentVolumeClaims

Um PersistentVolumeClaim é uma solicitação e uma declaração de um PersistentVolume. Objetos PersistentVolumeClaim solicitam tamanho, modo de acesso e StorageClass específicos para o PersistentVolume. Se um PersistentVolume que atende à solicitação existir ou puder ser provisionado, o PersistentVolumeClaim será vinculado a esse PersistentVolume.

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

A portabilidade é outra vantagem do uso de PersistentVolumes e PersistentVolumeClaims. É fácil usar a mesma especificação de pod em diferentes clusters e ambientes, já que o PersistentVolume é uma interface com o armazenamento de apoio real.

StorageClasses

As implementações de volume, como o driver da Interface de Armazenamento de Contêiner (CSI, na sigla em inglês) do disco permanente do Compute Engine, são configuradas por recursos StorageClass.

Para PersistentVolumeClaims que não especificam explicitamente um StorageClass, o GKE define um StorageClass padrão que depende do modo de acesso, da seguinte maneira:

  • Para declarações ReadWriteOnce: o GKE usa como padrão o StorageClass standard-rwo.
  • Para declarações ReadWriteMany: no GKE versão 1.37.1 e mais recentes, o GKE usa como padrão o StorageClass regional-rwx. Para mais informações, consulte Atribuição padrão de StorageClass.

É possível substituir o StorageClass padrão fornecido por um de sua preferência. Para instruções, consulte Alterar o StorageClass padrão.

É possível criar 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 backup. Esse conceito é algumas vezes chamado de "perfis" em outros sistemas de armazenamento.

Se você estiver usando um cluster com pools de nós do Windows, crie um StorageClass e especifique um storageClassName no PersistentVolumeClaim, porque o fstype padrão (ext4) não é compatível com o Windows. Se você estiver usando um disco permanente do Compute Engine, use o NTFS como o tipo de armazenamento de arquivos.

Ao definir um StorageClass, é preciso listar um provisionador. No GKE, recomendamos que você use um dos seguintes provisionadores:

Provisionar PersistentVolumes dinamicamente

Na maioria das vezes, você não precisa configurar objetos PersistentVolume diretamente nem criar discos permanentes do Compute Engine. Em vez disso, é possível criar um PersistentVolumeClaim e o Kubernetes provisiona automaticamente um disco permanente para você.

O manifesto a seguir descreve uma solicitação para um disco com 30 gibibytes (GiB) de armazenamento cujo modo de acesso permite que ele seja ativado como leitura/gravação por um único nó. Ele também cria um pod que consome o PersistentVolumeClaim como 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 você cria esse objeto PersistentVolumeClaim com kubectl apply -f pvc-pod-demo.yaml, o Kubernetes cria dinamicamente um objeto PersistentVolume correspondente.

Como a classe de armazenamento standard-rwo usa o modo de vinculação de volume WaitForFirstConsumer, o PersistentVolume não será criado até que um pod seja programado para consumir o volume.

No exemplo a seguir, mostramos 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

Se você não substituiu a classe de armazenamento standard-rwo, esse PersistentVolume é respaldado por um disco permanente novo e vazio do Compute Engine.

Excluir armazenamento permanente

Durante o provisionamento dinâmico, é possível controlar se o armazenamento permanente é excluído quando um PersistentVolumeClaim (PVC) é excluído. Para fazer isso, defina o campo reclaimPolicy na configuração do StorageClass como Delete ou Retain.

  • reclaimPolicy: Delete: esta é a política padrão. Quando o PVC é excluído, o objeto PersistentVolume (PV) e o disco subjacente (como um disco permanente do Compute Engine) são excluídos automaticamente. Use essa política para cargas de trabalho temporárias ou para requisitos de conformidade em que os dados precisam ser limpos após a conclusão de um job.

  • reclaimPolicy: Retain: se você definir essa política, o PersistentVolume e o disco subjacente não serão excluídos quando você excluir o PersistentVolumeClaim. O status do PersistentVolume muda para Released. Os dados são preservados, mas o volume não pode ser usado por um novo PersistentVolumeClaim até que um administrador o recupere manualmente.

Como gerenciar manualmente os volumes retidos

Quando um PersistentVolume tem o status Released, você precisa decidir manualmente o que fazer com os dados e o disco subjacentes.

  • Para excluir permanentemente o armazenamento: exclua o recurso PersistentVolume do Kubernetes e o disco do Compute Engine.

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

  • Para reutilizar o volume: recuperar um volume com o status Released para uso por outro PVC é uma tarefa avançada que envolve limpar manualmente os dados do disco e editar o objeto PersistentVolume para que ele volte a ser Available. Para mais informações sobre o procedimento detalhado, consulte a documentação oficial do Kubernetes sobre Como recuperar um PersistentVolume.

Para evitar ou reduzir a perda de dados, também recomendamos ativar o Backup para GKE e programar backups regulares do cluster do GKE.

Solução de problemas de exclusão inesperada de disco

Se você notar que os discos permanentes estão sendo excluídos quando você não espera que isso aconteça, a causa mais comum é um campo reclaimPolicy definido como Delete na configuração StorageClass usada pelo PersistentVolumeClaim.

Para diagnosticar esse problema, siga estas etapas:

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

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

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

    • Se a política for Delete e o aplicativo exigir que os dados persistam, atualize o aplicativo para usar uma configuração de StorageClass que defina a política como Retain.
    • Se a política for Delete e o aplicativo for temporário ou estiver sujeito a regras de compliance que exigem a limpeza de dados, a configuração está correta e funcionando como esperado.

Para saber mais, consulte a documentação do Kubernetes sobre Recuperação.

Gerenciar o armazenamento permanente durante a exclusão do cluster

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

Para remover recursos PersistentVolume ao excluir um cluster, é possível excluir manualmente o namespace dos recursos PersistentVolumeClaim, o que vai acionar a exclusão de objetos PersistentVolume com a política Delete. Como alternativa, exclua os recursos PersistentVolumeClaim individuais. No entanto, o GKE não espera até que essas atividades de exclusão sejam concluídas antes de começar a excluir o cluster. Portanto, se você excluir um namespace e o cluster imediatamente, talvez os recursos PersistentVolume com políticas Delete não sejam excluídos.

Após a exclusão do cluster, é possível ver os recursos PersistentVolume restantes no console do Google Cloud .

Para visualizar recursos não utilizados, como os PersistentVolume não utilizados, confira recomendações para recursos inativos.

Modos de acesso

Os recursos PersistentVolume são compatíveis com os seguintes modos de acesso:

  • ReadWriteOnce: o volume pode ser montado como leitura-gravação por um único nó.
  • ReadOnlyMany: o volume pode ser montado somente para leitura por muitos nós.
  • ReadWriteMany: o volume pode ser montado como leitura-gravação por muitos nós. O nível de suporte para esse modo no GKE depende do tipo de armazenamento, conforme descrito a seguir:
    • Armazenamento de arquivos compartilhados: o Filestore é a solução recomendada para acesso a arquivos compartilhados de vários gravadores no GKE.
    • Armazenamento em blocos: o Hyperdisk Balanced High Availability oferece suporte a esse modo quando o PersistentVolumeClaim usa a configuração volumeMode: Block. Esse modo de volume expõe o disco como um dispositivo de bloco bruto (vetor de bytes), em vez de um sistema de arquivos distribuído. Seu aplicativo precisa gerenciar a própria consistência de dados, por exemplo, usando reservas SCSI.
    • Discos permanentes padrão: os discos permanentes padrão do Compute Engine não são compatíveis com esse modo de acesso.
  • ReadWriteOncePod: o volume pode ser montado como leitura-gravação por um único pod.

Como usar discos permanentes do Compute Engine como ReadOnlyMany

ReadWriteOnce é o caso de uso mais comum para discos permanentes e funciona como o meio de acesso padrão para a maioria dos aplicativos. Os discos permanentes do Compute Engine também são compatíveis com o modo ReadOnlyMany, para que muitos aplicativos ou muitas réplicas do mesmo aplicativo consumam o mesmo disco ao mesmo tempo. Um exemplo de caso de uso é a disponibilização de conteúdo estático em várias réplicas.

Para instruções, consulte Usar discos permanentes com vários leitores.

Usar discos permanentes preexistentes como PersistentVolumes

Os recursos PersistentVolume provisionados dinamicamente ficam vazios quando são criados. Se você tiver um disco permanente do Compute Engine preenchido com dados, será possível introduzi-lo no cluster criando manualmente um recurso PersistentVolume correspondente. O disco permanente precisa estar na mesma zona que os nós do cluster.

Consulte este exemplo de como criar um volume permanente respaldado por um disco permanente preexistente.

Implantações versus StatefulSets

É possível usar um PersistentVolumeClaim ou modelos VolumeClaim em controladores de nível superior, como Implantações ou StatefulSets, respectivamente.

As implantações foram projetadas para aplicativos sem estado, de modo que todas as réplicas de uma implantação compartilhem o mesmo PersistentVolumeClaim. Como as réplicas de pods criados são idênticos entre si, somente os volumes com o modo ReadWriteMany podem funcionar nessa configuração.

Implantações com uma réplica que use um volume ReadWriteOnce também não são recomendados. Afinal a estratégia de implantação padrão cria um segundo pod antes de desativar o primeiro pod em uma recriação. A implantação pode falhar no deadlock, já que o segundo pod não pode ser iniciado porque o volume ReadWriteOnce já está em uso, e o primeiro pod não será removido porque o segundo pod ainda não foi iniciado. Em vez disso, use um StatefulSet com volumes ReadWriteOnce.

StatefulSets são o método recomendado para implantar aplicativos com estado que exigem um volume exclusivo por réplica. Ao usar StatefulSets com modelos PersistentVolumeClaim, você tem aplicativos capazes fazer o escalonamento vertical automaticamente com PersistentVolumesClaims exclusivos que estão associados a cada pod de réplica.

Discos permanentes regionais

Os discos permanentes regionais são recursos multizonais que replicam dados entre duas zonas na mesma região e podem ser usados de maneira semelhante aos discos permanentes zonais. No caso de uma falha zonal ou se os nós do cluster de uma zona não puderem ser programados, o Kubernetes poderá usar o volume para fazer o failover das cargas de trabalho para a outra zona. É possível usar discos permanentes regionais para criar soluções altamente disponíveis para cargas de trabalho com estado no GKE. É preciso garantir que as zonas principal e de failover estejam configuradas com capacidade de recursos suficiente para executar a carga de trabalho.

Os discos permanentes SSD regionais são uma opção para aplicativos, como bancos de dados, que exigem alta disponibilidade e alto desempenho. Para mais detalhes, consulte Comparação de desempenho do armazenamento em blocos.

Como ocorre com os discos permanentes zonais, os discos permanentes regionais podem ser provisionados dinamicamente conforme necessário ou provisionados manualmente com antecedência pelo administrador do cluster. Para saber como adicionar discos permanentes regionais, consulte Como provisionar discos permanentes regionais.

Zonas em discos permanentes

Os discos permanentes zonais são recursos zonais, e os discos permanentes regionais são recursos multizonais. Quando você adiciona armazenamento permanente ao cluster, o GKE atribui o disco a uma única zona, a menos que ela seja especificada. O GKE escolhe a zona aleatoriamente. Após o provisionamento de um disco permanente, todos os pods com referência a ele são programados para a mesma zona do disco permanente. No entanto, pods ou implantações não reconhecem inerentemente a zona de discos permanentes preexistentes. Para garantir que os pods sejam programados corretamente com discos permanentes preexistentes, use métodos de posicionamento zonal, como nodeAffinity, nas especificações do pod ou da implantação para destinar as zonas apropriadas.

Modo de vinculação de volume WaitForFirstConsumer

Se você provisionar dinamicamente um disco permanente no cluster, recomendamos definir o WaitForFirstConsumer modo de vinculação de volume na sua definição de StorageClass. Essa configuração instrui o Kubernetes a provisionar um disco permanente na mesma zona em que o pod está programado. Ele respeita as restrições de programação de pods, como antiafinidade e seletores de nós. A antiafinidade nas zonas permite que os pods do StatefulSet sejam distribuídos entre as zonas com os discos correspondentes. Além disso, essa configuração ajuda a mitigar problemas quando uma zona não tem capacidade de computação, adiando o provisionamento de armazenamento até que um nó íntegro e disponível possa ser protegido. Esse provisionamento adiado ajuda a evitar que o aplicativo com estado seja bloqueado permanentemente em uma zona degradada, em que ficaria preso em um estado Pending.

Veja a seguir um exemplo de definição de StorageClass para provisionar discos permanentes 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 usando discos permanentes regionais, consulte Como provisionar discos permanentes regionais.

A seguir