Volumes permanentes com discos permanentes

Nesta página, fornecemos uma visão geral de PersistentVolumes e PersistentVolumeClaims no Kubernetes e do respectivo uso com o Google Kubernetes Engine. Nesta página, o foco é o armazenamento respaldado por discos permanentes do Compute Engine.

Visão geral

Os recursos PersistentVolume são usados para gerenciar o armazenamento durável em um cluster. No GKE, os PersistentVolumes geralmente são respaldados por discos permanentes do Compute Engine. Os PersistentVolumes também podem ser usados com outros tipos de armazenamento, como o NFS. Consulte a documentação do Kubernetes para uma visão geral exaustiva de PersistentVolumes.

Ao contrário dos Volumes, o ciclo de vida dos PersistentVolumes é gerenciado pelo Kubernetes. Os PersistentVolumes podem ser provisionados dinamicamente, de modo que o usuário não precisa criar e excluir manualmente o armazenamento de apoio.

Os PersistentVolumes 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 podem ser explicitamente criados por um administrador de cluster.

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 satisfizer a solicitação existir ou puder ser provisionado, o PersistentVolumeClaim será associado a ele.

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

A portabilidade é outra vantagem do uso de PersistentVolumes e PersistentVolumeClaims. Você pode facilmente usar a mesma especificação de pod em diferentes clusters e ambientes, já que o PersistentVolume é uma interface para o armazenamento de respaldo real.

StorageClasses

Implementações de volume, como gcePersistentDisk, são configuradas por meio dos recursos StorageClass. O GKE cria para você um StorageClass padrão que usa o tipo de disco permanente padrão. O StorageClass padrão é usado quando um PersistentVolumeClaim não especifica um StorageClassName. Você pode substituir o StorageClass padrão fornecido pelo seu.

Você pode criar seus próprios recursos do 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.

Como 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, você pode criar um PersistentVolumeClaim e o Kubernetes provisiona automaticamente um disco permanente para você.

O manifesto a seguir descreve uma solicitação para um disco de 30 GiB com um modo de acesso que permite que ele seja ativado por um pod por vez no modo de leitura/gravação:

pvc-demo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: helloweb-disk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
    

Quando você cria esse PersistentVolumeClaim com kubectl apply -f pvc-demo.yaml, o Kubernetes cria dinamicamente um objeto PersistentVolume correspondente. Se você não substituiu a classe de armazenamento padrão do GKE, esse PersistentVolume é respaldado por um disco permanente novo e vazio do Compute Engine. Você usa esse disco em um pod usando a declaração como um volume.

Quando você exclui essa declaração, o objeto PersistentVolume correspondente e o disco permanente provisionado do Compute Engine também são excluídos.

Se você quiser evitar a exclusão de discos permanentes provisionados dinamicamente, defina a política de recuperação do recurso PersistentVolume, ou o recurso StorageClass dele, como Retain. Nesse caso, você será cobrado pelo tempo que o disco permanente existir, mesmo que não haja nenhum PersistentVolumeClaim consumindo-o.

Meios de acesso

Os PersistentVolumes são compatíveis com os seguintes meios de acesso:

  • ReadWriteOnce: o Volume pode ser ativado como leitura-gravação por um único nó.
  • ReadOnlyMany: o Volume pode ser ativado somente para leitura por muitos nós.
  • ReadWriteMany: o Volume pode ser ativado como leitura-gravação por muitos nós. Os PersistentVolumes que são respaldados pelos discos permanentes do Compute Engine não são compatíveis com esse meio 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.

Consulte este artigo para instruções sobre como criar discos permanentes para vários leitores.

Como usar discos permanentes preexistentes como PersistentVolumes

Os PersistentVolumes provisionados dinamicamente estão vazios quando são criados. Se você tiver um disco permanente existente 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 declarações de volume permanentes ou modelos de declaração de volume em controladores de nível superior, como Implantações ou StatefulSets, respectivamente.

As implantações são projetadas para aplicativos sem estado e, portanto, todas as réplicas de uma implantação compartilham a mesma solicitação de volume permanente. Como as réplicas dos pods criados serão idênticas entre si, apenas volumes com modos ReadOnlyMany ou ReadWriteMany podem funcionar nessa configuração.

Mesmo as implantações com uma réplica usando um volume ReadWriteOnce não são recomendadas. Isso ocorre porque a estratégia de implantação padrão criará 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 informações de estado que exigem um volume exclusivo por réplica. Ao usar StatefulSets com modelos de declaração de volume permanente, você pode ter aplicativos capazes de escalonar automaticamente com declarações de volume permanente exclusivas associadas a cada pod de réplica.

Discos permanentes regionais

Os discos permanentes regionais replicam dados entre duas zonas na mesma região e podem ser usados de maneira semelhante aos discos permanentes regulares. No caso de uma interrupção zonal, o Kubernetes pode fazer o failover de cargas de trabalho usando o volume para a outra zona. Você pode usar discos permanentes regionais para criar soluções de alta disponibilidade para cargas de trabalho com estado no GKE. Os usuários precisam 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 regulares, 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 estas instruções sobre o provisionamento de discos permanentes regionais.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine