Kubernetes Persistent Volume: Como criar um Volume Persistente no Kubernetes

Volume Persistente ou Kubernetes Persistent Volume desempenha uma função essencial na gestão de dados nos clusters do Kubernetes. Ele abstrai dados e possibilita o armazenamento consistente nos ciclos de vida dos pods.

O que é um Kubernetes Persistent Volume?

O Kubernetes Persistent Volume (PV) é essencial na orquestração do Kubernetes. Ele foi projetado para promover o gerenciamento eficiente e escalável dos dados nos clusters de um container. A finalidade do PV é oferecer uma área de armazenamento padronizada e persistente. Ele pode ser usado por diferentes pods independentemente de quais recursos de armazenamento físicos o cluster acessa. Um nível mais alto de abstração é alcançado ao separar os detalhes de armazenamento e a lógica da aplicação.

O PV é disponibilizado em formas estáticas e dinâmicas. No provisionamento estático, os recursos de armazenamento são predefinidos manualmente, enquanto no provisionamento dinâmico, o PV é criado automaticamente quando um pod apresenta requisitos de armazenamento específicos. Essa flexibilidade assegura o gerenciamento eficiente de dados persistentes nos clusters do Kubernetes, tornando as aplicações mais robustas e escaláveis.

Dica

A solução Managed Kubernetes da IONOS configura automaticamente clusters Kubernetes em servidores virtuais de alto desempenho. Graças às definições flexíveis dos nós de trabalho, você consegue adaptar os recursos de acordo com as suas necessidades. Use SDKs e ferramentas de gerenciamento de configurações para facilitar a integração e otimizar a operação.

Diferença entre Volume e Volume Persistente

Existem dois tipos básicos de volumes de armazenamento no Kubernetes: volume e Volume Persistente. Um volume considerado normal é aquele vinculado ao ciclo de vida de um único pod. Ele é declarado diretamente na configuração e usado, principalmente, no armazenamento temporário de dados durante a execução desse pod. Quando o pod é finalizado, o volume normal também é liberado e todos os dados contidos nele são excluídos.

Já o Volume Persistente tem um ciclo de vida maior e independente de um pod específico. Ele pode ser usado e liberado por vários pods em ciclos de vida diferentes. Os volumes persistentes são declarados separadamente dos pods e vinculados às solicitações Persistent Volume Claims (PVCs). A conexão entre uma PVC e um PV é feita dinamicamente ou manualmente. Os volumes persistentes são ideais em casos nos quais os dados precisam durar além do ciclo de vida de um único pod. Esse tipo de volume oferece uma maneira de compartilhar e armazenar dados entre diferentes pods, até mesmo se eles forem criados ou excluídos.

Quais tipos de Kubernetes Persistent Volumes existem?

Existem diversos tipos de Kubernetes Persistent Volumes que representam soluções e tecnologias de armazenamento diferentes. Estes são alguns dos tipos mais comuns de volumes persistentes:

  • hostPath: O tipo hostPath vincula um Kubernetes Persistent Volume a um caminho no nó do host no cluster. Ele possibilita acessar os recursos de armazenamento local do host e é uma opção adequada para ambientes de desenvolvimento e testes. No entanto, esse tipo de Volume Persistente deve ser usado com cuidado nos ambientes de produção, pois os dados não são replicados entre os nós.
  • emptyDir: O tipo emptyDir cria um volume temporário e ocioso toda vez que um pod é criado. Ele é adequado para dados temporários ou trocas de dados entre containers dentro do mesmo pod. O volume é excluído quando o pod é finalizado.
  • GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: Esses tipos associam um Kubernetes Persistent Volume a soluções externas de armazenamento em nuvem, como Google Compute Engine Persistent Disks, Amazon EBS Volumes ou Azure Disks e Azure File Shares. Eles representam uma forma de manter os dados persistentes nos pods e até mesmo nos clusters, sendo uma opção adequada para aplicações implementadas em ambientes na nuvem.
  • nfs (Network File System): Os PVs do tipo NFS são vinculados a um compartilhamento de rede que é disponibilizado pelo Network File System (NFS). Ele permite que os dados sejam compartilhados entre diferentes pods. Essa é uma alternativa útil quando múltiplos pods precisam acessar os arquivos compartilhados.
  • iscsi (Internet Small Computer System Interface): Os PVs baseados em ISCSI são vinculados a dispositivos de armazenamento em bloco que ficam disponíveis via protocolo ISCSI. Essa é uma opção para utilizar dispositivos externos de armazenamento em bloco nos clusters do Kubernetes que oferece uma solução flexível e escalável para dados persistentes.
  • local: O tipo local habilita acesso direto aos recursos de armazenamento físico no nó local do cluster do Kubernetes. Ele é especialmente útil para as aplicações que dependem de armazenamento local rápido. No entanto, é preciso ter cuidado com essa opção, pois os recursos de armazenamento local não são replicados entre os nós. Se houver uma falha no nó, os dados poderão ser perdidos.
  • csi (Container Storage Interface): O tipo CSI permite integrar provedores de armazenamento externo por meio da Container Storage Interface. Assim, os sistemas de orquestração de containers, como o Kubernetes, conseguem se comunicar com várias soluções de armazenamento de terceiros. Dessa forma, o usuário tem mais flexibilidade e consegue usar uma ampla gama de sistemas de armazenamento com suporte à CSI.
  • cephfs: CephFS é um sistema de arquivos distribuído. Os volumes persistentes do tipo CephFS são vinculados a esse sistema de arquivos. Esse tipo de PV é usado em aplicações que requerem acesso compartilhado aos arquivos e que operam em um ambiente de armazenamento distribuído, como é o caso do Ceph.
  • fc (Fibre Channel): Os volumes persistentes baseados em FC são vinculados aos dispositivos de armazenamento Fibre Channel. Esse tipo permite que você acesse as soluções de armazenamento externo baseadas em Fibre Channel. Em ambientes nos quais as redes Fibre Channel são usadas, é comum ser disponibilizado o armazenamento em bloco.
  • rbd (RADOS Block Device): O tipo RBD é vinculado aos dispositivos de armazenamento em bloco no cluster Ceph que atuam como RADOS Block Devices. Esse tipo permite acessar o sistema de armazenamento em bloco do Ceph, o que é especialmente vantajoso em ambientes de armazenamento distribuído com alta escalabilidade.

Como acessar o Kubernetes Persistent Volume

Os modos de acesso do Kubernetes Persistent Volume determinam como os pods acessam os volumes persistentes vinculados a eles. Existem três de modos de acesso principais:

  • ReadWriteOnce (RWO): Este modo permite que um único pod monte o Volume Persistente com permissões de leitura e gravação. Ele é útil para aplicações que requerem controle de acesso de gravação exclusivo. Um PV com esse modo só pode ser montado por um pod por vez.
  • ReadOnlyMany (ROX): O modo ReadOnlyMany permite que múltiplos pods montem o Volume Persistente simultaneamente no modo somente leitura. Esse é um recurso útil para aplicações que podem compartilhar dados em um modo comum no qual o acesso de gravação é restrito. Múltiplos pods podem acessar os dados paralelamente, porém no modo somente leitura.
  • ReadWriteMany (RWX): Com o modo ReadWriteMany, múltiplos pods podem montar o Volume Persistente simultaneamente no modo leitura e gravação. Esse modo é usado em situações que exigem um banco de dados compartilhado e múltiplos pods têm acesso de gravação aos dados.

Ao definir o modo, considere o tipo de acesso de dado que a sua aplicação requer e verifique se a opção escolhida oferece suporte aos padrões de acesso necessários.

Observe que nem todas as classes de armazenamento e tipos de volume oferecem suporte aos três modos de acesso. Isso depende da infraestrutura de armazenamento subjacente e do tipo específico de Volume Persistente. Portanto, é recomendável verificar a documentação da respectiva classe de armazenamento e do tipo de Volume Persistente para garantir que os padrões de acesso que você deseja são permitidos.

Ciclo de vida de um Kubernetes Persistent Volume

Os ciclos de vida do Kubernetes Persistent Volume podem ser divididos em diferentes fases que representam os processos de provisionamento, utilização e liberação do armazenamento persistente no cluster.

  1. Provisionamento: O ciclo de vida de um PV começa com sua criação ou provisionamento. O administrador do cluster cria um Volume Persistente e o configura estaticamente, com recursos de armazenamento fixos, ou dinamicamente, usando uma classe de armazenamento que habilita o provisionamento dinâmico.
  2. Vinculação: Um PV é vinculado a uma solicitação PVC quando um pod declara um requisito de armazenamento que corresponde às especificações do PV. Essa etapa assegura que o PV atenda aos requisitos de um pod específico.
  3. Utilização pelo pod: Após a conclusão do processo de vinculação, o PV pode ser utilizado por um pod capaz de ler ou gravar o volume montado, dependendo dos modos de acesso definidos durante a criação do PV.
  4. Expiração de uso: Quando um pod termina seu serviço ou é excluído, o PV associado a ele pode ser reutilizado por outro pod. O PV é mantido até que seja excluído manualmente pelo usuário ou por uma classe de armazenamento dinâmica.
  5. Liberação: O usuário pode liberar um PV explicitamente ao desconectá-lo de uma PVC. O PV poderá ser vinculado novamente, possivelmente a outra PVC ou pod.
  6. Exclusão: Por fim, o usuário pode excluir um PV se ele não for mais necessário. Isso pode ser feito manualmente ou automaticamente, se a replicação do PV for definida pela classe de armazenamento.

Como criar um Kubernetes Persistent Volume

A criação de um Kubernetes Persistent Volume é um processo dividido em vários estágios que exigem uma configuração cuidadosa.

Passo 1: Configurar Volume Persistente

O primeiro passo é abrir um editor de texto e criar um arquivo YAML contendo a configuração do Kubernetes Persistent Volume. Nomeie o arquivo como pv.yaml. Abaixo, apresentamos um exemplo simples da configuração de um PV:

apiVersion: v1
kind: PersistentVolume
metadata:
    name: my-pv
spec:
    capacity:
        storage: 1Gi
    volumeMode: Filesystem
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: manual
    hostPath:
        path: "/mnt/data"
yaml
  • apiVersion: Especifica a versão da API do Kubernetes. Nesse caso, V1.
  • kind: O tipo de objeto do Kubernetes. Nesse caso, “PersistentVolume”.
  • metadata: Contém os metadados do Volume Persistente. Por exemplo, o nome do volume. spec: Define a especificação do volume.
  • capacity: Especifica a capacidade de armazenamento. Nesse caso, 1 GB.
  • volumeMode: Especifica o modo do volume, que pode ser Filesystem ou Block. Nesse caso, usamos Filesystem.
  • accessModes: Define os modos de acesso. ReadWriteOnce indica acesso exclusivo de leitura e gravação.
  • persistentVolumeReclaimPolicy: Especifica como o volume deve ser tratado quando não for mais necessário. Retain indica que o volume deve ser excluído manualmente.
  • storageClassName: Atribui uma classe de armazenamento ao Volume Persistente.
  • hostPath: Define o caminho no sistema de arquivos do host que é usado como armazenamento para o Volume Persistente.

Passo 2: Aplicar a configuração

Depois de preencher o arquivo de configuração do PV, você pode ativá-lo com o Kubelet:

kubectl apply -f pv.yaml
shell

Esse comando envia o arquivo de configuração para o cluster do Kubernetes, que cria os recursos contidos nele.

Passo 3: Verificar a configuração

Para verificar se o Kubernetes Persistent Volume foi criado corretamente, use o comando a seguir:

kubectl get pv
shell

Esse comando listará todos os volumes persistentes no cluster.

NAME   CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS  REASON  AGE
my-pv    1Gi          RWX          Retain     Available           manual             1h
shell

Passo 4: Criar solicitação Persistent Volume Claim (PVC)

Preencha o arquivo YAML com as configurações da solicitação PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: my-pvc
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: manual
yaml

Aplique o arquivo de configuração da PVC no cluster do Kubernetes:

kubectl apply -f pvc.yaml
shell

Para verificar se a PVC foi criada com sucesso, use o comando a seguir:

kubectl get pvc
shell

O resultado será similar a este:

NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc     Bound    my-pv     1Gi           RWO          manual       1m
shell

Em seguida, crie o manifesto YAML pvc-dynamic.yaml para demonstrar o provisionamento dinâmico de uma solicitação PVC no Kubernetes. O manifesto cria e reivindica automaticamente um novo Kubernetes Persistent Volume com o tamanho de 1 GB, que é suportado pela classe de armazenamento standard.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc-dynamic
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: standard
yaml

Após a definição das configurações, ative o manifesto:

kubectl apply -f pvc-dynamic.yaml
shell

Passo 5: Vincular PVCs a pods

Para conectar a PVC ao pod, defina as configurações do pod que usará o armazenamento persistente.

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
    volumes:
    - name: mypvc-volume
        persistentVolumeClaim:
            claimName: my-pvc
    containers:
    - name: mycontainer
        image: myimage
        volumeMounts:
        - mountPath: "/app/data"
            name: mypvc-volume
yaml

Para criar o pod, aplique sua configuração no cluster do Kubernetes:

kubectl apply -f pod.yaml
shell

Se você está começando a aprender sobre Kubernetes, encontre tudo o que precisa saber sobre o processo de instalação e configuração de um cluster no tutorial Kubernetes no nosso Digital Guide.

Managed Kubernetes da IONOS
O jeito mais simples de gerenciar cargas de trabalho em contêineres.

Instalação de clusters Kubernetes totalmente automatizada, visibilidade máxima e controle de clusters K8s.

Este artigo foi útil?
Para melhorar a sua experiência, este site usa cookies. Ao acessar o nosso site, você concorda com nosso uso de cookies. Mais informações
Page top