Volumes permanentes e provisionamento dinâmico

Nesta página, você encontra uma visão geral dos volumes permanentes e declarações no Kubernetes e do uso deles com o Google Kubernetes Engine (GKE). Nesta página, o foco é o armazenamento com discos permanentes do Compute Engine.

Volumes permanentes

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. Também é possível usar outras soluções de armazenamento, como NFS. 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.

Outra opção de armazenamento é o Cloud Volumes Service. Este produto é um serviço de armazenamento de dados baseado em nuvem totalmente gerenciado que oferece recursos avançados de gerenciamento de dados e desempenho altamente escalonável.

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 (em inglês) do Kubernetes e a referência da API Persistent Volumes.

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. É 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.

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.

Como excluir o armazenamento permanente

Por padrão, a exclusão de um PersistentVolumeClaim para volumes provisionados dinamicamente, como os discos permanentes do Compute Engine, exclui o objeto PersistentVolume e o disco de apoio real. Esse comportamento é controlado pela política de recuperação no StorageClass e no PersistentVolume, que podem ser definidos como o padrão Delete ou Retain. 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 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.

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 vs. 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, quaisquer pods que façam referência a ele são programados para a mesma zona do disco.

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