Volumes permanentes e provisionamento do GKE

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

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

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

PersistentVolumes

Os recursos PersistentVolume 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 PersistentVolume é gerenciado pelo Kubernetes. Um PersistentVolume pode ser provisionado dinamicamente, então não é preciso criar e excluir manualmente o armazenamento de apoio.

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 dinamicamente por meio de PersistentVolumeClaims ou criados explicitamente por um administrador de cluster.

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

Os PersistentVolumeClaims

Um PersistentVolumeClaim é uma solicitação e uma declaração de um recurso PersistentVolume. Objetos PersistentVolumeClaim solicitam um tamanho específico, modo de acesso e StorageClass para o PersistentVolume. Se uma PersistentVolume que satisfaça a solicitação existir ou puder ser provisionada, 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. É possível 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.

O GKE cria para você um StorageClass padrão que usa o tipo de disco permanente equilibrado (ext4). O StorageClass padrão é usado quando um PersistentVolumeClaim não especifica um StorageClassName. É possível substituir o StorageClass padrão fornecido pelo seu. Veja as instruções em 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, precisará criar um StorageClass e especificar 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, você precisa listar um provisionador. No GKE, recomendamos que você use um dos seguintes provisionadores:

Provisionar PersistentVolumes dinamicamente

Na maioria das vezes, não é necessário configurar diretamente objetos PersistentVolume ou criar discos permanentes do Compute Engine. Em vez disso, você pode criar um PersistentVolumeClaim. O Kubernetes provisionará um disco persistente para você, de modo automático.

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 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 vai ser criado até que um pod seja programado para consumir o volume.

O exemplo a seguir 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

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 será excluído quando uma PersistentVolumeClaim (PVC) for excluída. Para isso, defina o campo reclaimPolicy na configuração StorageClass como Delete ou Retain.

  • reclaimPolicy: Delete: é 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 compliance em que os dados precisam ser limpos após a conclusão de um job.

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

Gerenciar manualmente os volumes retidos

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

  • Para excluir permanentemente o armazenamento: é necessário excluir o recurso PersistentVolume do Kubernetes e o disco do Compute Engine subjacente.

    1. Exclua o PersistentVolume: bash kubectl delete pv <your-pv-name>
    2. Para encontrar o nome do disco subjacente, descreva o arquivo de configuração YAML do PV e procure o campo volumeHandle ou 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 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 fique Available novamente. Para mais informações sobre o procedimento detalhado, consulte a documentação oficial do Kubernetes sobre 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 com exclusão inesperada de disco

Se você notar que os discos permanentes subjacentes estão sendo excluídos quando não deveriam, 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 da sua 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 à sua intenção:

    • Se a política for Delete e seu aplicativo exigir que os dados sejam mantidos, atualize o aplicativo para usar uma configuração StorageClass que defina a política como Retain.
    • Se a política for Delete e seu aplicativo for efêmero ou estiver sujeito a regras de compliance que exigem limpeza de dados, a configuração estará correta e funcionando conforme o esperado.

Para mais informações, 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 restantes do PersistentVolume no console do Google Cloud .

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

Meios de acesso

Os recursos PersistentVolume são compatíveis com os seguintes meios 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. Os recursos PersistentVolume compatíveis com discos permanentes 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 de PersistentVolume provisionados dinamicamente estão vazios quando são criados. Se você tiver um disco permanente atual do Compute Engine preenchido com dados, poderá apresentá-lo ao seu 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 x StatefulSets

É possível usar modelos PersistentVolumeClaim ou 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 disponibilidade e desempenho altos. 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, recomendamo definir o WaitForFirstConsumer modo de vinculação de volume (em inglês) na sua StorageClass. Essa configuração instrui o Kubernetes a provisionar um disco permanente na mesma zona para a qual o pod é programado. Ele respeita as restrições de programação do pod, como as antiafinidades (em inglês) e os seletores de nós. A antiafinidade nas zonas permite que os pods do StatefulSet sejam distribuídos entre as zonas com os discos correspondentes.

Veja a seguir uma StorageClass de exemplo para provisionar discos permanentes zonais que definem 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