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:
- Quando um contêiner é reconstruído, os arquivos no contêiner serão perdidos.
- 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.
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.
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.
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:
- Exclua o PV.
- Limpe os dados sobre os recursos de armazenamento subjacentes associados, conforme necessário.
- 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.
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.