Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Atualizado em 2024-11-28 GMT+08:00

Noções básicas de armazenamento

Volume

Os arquivos em disco em um contêiner são efêmeros, o que apresenta os seguintes problemas para aplicações importantes em execução no contêiner:

  1. Quando um contêiner é reconstruído, os arquivos no contêiner serão perdidos.
  2. Quando vários contêineres são executados em um pod ao mesmo tempo, os arquivos precisam ser compartilhados entre os contêineres.

Os volumes do Kubernetes resolvem esses dois problemas. Volumes, como parte de um pod, não podem ser criados independentemente e só podem ser definidos em pods. Todos os contêineres em um pod podem acessar seus volumes, mas os volumes devem ter sido montados em qualquer diretório em um contêiner.

A figura a seguir mostra como um volume de armazenamento é usado entre contêineres em um pod.

Os princípios básicos para o uso de volumes são os seguintes:

  • Vários volumes podem ser montados em um pod. No entanto, não monte muitos volumes em um pod.
  • Vários tipos de volumes podem ser montados em um pod.
  • Cada volume montado em um pod pode ser compartilhado entre os contêineres no pod.
  • Recomendamos que você use PVCs e PVs para montar volumes para o Kubernetes.

O ciclo de vida de um volume é o mesmo do pod no qual o volume é montado. Quando o pod é excluído, o volume também é excluído. No entanto, os arquivos no volume podem superar o volume, dependendo do tipo de volume.

O Kubernetes fornece vários tipos de volume, que podem ser classificados como in-tree e out-of-tree.

Classificação do volume

Descrição

In-tree

Mantido por meio do repositório de código do Kubernetes e construído, editado e lançado com arquivos binários do Kubernetes. O Kubernetes não aceita mais esse tipo de volume.

Volumes nativos do Kubernetes, como HostPath, EmptyDir, Secret e ConfigMap, são todos do tipo in-tree.

As PVCs são um volume especial in-tree. O Kubernetes usa esse tipo de volume para converter de in-tree para out-of-tree. As PVCs permitem que você solicite PVs criados usando os recursos de armazenamento subjacentes fornecidos por diferentes fornecedores de armazenamento.

Out-of-tree

Os volumes out-of-tree incluem interfaces de armazenamento de contêiner (CSIs) e FlexVolumes (obsoletos). Os fornecedores de armazenamento só precisam cumprir determinadas especificações para criar complementos de armazenamento personalizados e PVs que podem ser usados pelo Kubernetes, sem adicionar código-fonte do complemento ao repositório de código do Kubernetes. O armazenamento em nuvem, como SFS e OBS, é usado instalando drivers de armazenamento em um cluster. Você precisa criar PVs no cluster e montá-los em pods usando PVCs.

PV e PVC

O Kubernetes fornece PVs (PersistentVolumes) e PVCs (PersistentVolumeClaims) para abstrair detalhes de como o armazenamento é fornecido de como é consumido. Você pode solicitar um tamanho específico de armazenamento quando necessário, assim como os pods podem solicitar níveis específicos de recursos (CPU e memória).

  • PV: descreve um volume de armazenamento persistente em um cluster. Um PV é um recurso de nível de cluster, assim como um nó. Ele se aplica a todo o cluster do Kubernetes. Um PV tem um ciclo de vida independente de qualquer Pod individual que use o PV.
  • PVC: descreve uma solicitação de armazenamento por um usuário. Ao configurar o armazenamento para uma aplicação, declare uma solicitação de armazenamento (ou seja, PVC). O Kubernetes seleciona um PV que melhor atenda à solicitação e vincula o PV à PVC. Uma vinculação de PVC a PV é um mapeamento um-para-um. Ao criar uma PVC, descreva os atributos do armazenamento persistente solicitado, como o tamanho do armazenamento e a permissão de leitura/gravação.

Você pode vincular PVCs a PVs em um pod para que o pod possa usar recursos de armazenamento. A figura a seguir mostra a relação entre PVs e PVCs.

Figura 1 Vinculação de PVC para PV

CSI

A CSI é um padrão para interfaces de armazenamento de contêineres e uma solução de implementação de plug-in de armazenamento recomendada pela comunidade do Kubernetes. everest é um complemento de armazenamento desenvolvido pela Huawei baseado na CSI. Ela fornece diferentes tipos de armazenamento persistente para contêineres.

Modos de acesso a volume

Os volumes de armazenamento podem ser montados no sistema host somente no modo suportado pelos recursos de armazenamento subjacentes. Por exemplo, um sistema de armazenamento de arquivos pode ser lido e gravado por vários nós, mas um disco EVS pode ser lido e gravado por apenas um nó.

  • ReadWriteOnce: um volume de armazenamento pode ser montado em um único nó no modo leitura-gravação.
  • ReadWriteMany: um volume de armazenamento pode ser montado em vários nós no modo leitura-gravação.
Tabela 1 Modos de acesso suportados por volumes de armazenamento

Tipo de armazenamento

ReadWriteOnce

ReadWriteMany

EVS

×

SFS

×

OBS

×

SFS Turbo

×

PV local

×

Montagem de um volume de armazenamento

Você pode montar volumes das seguintes maneiras:

Use PVs para descrever os recursos de armazenamento existentes e, em seguida, crie PVCs para usar os recursos de armazenamento em pods. Você também pode usar o modo de criação dinâmica. Ou seja, especifique a StorageClass ao criar uma PVC e use o provisionador na StorageClass para criar automaticamente um PV e vincular o PV à PVC.

Tabela 2 Modos de montagem de volumes

Modo de montagem

Descrição

Tipo de volume suportado

Outras restrições

Criar estaticamente o volume de armazenamento (usando o armazenamento existente)

Use o armazenamento existente (como discos EVS e sistemas de arquivos do SFS) para criar PVs e montá-los na carga de trabalho por meio de PVCs. O Kubernetes vincula as PVCs aos PVs correspondentes para que as cargas de trabalho possam acessar os serviços de armazenamento.

Todos os volumes

Nenhuma

Criar dinâmica de volumes de armazenamento (criação automática de armazenamento)

Especifique uma StorageClass para uma PVC. O provedor de armazenamento cria mídia de armazenamento subjacente conforme necessário para criar automaticamente PVs e vincular diretamente o PV à PVC.

EVS, OBS, SFS e PV local

Nenhuma

Montagem dinâmica (VolumeClaimTemplate)

Obtida usando o campo volumeClaimTemplates e depende da capacidade de criação dinâmica de PV da StorageClass. Neste modo, cada pod está associado a uma única PVC e PV. Depois que um pod é reprogramado, os dados originais ainda podem ser montados nele com base no nome da PVC.

EVS e PV local

Suportado apenas pelo StatefulSets

Política de recuperação da PV

Uma política de recuperação de PV é usada para excluir ou recuperar volumes subjacentes quando uma PVC é excluída. O valor pode ser Delete ou Retain.

  • Delete: a exclusão de uma PVC removerá o PV do Kubernetes, portanto, os ativos de armazenamento subjacentes associados da infraestrutura externa.

    Os recursos anuais/mensais não podem ser excluídos usando a política de recuperação Delete.

  • Retain: quando uma PVC é excluída, o PV e os recursos de armazenamento subjacentes não são excluídos. Em vez disso, você deve excluir manualmente esses recursos. Depois disso, os recursos do PV estão no estado Released e não podem ser vinculados diretamente à PVC.

    Você pode excluir e recuperar volumes manualmente executando as seguintes operações:

    1. Exclua o PV.
    2. Limpe os dados sobre os recursos de armazenamento subjacentes associados, conforme necessário.
    3. Exclua os recursos de armazenamento subjacentes associados.

    Para reutilizar os recursos de armazenamento subjacentes, crie um PV.

O CCE também permite excluir uma PVC sem excluir os recursos de armazenamento subjacentes. Esta função só pode ser obtida usando um arquivo YAML: Defina a política de recuperação de PV como Delete e adicione everest.io/reclaim-policy: retain-volume-only a annotations. Dessa forma, quando a PVC é excluída, o PV é excluído, mas os recursos de armazenamento subjacentes são retidos.

O seguinte arquivo YAML usa o EVS como exemplo:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test
  namespace: default
  annotations:
    volume.beta.kubernetes.io/storage-provisioner: everest-csi-provisioner
    everest.io/disk-volume-type: SAS
  labels:
    failure-domain.beta.kubernetes.io/region: <your_region>   # Region of the node where the application is to be deployed
    failure-domain.beta.kubernetes.io/zone: <your_zone>       # AZ of the node where the application is to be deployed
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: csi-disk
  volumeName: pv-evs-test

---
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: everest-csi-provisioner
    everest.io/reclaim-policy: retain-volume-only
  name: pv-evs-test
  labels:
    failure-domain.beta.kubernetes.io/region: <your_region>   # Region of the node where the application is to be deployed
    failure-domain.beta.kubernetes.io/zone: <your_zone>       # AZ of the node where the application is to be deployed
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 10Gi
  csi:
    driver: disk.csi.everest.io
    fsType: ext4
    volumeHandle: 2af98016-6082-4ad6-bedc-1a9c673aef20
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: everest-csi-provisioner
      everest.io/disk-mode: SCSI
      everest.io/disk-volume-type: SAS
  persistentVolumeReclaimPolicy: Delete
  storageClassName: csi-disk

Documentação

  • Para obter mais informações sobre o armazenamento do Kubernetes, consulte Armazenamento.
  • Para obter mais informações sobre o armazenamento de contêineres do CCE, consulte Visão geral.