09 Mai 2026 5 min de leitura

Kubernetes v1.36: Volume Group Snapshots em GA – Adeus à Inconsistência em Workloads Estadoful

Volumes desconectados, snapshots fora de sincronia e noites perdidas validando backups manuais — com o v1.36, essa dor finalmente tem remédio nativo. O recurso de Volume Group Snapshots promete acabar com a inconsistência temporal em workloads que dependem de múltiplos PVCs.

O problema clássico de quem roda estadoful no Kubernetes

Todo engenheiro que já administrou um banco de dados distribuído ou um cluster de mensageria conhece o roteiro: dois PersistentVolumeClaims (PVCs) — um para dados, outro para logs ou índices — e uma sequência de snapshots que, por milissegundos de diferença, gera inconsistência.

O snapshot de dados captura um estado ligeiramente anterior ao snapshot de logs. Na restauração, a aplicação simplesmente se recusa a subir, ou pior, sobe com dados corrompidos.

A solução tradicional envolvia quiescência manual: pausar escritas, drenar buffers, disparar snapshots em fila e torcer para o intervalo ser curto o suficiente. Frágil e operação intensiva.

Volume Group Snapshots chegam para eliminar esse calvário: todos os volumes de um grupo são capturados no mesmo ponto no tempo, de forma crash‑consistent.

A solução GA: como funciona a nova API

Promovida a General Availability (GA) no v1.36, a API groupsnapshot.storage.k8s.io/v1 introduz três CRDs que formam a espinha dorsal da feature:

VolumeGroupSnapshot – objeto declarado pelo usuário para solicitar o snapshot do grupo.
VolumeGroupSnapshotContent – recurso gerenciado pelo controlador, representando o conteúdo do snapshot.
VolumeGroupSnapshotClass – define a classe de armazenamento e os parâmetros do driver CSI.

Agrupamento inteligente por labels

O mecanismo central é o uso de label selectors. Você não precisa listar manualmente cada PVC. Basta que os volumes compartilhem labels que correspondam ao seletor definido no VolumeGroupSnapshot.

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
  name: postgres-diario
spec:
  source:
    selector:
      matchLabels:
        app: postgres
        grupo: producao
  volumeGroupSnapshotClassName: grupo-ebs-gp3

O controlador localiza todos os PVCs com os labels app: postgres e grupo: producao, e solicita ao driver CSI que crie um snapshot crash‑consistente de todos eles simultaneamente.

Restauração granular

Após o snapshot, a restauração gera PVCs individuais a partir de cada VolumeSnapshot filho. Você pode referenciar diretamente o snapshot filho no dataSource do PVC restaurado.

A correção de bugs como o restoreSize agora preciso e a maturidade da API tornam o processo confiável para ambientes de produção.

Requisitos técnicos: o pulo do gato do CSI

Volume Group Snapshots funcionam exclusivamente com CSI drivers que implementem o Group Controller — especificamente os RPCs CreateVolumeGroupSnapshot, DeleteVolumeGroupSnapshot e GetVolumeGroupSnapshot.

Drivers in‑tree (legados) não são compatíveis.
Fornecedores como AWS EBS CSI, Azure Disk CSI, GCE PD CSI precisam estender seus drivers para suportar o protocolo de grupo.
Em clouds gerenciadas (EKS, AKS, GKE), a expectativa é que a feature seja habilitada rapidamente por ser um diferencial competitivo.

“A API é limpa, o fluxo é declarativo. A complexidade real está fora do YAML: depende do ecossistema de storage.”

Implicações de mercado: o impulso definitivo para workloads estadoful

1. Aceleração da adoção de stateful workloads

A principal barreira para rodar bancos de dados no Kubernetes era a complexidade de backup/DR. Agora, com uma API nativa, consistente e que elimina a necessidade de quiescência manual, times de infraestrutura podem tratar snapshots de grupo como um recurso padrão, sem scripts ad hoc.

2. Pressão competitiva sobre fornecedores de CSI

Fabricantes de storage que ainda não implementaram os RPCs de grupo correm o risco de perder relevância. A feature se torna requisito básico para ambientes estadoful modernos.

3. Integração em ferramentas de backup e DR

Ferramentas como Velero, Kasten K10 e Trilio podem estender seus controladores para consumir VolumeGroupSnapshot, oferecendo snapshots consistentes sem hooks de pré/pós backup. Isso simplifica drasticamente os playbooks de disaster recovery.

4. Plataformas de cloud gerenciadas

EKS, AKS, GKE devem disponibilizar a feature como parte de suas ofertas padrão, agregando valor e facilitando a migração de workloads legacy para Kubernetes.

Limitações e riscos que você precisa conhecer

Nem tudo são flores. A feature tem contornos que exigem atenção redobrada.

Limitação	Impacto	Mitigação
Crash‑consistent, não application‑consistent	Bancos com consistência transacional (MySQL, Oracle) podem exigir quiescência interna	Usar hooks de pré‑snapshot ou ferramentas como `pg_start_backup()`
Dependência de CSI com Group Controller	Drivers in‑tree e alguns CSI de terceiros ficam de fora	Verificar compatibilidade do storage provisioner antes do planejamento
Governança de labels	Se múltiplas apps usarem labels sem escopo, snapshots podem agrupar volumes de apps diferentes	Usar labels exclusivos por aplicação ou namespace
Crescimento de objetos CRD	Cada grupo gera múltiplos VolumeSnapshots internos; centenas de grupos podem impactar o API server	Política de limpeza com TTL e monitoramento de carga

A consistência é crash‑consistent – os dados no disco estão em um estado válido como se o sistema tivesse caído repentinamente. Para workloads transacionais, ainda é necessário um checkpoint no nível da aplicação.

Exemplo prático: backup de um cluster PostgreSQL

Vamos ver a nova API em ação com um fluxo completo de backup de um PostgreSQL com dois PVCs.

Passo 1: Criar a VolumeGroupSnapshotClass

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshotClass
metadata:
  name: grupo-ebs-gp3
driver: ebs.csi.aws.com
deletionPolicy: Delete

Passo 2: PVCs com labels consistentes

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgdata
  labels:
    app: postgres
    grupo: producao
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgwal
  labels:
    app: postgres
    grupo: producao
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Passo 3: Criar o VolumeGroupSnapshot

kubectl apply -f - <

`Passo 4: Verificar os snapshots gerados`

kubectl get volumegroupsnapshot postgres-snapshot-diario -o yaml
kubectl get volumesnapshot -l groupsnapshot.storage.k8s.io/volume-group-name=postgres-snapshot-diario

`Passo 5: Restaurar um PVC individual`

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgdata-restaurado
spec:
  dataSource:
    name: postgres-snapshot-diario-0
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Esse fluxo pode ser facilmente integrado a um CronJob ou a um operador de backup como o Velero, que agora pode consumir a API nativa de grupo.

`O futuro dos snapshots consistentes em Kubernetes`

A chegada dos Volume Group Snapshots ao GA representa um atestado de maturidade para o gerenciamento de estado no Kubernetes.

Application‑consistent via hooks – Combinar a API de grupo com hooks de pré‑snapshot (ainda não padronizados) permitirá checkpoints sem pausar todas as escritas.
Integração com operadores de banco de dados – Operadores como Crunchy, Zalando, KubeDB e Cassandra Operator devem em breve oferecer suporte nativo a VolumeGroupSnapshot.
Restauração multi‑volume orquestrada – Ferramentas de DR evoluirão para restaurar um grupo inteiro de PVCs com um único comando, reconstruindo a topologia original e reduzindo o RTO.
Padronização multi‑cloud – A especificação do Group Controller no CSI Spec tende a se consolidar, permitindo portabilidade entre clouds.

“Volume Group Snapshots GA é uma daquelas features que, uma vez adotada, você se pergunta como viveu sem ela. Para workloads estadoful, o Kubernetes acaba de se tornar significativamente mais confiável e gerenciável.”

Kubernetes volume group snapshots GA visual

Quer saber como sua stack de storage se comporta com a nova API? Deixe nos comentários qual CSI driver você usa e se ele já suporta group snapshots. Vamos mapear juntos o ecossistema.