Um Guia Simples para Implementar Armazenamento Persistente no Kubernetes

O armazenamento persistente no Kubernetes resolve um problema simples: seu contêiner pode desaparecer, mas seus arquivos de banco de dados, uploads ou dados de fila não podem. Pods sem estado podem ser substituídos a qualquer momento. Aplicações com estado precisam de armazenamento que sobreviva a reinicializações de Pods, reagendamentos e manutenção de nós.

Este guia explica PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), modos de acesso e StorageClasses com YAML prático que você pode adaptar para uma carga de trabalho real.

Entendendo PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs)

Antes de montar armazenamento em um Pod, saiba qual objeto é responsável por qual tarefa:

• PersistentVolume (PV): Um PV é uma peça de armazenamento no cluster que foi provisionada por um administrador ou provisionada dinamicamente usando StorageClasses. PVs são recursos do cluster, muito parecidos com Nós. Eles têm um ciclo de vida independente de qualquer Pod individual que use o PV. PVs abstraem os detalhes da implementação de armazenamento subjacente (por exemplo, NFS, iSCSI, armazenamento em bloco do provedor de nuvem).
• PersistentVolumeClaim (PVC): Um PVC é uma solicitação de armazenamento por um usuário. Ele consome recursos de armazenamento que estão disponíveis no cluster como PVs. PVCs são semelhantes a Pods, pois consomem recursos de computação e são limitados a um namespace. Um PVC especifica a capacidade de armazenamento desejada, modos de acesso e, opcionalmente, uma StorageClass.

Essa separação permite que as equipes de plataforma gerenciem os detalhes de armazenamento enquanto as equipes de aplicação solicitam a capacidade e o padrão de acesso de que precisam.

Conceitos Chave: Modos de Acesso e StorageClasses

Duas configurações controlam a maior parte do comportamento do PVC: como o volume pode ser montado e qual backend de armazenamento deve criá-lo.

Modos de Acesso

Os modos de acesso definem como um volume pode ser montado em um Pod. Os modos de acesso disponíveis são:

• ReadWriteOnce (RWO): O volume pode ser montado como leitura-escrita por um único nó.
• ReadOnlyMany (ROX): O volume pode ser montado como somente leitura por muitos nós.
• ReadWriteMany (RWX): O volume pode ser montado como leitura-escrita por muitos nós.
• ReadWriteOncePod (RWOP): O volume pode ser montado como leitura-escrita por um único Pod. Isso é útil quando você precisa de um comportamento de escritor único mais rigoroso e seu driver CSI suporta isso.

É importante notar que o suporte real para esses modos depende do provedor de armazenamento subjacente.

StorageClasses

Uma StorageClass fornece uma maneira para os administradores descreverem as "classes" de armazenamento que oferecem. Diferentes classes podem mapear para níveis de qualidade de serviço, políticas de backup ou políticas arbitrárias determinadas pelos administradores do cluster. Uma StorageClass tem um provisionador que provisiona armazenamento e um conjunto de parâmetros para o provisionador. Quando um PVC é criado sem um PV específico e solicita uma StorageClass, o Kubernetes provisionará dinamicamente um PV usando a StorageClass especificada.

Implementando Armazenamento Persistente Passo a Passo

Vamos percorrer um cenário comum: solicitar e usar armazenamento persistente para um Pod.

Passo 1: Definir um PersistentVolumeClaim (PVC)

Primeiro, você precisa criar um PVC que especifique seus requisitos de armazenamento. Este PVC atuará como a solicitação de armazenamento para sua aplicação.

Exemplo pvc.yaml:

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

Neste exemplo:

• name: my-pvc: Este é o nome do nosso PVC.
• accessModes: - ReadWriteOnce: Estamos solicitando armazenamento que pode ser montado como leitura-escrita por um único nó.
• resources.requests.storage: 1Gi: Estamos solicitando 1 Gigabyte de armazenamento.

Aplicando o PVC:

Salve o conteúdo acima em um arquivo chamado pvc.yaml e aplique-o ao seu cluster:

kubectl apply -f pvc.yaml

Após aplicar, você pode verificar o status do PVC:

kubectl get pvc my-pvc

Você deve ver uma saída indicando que o PVC está Bound se um PV adequado estiver disponível ou tiver sido provisionado dinamicamente.

Passo 2: Criar um Pod que Use o PVC

Agora, vamos criar um Pod que utilizará o armazenamento solicitado pelo nosso PVC. Montaremos o volume fornecido pelo PVC em um diretório específico dentro do nosso contêiner.

Exemplo pod-with-pv.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

Neste exemplo:

• volumes: Definimos um volume chamado my-persistent-storage.
• persistentVolumeClaim.claimName: my-pvc: Isso vincula nosso volume ao PVC que criamos anteriormente.
• volumeMounts: Dentro da definição do contêiner, especificamos onde este volume deve ser montado (mountPath: /usr/share/nginx/html).

Aplicando o Pod:

Salve o conteúdo acima em um arquivo chamado pod-with-pv.yaml e aplique-o:

kubectl apply -f pod-with-pv.yaml

Agora, seu contêiner nginx terá acesso ao armazenamento persistente definido por my-pvc no caminho /usr/share/nginx/html. Quaisquer dados gravados neste caminho dentro do contêiner serão persistidos mesmo se o Pod for excluído e recriado, desde que o PVC e seu PV subjacente permaneçam.

Provisionamento Dinâmico com StorageClasses

Criar PVs manualmente pode ser trabalhoso. O Kubernetes oferece provisionamento dinâmico, onde os PVs são criados automaticamente quando um PVC solicita armazenamento que não pode ser atendido pelos PVs existentes. Isso é alcançado por meio de StorageClasses.

A maioria dos provedores de nuvem (AWS, GCP, Azure) oferece StorageClasses pré-configuradas. Você pode inspecioná-las com:

kubectl get storageclass

Para usar o provisionamento dinâmico, basta adicionar um campo storageClassName à sua definição de PVC:

Exemplo pvc-dynamic.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # Substitua 'standard' por um nome de StorageClass real
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Quando você aplicar este PVC, o Kubernetes procurará uma StorageClass chamada standard (ou qualquer nome que você especificar) e instruirá seu provisionador a criar um novo PV de 5Gi e vinculá-lo a este PVC.

Dicas e Melhores Práticas

• Escolha o Modo de Acesso Correto: Considere cuidadosamente o modo de acesso exigido pela sua aplicação. ReadWriteOnce é comum para bancos de dados de réplica única, enquanto ReadWriteMany é necessário para sistemas de arquivos compartilhados usados por vários Pods.
• Entenda o Desempenho do Armazenamento: Diferentes provedores de armazenamento e StorageClasses oferecem características de desempenho variadas (IOPS, throughput). Escolha uma StorageClass que atenda às necessidades de desempenho da sua aplicação.
• Estratégia de Backup: Armazenamento persistente não significa automaticamente backup. Implemente uma estratégia de backup robusta para seus volumes persistentes, especialmente para dados críticos.
• Política de Reclamação de PV: PVs têm uma persistentVolumeReclaimPolicy, comumente Delete ou Retain. Volumes provisionados dinamicamente geralmente usam a política de reclamação definida por sua StorageClass. A antiga política Recycle está obsoleta e não deve ser usada para novas configurações.
• Considerações sobre Namespace: PVCs têm escopo de namespace. Certifique-se de que seu Pod e PVC estejam no mesmo namespace para que a vinculação ocorra.

Conclusão

O armazenamento persistente no Kubernetes começa com um PVC, uma montagem de Pod e uma StorageClass que corresponda à sua carga de trabalho. Para um banco de dados de réplica única, comece com uma solicitação ReadWriteOnce, verifique se ela atinge o estado Bound, monte-a no contêiner e torne os backups parte do design desde o primeiro dia.