Kubernetes storage basics - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Volumes

Os sistemas de arquivos dos contêineres são efêmeros; os arquivos se perdem após reinicializações. Os volumes definem o armazenamento externo na especificação do pod, e o Kubernetes os monta nos contêineres durante a execução.

O ACK oferece suporte aos seguintes tipos de volume:

Tipo	Descrição
Armazenamento local	Volumes locais do nó, como `hostPath` e `emptyDir`. Os dados estão vinculados ao nó e se perdem se ele ficar indisponível. Não recomendado para cargas de trabalho com estado passíveis de reagendamento.
Armazenamento de rede	Volumes remotos, como Ceph, GlusterFS, NFS e iSCSI. Os dados residem em um serviço remoto, mas é necessário montar o serviço localmente.
Secret e ConfigMap	Volumes especiais que expõem dados de objetos do cluster (credenciais, configurações) aos pods como arquivos.
PVC	Volume respaldado por um PersistentVolumeClaim que abstrai o armazenamento como um objeto independente. Ideal para armazenamento durável e portátil.

Observações de uso:

Um pod pode montar vários volumes, inclusive de tipos diferentes.
Todos os contêineres de um pod compartilham seus volumes montados.
O volume compartilha o ciclo de vida do pod. A persistência dos dados após a exclusão do pod depende do tipo e da configuração do volume.
Para dados duráveis, use PVCs e PVs.

PVs e PVCs

Nem todos os volumes do Kubernetes são persistentes. Para garantir armazenamento durável, o Kubernetes introduz dois objetos que separam como o armazenamento é provisionado de como o armazenamento é consumido:

Um PV é um recurso de armazenamento do cluster, análogo a um nó: assim como os pods consomem nós, os PVCs consomem PVs. O PV possui ciclo de vida próprio, independente de qualquer pod.
Um PVC é uma solicitação de armazenamento, análoga a um pod: assim como um pod solicita CPU e memória de um nó, um PVC solicita capacidade e modos de acesso de um PV.

Os desenvolvedores declaram as necessidades de armazenamento (PVC), enquanto os administradores gerenciam o provisionamento (PV).

Exemplo de PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 20Gi # adjust to match the actual cloud disk size
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: diskplugin.csi.alibabacloud.com
    volumeHandle: <disk ID>
  volumeMode: Filesystem

Exemplo de PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  volumeName: pv-example

Regras de vinculação

PVs e PVCs possuem relação de um para um: exatamente um PVC se vincula a cada PV. Antes que um pod possa usar um PVC, o Kubernetes precisa encontrar um PV que atenda aos seguintes critérios:

Campo	Requisito
`volumeMode`	Deve corresponder ao modo de volume do PVC
`accessModes`	Deve incluir os modos de acesso solicitados pelo PVC
`storageClassName`	Se especificado no PVC, o PV deve ter a mesma StorageClass
Seletor de rótulo	O PV deve corresponder a qualquer seletor de rótulo definido no PVC
`storage`	A capacidade do PV deve ser pelo menos igual à quantidade solicitada pelo PVC

Como funciona o campo storage:

O Kubernetes usa storage para corresponder e vincular PVs a PVCs.
No provisionamento dinâmico, o valor de storage do PVC define a capacidade do PV e do recurso subjacente (como um disco em nuvem).
Para tipos de armazenamento compatíveis com redimensionamento, o valor de storage do PVC define a capacidade alvo após a expansão.
storage é uma declaração lógica de capacidade. A capacidade real de gravação depende do meio de armazenamento subjacente, não do campo storage.

Modos de acesso ao volume

Use o campo accessModes para definir como montar um volume:

Modo de acesso	Abreviação	Descrição	Exemplo
ReadWriteOnce	RWO	Leitura e escrita por um único nó	Disco do Alibaba Cloud
ReadOnlyMany	ROX	Somente leitura por múltiplos nós	Bucket do OSS
ReadWriteMany	RWX	Leitura e escrita por múltiplos nós	Sistema de arquivos NAS

Como os volumes são provisionados

O ACK oferece suporte a dois fluxos de trabalho de provisionamento: estático e dinâmico.

Provisionamento estático

No provisionamento estático, o administrador do cluster cria os PVs antecipadamente. Discos em nuvem, sistemas de arquivos NAS e buckets do OSS oferecem suporte ao provisionamento estático.

O administrador aloca recursos de armazenamento (por exemplo, discos em nuvem ou sistemas de arquivos NAS) com base nos requisitos dos pods.
O administrador cria PVs que descrevem esses recursos, incluindo capacidade e configuração.
Os desenvolvedores criam PVCs que declaram as necessidades de suas cargas de trabalho.
Ao criar um pod, o Kubernetes vincula o PVC a um PV correspondente.

Provisionamento dinâmico

No provisionamento dinâmico, um provisionador CSI cria PVs automaticamente quando um PVC é criado. Discos em nuvem, sistemas de arquivos NAS e buckets do OSS oferecem suporte ao provisionamento dinâmico.

O administrador cria uma StorageClass que define o tipo de armazenamento e o provisionador. Por exemplo, diskplugin.csi.alibabacloud.com provisiona discos em nuvem.
Os desenvolvedores criam PVCs referenciando uma StorageClass. Não é necessária a criação manual de PV.
Ao criar um pod, o provisionador CSI lê a StorageClass, cria um PV e o recurso de armazenamento subjacente e vincula o PV ao PVC.

O provisionamento dinâmico oferece três vantagens:

Gestão automatizada do ciclo de vida: o provisionador lida automaticamente com a criação e a exclusão de PVs.
Redução da carga operacional: os administradores gerenciam StorageClasses em vez de PVs individuais.
Consistência de capacidade: o PV e o recurso subjacente sempre correspondem à capacidade solicitada pelo PVC.

StorageClasses

Uma StorageClass define o tipo de armazenamento, o provisionador e os parâmetros usados para o provisionamento dinâmico. Quando um PVC referencia uma StorageClass e não existe nenhum PV correspondente, o Kubernetes aciona o provisionador para criar automaticamente um PV e o armazenamento subjacente.

Exemplo de StorageClass

A seguinte StorageClass provisiona discos do Alibaba Cloud:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-alltype
provisioner: diskplugin.csi.alibabacloud.com
parameters:
  type: cloud_auto,cloud_essd,cloud_ssd,cloud_efficiency
  fstype: ext4
  diskTags/a: b
  encrypted: "false"
  performanceLevel: PL1
  provisionedIops: "40000"
  burstingEnabled: "false"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Parâmetros principais

Parâmetro	Descrição
`provisioner`	Driver CSI para provisionamento de armazenamento. Use `diskplugin.csi.alibabacloud.com` para discos em nuvem, `nasplugin.csi.alibabacloud.com` para NAS ou `ossplugin.csi.alibabacloud.com` para OSS.
`parameters`	Parâmetros específicos do driver, como tipo de disco, tipo de sistema de arquivos e configurações de desempenho.
`reclaimPolicy`	Define o que acontece com o PV e o armazenamento subjacente quando o PVC é excluído. `Delete` (padrão) remove tanto o PV quanto o disco em nuvem. `Retain` mantém ambos — você deve excluí-los manualmente. Defina como `Retain` se a segurança dos dados for prioridade.
`allowVolumeExpansion`	Defina como `true` para ativar a expansão online do disco.
`volumeBindingMode`	Determina quando o PV é provisionado. Consulte a tabela abaixo.

Escolha de um volumeBindingMode:

Modo	Quando o PV é criado	Recomendado para
`Immediate` (padrão)	Quando o PVC é criado, antes do agendamento de qualquer pod	Clusters de zona única
`WaitForFirstConsumer`	Após o agendamento de um pod que usa o PVC em um nó	Clusters multizona

Use WaitForFirstConsumer em clusters multizona. Discos em nuvem não podem ser montados entre zonas diferentes. Se um PV estiver na Zona A, mas um pod for agendado para a Zona B, o pod falhará ao iniciar. Com WaitForFirstConsumer, o provisionador aguarda o agendamento do pod e então cria o disco na zona do pod.

Como funciona o WaitForFirstConsumer:

Ao criar um PVC, o provisionador aguarda até que um pod o consuma. O scheduler posiciona o pod em um nó e grava o resultado (região e nó) nos metadados do PVC. Em seguida, o provisionador cria o PV e o disco na zona correta.

StorageClass padrão

Uma StorageClass padrão provisiona automaticamente um PV para qualquer PVC que omita o nome de uma StorageClass.

Importante

Clusters ACK não incluem uma StorageClass padrão. Uma StorageClass padrão se aplica a todos os PVCs sem um storageClassName. Se seu cluster usar vários tipos de armazenamento, ele poderá provisionar o tipo errado. Ative essa opção apenas se todos os PVCs usarem o mesmo tipo de armazenamento.

Definir uma StorageClass padrão:

Marque alicloud-disk-topology-alltype como padrão:

kubectl annotate storageclass alicloud-disk-topology-alltype storageclass.kubernetes.io/is-default-class=true

Verifique a alteração:

kubectl get sc

Saída esperada:

NAME                                        PROVISIONER                       AGE
alicloud-disk-topology-alltype (default)    diskplugin.csi.alibabacloud.com   96m

Criar um PVC sem especificar uma StorageClass:

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

O cluster cria automaticamente um PV de disco em nuvem usando alicloud-disk-topology-alltype.

kubectl get pvc

Saída esperada:

NAME       STATUS   VOLUME                   CAPACITY   ACCESS MODES    STORAGECLASS                      AGE
disk-pvc   Bound    d-bp18pbai447qverm****   20Gi       RWO             alicloud-disk-topology-alltype    49s

Remover a StorageClass padrão:

kubectl annotate storageclass alicloud-disk-topology-alltype storageclass.kubernetes.io/is-default-class-

StorageClasses fornecidas pelo ACK

StorageClass	Tipo de disco	Observações
`alicloud-disk-efficiency`	Ultra disk	Disco em nuvem de geração anterior
`alicloud-disk-ssd`	Standard SSD	Disco em nuvem de geração anterior
`alicloud-disk-essd`	ESSD	Enterprise SSD Performance Level 1 (PL1)
`alicloud-disk-topology-alltype`	Múltiplos tipos	Tenta primeiro ESSD, depois Standard SSD e, por fim, Ultra Disk. Recomendado para clusters multizona.
`alibabacloud-cnfs-nas`	NAS gerenciado por CNFS	Cria volumes NAS gerenciados por Container Network File System (CNFS)

A StorageClass alicloud-disk-topology-alltype seleciona o melhor tipo de disco disponível:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-alltype
parameters:
  type: cloud_essd,cloud_ssd,cloud_efficiency
provisioner: diskplugin.csi.alibabacloud.com
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Próximos passos

Consulte Armazenamento para ver todos os tipos de armazenamento e guias.

Para provisionar tipos específicos de armazenamento: