Ku­ber­ne­tes Per­sis­tent Volume: Como criar um Volume Per­sis­tente no Ku­ber­ne­tes

Volume Per­sis­tente ou Ku­ber­ne­tes Per­sis­tent Volume de­sem­pe­nha uma função essencial na gestão de dados nos clusters do Ku­ber­ne­tes. Ele abstrai dados e pos­si­bi­lita o ar­ma­ze­na­mento con­sis­tente nos ciclos de vida dos pods.

O que é um Ku­ber­ne­tes Per­sis­tent Volume?

O Ku­ber­ne­tes Per­sis­tent Volume (PV) é essencial na or­ques­tra­ção do Ku­ber­ne­tes. Ele foi projetado para promover o ge­ren­ci­a­mento eficiente e escalável dos dados nos clusters de um container. A fi­na­li­dade do PV é oferecer uma área de ar­ma­ze­na­mento pa­dro­ni­zada e per­sis­tente. Ele pode ser usado por di­fe­ren­tes pods in­de­pen­den­te­mente de quais recursos de ar­ma­ze­na­mento físicos o cluster acessa. Um nível mais alto de abstração é alcançado ao separar os detalhes de ar­ma­ze­na­mento e a lógica da aplicação.

O PV é dis­po­ni­bi­li­zado em formas estáticas e dinâmicas. No pro­vi­si­o­na­mento estático, os recursos de ar­ma­ze­na­mento são pre­de­fi­ni­dos ma­nu­al­mente, enquanto no pro­vi­si­o­na­mento dinâmico, o PV é criado au­to­ma­ti­ca­mente quando um pod apresenta re­qui­si­tos de ar­ma­ze­na­mento es­pe­cí­fi­cos. Essa fle­xi­bi­li­dade assegura o ge­ren­ci­a­mento eficiente de dados per­sis­ten­tes nos clusters do Ku­ber­ne­tes, tornando as apli­ca­ções mais robustas e es­ca­lá­veis.

Diferença entre Volume e Volume Per­sis­tente

Existem dois tipos básicos de volumes de ar­ma­ze­na­mento no Ku­ber­ne­tes: volume e Volume Per­sis­tente. Um volume con­si­de­rado normal é aquele vinculado ao ciclo de vida de um único pod. Ele é declarado di­re­ta­mente na con­fi­gu­ra­ção e usado, prin­ci­pal­mente, no ar­ma­ze­na­mento tem­po­rá­rio de dados durante a execução desse pod. Quando o pod é fi­na­li­zado, o volume normal também é liberado e todos os dados contidos nele são excluídos.

Já o Volume Per­sis­tente tem um ciclo de vida maior e in­de­pen­dente de um pod es­pe­cí­fico. Ele pode ser usado e liberado por vários pods em ciclos de vida di­fe­ren­tes. Os volumes per­sis­ten­tes são de­cla­ra­dos se­pa­ra­da­mente dos pods e vin­cu­la­dos às so­li­ci­ta­ções Per­sis­tent Volume Claims (PVCs). A conexão entre uma PVC e um PV é feita di­na­mi­ca­mente ou ma­nu­al­mente. Os volumes per­sis­ten­tes 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 com­par­ti­lhar e armazenar dados entre di­fe­ren­tes pods, até mesmo se eles forem criados ou excluídos.

Quais tipos de Ku­ber­ne­tes Per­sis­tent Volumes existem?

Existem diversos tipos de Ku­ber­ne­tes Per­sis­tent Volumes que re­pre­sen­tam soluções e tec­no­lo­gias de ar­ma­ze­na­mento di­fe­ren­tes. Estes são alguns dos tipos mais comuns de volumes per­sis­ten­tes:

• hostPath: O tipo hostPath vincula um Ku­ber­ne­tes Per­sis­tent Volume a um caminho no nó do host no cluster. Ele pos­si­bi­lita acessar os recursos de ar­ma­ze­na­mento local do host e é uma opção adequada para ambientes de de­sen­vol­vi­mento e testes. No entanto, esse tipo de Volume Per­sis­tente deve ser usado com cuidado nos ambientes de produção, pois os dados não são re­pli­ca­dos entre os nós.
• emptyDir: O tipo emptyDir cria um volume tem­po­rá­rio e ocioso toda vez que um pod é criado. Ele é adequado para dados tem­po­rá­rios ou trocas de dados entre con­tai­ners dentro do mesmo pod. O volume é excluído quando o pod é fi­na­li­zado.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: Esses tipos associam um Ku­ber­ne­tes Per­sis­tent Volume a soluções externas de ar­ma­ze­na­mento em nuvem, como Google Compute Engine Per­sis­tent Disks, Amazon EBS Volumes ou Azure Disks e Azure File Shares. Eles re­pre­sen­tam uma forma de manter os dados per­sis­ten­tes nos pods e até mesmo nos clusters, sendo uma opção adequada para apli­ca­ções im­ple­men­ta­das em ambientes na nuvem.
• nfs (Network File System): Os PVs do tipo NFS são vin­cu­la­dos a um com­par­ti­lha­mento de rede que é dis­po­ni­bi­li­zado pelo Network File System (NFS). Ele permite que os dados sejam com­par­ti­lha­dos entre di­fe­ren­tes pods. Essa é uma al­ter­na­tiva útil quando múltiplos pods precisam acessar os arquivos com­par­ti­lha­dos.
• iscsi (Internet Small Computer System Interface): Os PVs baseados em ISCSI são vin­cu­la­dos a dis­po­si­ti­vos de ar­ma­ze­na­mento em bloco que ficam dis­po­ní­veis via protocolo ISCSI. Essa é uma opção para utilizar dis­po­si­ti­vos externos de ar­ma­ze­na­mento em bloco nos clusters do Ku­ber­ne­tes que oferece uma solução flexível e escalável para dados per­sis­ten­tes.
• local: O tipo local habilita acesso direto aos recursos de ar­ma­ze­na­mento físico no nó local do cluster do Ku­ber­ne­tes. Ele é es­pe­ci­al­mente útil para as apli­ca­ções que dependem de ar­ma­ze­na­mento local rápido. No entanto, é preciso ter cuidado com essa opção, pois os recursos de ar­ma­ze­na­mento local não são re­pli­ca­dos 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 pro­ve­do­res de ar­ma­ze­na­mento externo por meio da Container Storage Interface. Assim, os sistemas de or­ques­tra­ção de con­tai­ners, como o Ku­ber­ne­tes, conseguem se comunicar com várias soluções de ar­ma­ze­na­mento de terceiros. Dessa forma, o usuário tem mais fle­xi­bi­li­dade e consegue usar uma ampla gama de sistemas de ar­ma­ze­na­mento com suporte à CSI.
• cephfs: CephFS é um sistema de arquivos dis­tri­buído. Os volumes per­sis­ten­tes do tipo CephFS são vin­cu­la­dos a esse sistema de arquivos. Esse tipo de PV é usado em apli­ca­ções que requerem acesso com­par­ti­lhado aos arquivos e que operam em um ambiente de ar­ma­ze­na­mento dis­tri­buído, como é o caso do Ceph.
• fc (Fibre Channel): Os volumes per­sis­ten­tes baseados em FC são vin­cu­la­dos aos dis­po­si­ti­vos de ar­ma­ze­na­mento Fibre Channel. Esse tipo permite que você acesse as soluções de ar­ma­ze­na­mento externo baseadas em Fibre Channel. Em ambientes nos quais as redes Fibre Channel são usadas, é comum ser dis­po­ni­bi­li­zado o ar­ma­ze­na­mento em bloco.
• rbd (RADOS Block Device): O tipo RBD é vinculado aos dis­po­si­ti­vos de ar­ma­ze­na­mento em bloco no cluster Ceph que atuam como RADOS Block Devices. Esse tipo permite acessar o sistema de ar­ma­ze­na­mento em bloco do Ceph, o que é es­pe­ci­al­mente vantajoso em ambientes de ar­ma­ze­na­mento dis­tri­buído com alta es­ca­la­bi­li­dade.

Como acessar o Ku­ber­ne­tes Per­sis­tent Volume

Os modos de acesso do Ku­ber­ne­tes Per­sis­tent Volume de­ter­mi­nam como os pods acessam os volumes per­sis­ten­tes vin­cu­la­dos a eles. Existem três de modos de acesso prin­ci­pais:

• ReadWriteOnce (RWO): Este modo permite que um único pod monte o Volume Per­sis­tente com per­mis­sões de leitura e gravação. Ele é útil para apli­ca­çõ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 Per­sis­tente si­mul­ta­ne­a­mente no modo somente leitura. Esse é um recurso útil para apli­ca­ções que podem com­par­ti­lhar dados em um modo comum no qual o acesso de gravação é restrito. Múltiplos pods podem acessar os dados pa­ra­le­la­mente, porém no modo somente leitura.
• ReadWriteMany (RWX): Com o modo ReadWriteMany, múltiplos pods podem montar o Volume Per­sis­tente si­mul­ta­ne­a­mente no modo leitura e gravação. Esse modo é usado em situações que exigem um banco de dados com­par­ti­lhado 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 ne­ces­sá­rios.

Observe que nem todas as classes de ar­ma­ze­na­mento e tipos de volume oferecem suporte aos três modos de acesso. Isso depende da in­fra­es­tru­tura de ar­ma­ze­na­mento sub­ja­cente e do tipo es­pe­cí­fico de Volume Per­sis­tente. Portanto, é re­co­men­dá­vel verificar a do­cu­men­ta­ção da res­pec­tiva classe de ar­ma­ze­na­mento e do tipo de Volume Per­sis­tente para garantir que os padrões de acesso que você deseja são per­mi­ti­dos.

Ciclo de vida de um Ku­ber­ne­tes Per­sis­tent Volume

Os ciclos de vida do Ku­ber­ne­tes Per­sis­tent Volume podem ser divididos em di­fe­ren­tes fases que re­pre­sen­tam os processos de pro­vi­si­o­na­mento, uti­li­za­ção e liberação do ar­ma­ze­na­mento per­sis­tente no cluster.

1. Pro­vi­si­o­na­mento: O ciclo de vida de um PV começa com sua criação ou pro­vi­si­o­na­mento. O ad­mi­nis­tra­dor do cluster cria um Volume Per­sis­tente e o configura es­ta­ti­ca­mente, com recursos de ar­ma­ze­na­mento fixos, ou di­na­mi­ca­mente, usando uma classe de ar­ma­ze­na­mento que habilita o pro­vi­si­o­na­mento dinâmico.
2. Vin­cu­la­ção: Um PV é vinculado a uma so­li­ci­ta­ção PVC quando um pod declara um requisito de ar­ma­ze­na­mento que cor­res­ponde às es­pe­ci­fi­ca­ções do PV. Essa etapa assegura que o PV atenda aos re­qui­si­tos de um pod es­pe­cí­fico.
3. Uti­li­za­ção pelo pod: Após a conclusão do processo de vin­cu­la­ção, o PV pode ser utilizado por um pod capaz de ler ou gravar o volume montado, de­pen­dendo 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 reu­ti­li­zado por outro pod. O PV é mantido até que seja excluído ma­nu­al­mente pelo usuário ou por uma classe de ar­ma­ze­na­mento dinâmica.
5. Liberação: O usuário pode liberar um PV ex­pli­ci­ta­mente ao des­co­nectá-lo de uma PVC. O PV poderá ser vinculado novamente, pos­si­vel­mente a outra PVC ou pod.
6. Exclusão: Por fim, o usuário pode excluir um PV se ele não for mais ne­ces­sá­rio. Isso pode ser feito ma­nu­al­mente ou au­to­ma­ti­ca­mente, se a re­pli­ca­ção do PV for definida pela classe de ar­ma­ze­na­mento.

Como criar um Ku­ber­ne­tes Per­sis­tent Volume

A criação de um Ku­ber­ne­tes Per­sis­tent Volume é um processo dividido em vários estágios que exigem uma con­fi­gu­ra­ção cuidadosa.

Passo 1: Con­fi­gu­rar Volume Per­sis­tente

O primeiro passo é abrir um editor de texto e criar um arquivo YAML contendo a con­fi­gu­ra­ção do Ku­ber­ne­tes Per­sis­tent Volume. Nomeie o arquivo como pv.yaml. Abaixo, apre­sen­ta­mos um exemplo simples da con­fi­gu­ra­çã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"

• apiVersion: Es­pe­ci­fica a versão da API do Ku­ber­ne­tes. Nesse caso, V1.
• kind: O tipo de objeto do Ku­ber­ne­tes. Nesse caso, “Per­sis­tent­Vo­lume”.
• metadata: Contém os metadados do Volume Per­sis­tente. Por exemplo, o nome do volume. spec: Define a es­pe­ci­fi­ca­ção do volume.
• capacity: Es­pe­ci­fica a ca­pa­ci­dade de ar­ma­ze­na­mento. Nesse caso, 1 GB.
• volumeMode: Es­pe­ci­fica 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: Es­pe­ci­fica como o volume deve ser tratado quando não for mais ne­ces­sá­rio. Retain indica que o volume deve ser excluído ma­nu­al­mente.
• storageClassName: Atribui uma classe de ar­ma­ze­na­mento ao Volume Per­sis­tente.
• hostPath: Define o caminho no sistema de arquivos do host que é usado como ar­ma­ze­na­mento para o Volume Per­sis­tente.

Passo 2: Aplicar a con­fi­gu­ra­ção

Depois de preencher o arquivo de con­fi­gu­ra­ção do PV, você pode ativá-lo com o Kubelet:

kubectl apply -f pv.yaml

Esse comando envia o arquivo de con­fi­gu­ra­ção para o cluster do Ku­ber­ne­tes, que cria os recursos contidos nele.

Passo 3: Verificar a con­fi­gu­ra­ção

Para verificar se o Ku­ber­ne­tes Per­sis­tent Volume foi criado cor­re­ta­mente, use o comando a seguir:

kubectl get pv

Esse comando listará todos os volumes per­sis­ten­tes no cluster.

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

Passo 4: Criar so­li­ci­ta­ção Per­sis­tent Volume Claim (PVC)

Preencha o arquivo YAML com as con­fi­gu­ra­ções da so­li­ci­ta­ção PVC:

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

Aplique o arquivo de con­fi­gu­ra­ção da PVC no cluster do Ku­ber­ne­tes:

kubectl apply -f pvc.yaml

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

kubectl get pvc

O resultado será similar a este:

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

Em seguida, crie o manifesto YAML pvc-dynamic.yaml para de­mons­trar o pro­vi­si­o­na­mento dinâmico de uma so­li­ci­ta­ção PVC no Ku­ber­ne­tes. O manifesto cria e rei­vin­dica au­to­ma­ti­ca­mente um novo Ku­ber­ne­tes Per­sis­tent Volume com o tamanho de 1 GB, que é suportado pela classe de ar­ma­ze­na­mento standard.

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

Após a definição das con­fi­gu­ra­ções, ative o manifesto:

kubectl apply -f pvc-dynamic.yaml

Passo 5: Vincular PVCs a pods

Para conectar a PVC ao pod, defina as con­fi­gu­ra­ções do pod que usará o ar­ma­ze­na­mento per­sis­tente.

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

Para criar o pod, aplique sua con­fi­gu­ra­ção no cluster do Ku­ber­ne­tes:

kubectl apply -f pod.yaml

Se você está começando a aprender sobre Ku­ber­ne­tes, encontre tudo o que precisa saber sobre o processo de ins­ta­la­ção e con­fi­gu­ra­ção de um cluster no tutorial Ku­ber­ne­tes no nosso Digital Guide.