DevOps · 22/06/2026

SIG Storage Expõe o Trade-off Real: Abstração de Interface Universal vs Fragmentação de Responsabilidade Operacional em Kubernetes Stateful

A evolução de SIG Storage—de plugins in-tree para CSI e agora COSI—revela a tensão estrutural entre unificar interfaces de armazenamento e multiplicar os pontos de falha distribuídos que DevOps precisa operar em produção.

O que está acontecendo

O Kubernetes SIG Storage enfrenta um dilema técnico fundamental que se materializa conforme a plataforma absorve cargas de trabalho stateful. Durante anos, Kubernetes foi projetado explicitamente para workloads sem estado. Com a adoção de aplicações que requerem persistência—bancos de dados, caches distribuídos, sistemas de fila—a abstração de armazenamento se tornou crítica.

O modelo evoluiu em três fases: (1) plugins in-tree, onde o core do Kubernetes continha código de drivers diretos para vários backends; (2) Container Storage Interface (CSI), que externaliza drivers para repositórios de terceiros; (3) Container Object Storage Interface (COSI), estendendo o padrão para armazenamento de objetos. Cada transição resolveu um problema e criou outro.

A questão central: quanto mais Kubernetes se afasta do monolito (in-tree), mais responsabilidades operacionais se distribuem entre agentes independentes (sidecars, drivers CSI, controladores COSI). Xing Yang, co-chair de SIG Storage, menciona explicitamente que múltiplos sidecars CSI—como csi-provisioner, csi-attacher, csi-resizer e csi-snapshotter—precisam ser lançados sincronizadamente a cada release do Kubernetes. Isso não é elegância arquitetural; é fragmentação de responsabilidade com sincronia forçada.

Insights e Riscos

• Superfície de Falha Multiplicada: Cada sidecar CSI é um ponto potencial de falha independente. Um problema no csi-snapshotter não bloqueia csi-provisioner, mas ambos precisam estar versionados corretamente em relação ao Kubernetes. Falhas de compatibilidade cruzada emergem em produção, não em testes.

• Sincronização Artificial de Releases: SIG Storage deve coordenar sidecars com a cadência do Kubernetes (4 releases/ano). Isso não reflete a realidade operacional: um driver de armazenamento não evolui necessariamente na mesma velocidade do orquestrador.

• Fragmentação de Expertise: Antes, um engenheiro Kubernetes aprendia uma interface de armazenamento in-tree. Agora, ele precisa entender CSI (que é a abstração "correta"), conhecer quais sidecars sua infraestrutura instancia, compreender a configuração específica do driver de seu vendor, e resolver conflitos de compatibilidade quando surgem. O overhead cognitivo é real.

• Data Protection Gap Preenchido Incrementalmente: Features como Volume Group Snapshot e Changed Block Tracking (CBT) vieram do Data Protection Working Group porque havia lacunas na abstração original. Cada gap preenchido é evidência de que a interface não foi completa desde o início—e cada patch requer ciclos de integração.

• Extensão para COSI: A adição de armazenamento de objetos (COSI) replica o mesmo padrão de desacoplamento. Mais uma interface, mais drivers, mais sidecars, mais pontos de falha. O argumento é que "storage vendors podem manter seus próprios drivers", mas quem integra, testa e opera essa rede de componentes?

O que muda na prática

Para Engenheiros de Confiabilidade/DevOps: O custo operacional aumenta não-linearmente com a diversidade de backends de armazenamento. Você não apenas provisiona volumes; você mantém a compatibilidade entre múltiplos sidecars, drivers CSI, versões do Kubernetes, e backends (NFS, S3, vSphere, etc.). Falhas silenciosas ocorrem quando um sidecar fica desatualizado. Alertas precisam cobrir cada componente independentemente. Rollbacks de Kubernetes requerem compatibilidade backward dos drivers—que podem não existir.

Para Arquitetos: CSI resolve o problema de acoplamento monolítico, mas transfere a complexidade para o plano de controle distribuído. Você precisa decidir: centralizar drivers em um registry corporativo e gerenciar versões, ou deixar cada equipe escolher drivers? A primeira opção reintroduz serialização; a segunda fragmente a operabilidade.

Para Especialistas em Segurança: Cada driver CSI expande a superfície de ataque. Um driver malicioso ou comprometido pode extrair dados. SIG Storage define interfaces, mas não impõe garantias de segurança homogêneas. Você depende da maturidade de segurança de cada vendor de storage.

Conclusão direta

SIG Storage não está "resolvendo" o problema de armazenamento em Kubernetes; está redistribuindo-o. A migração de in-tree para CSI para COSI segue a lógica correta de desacoplamento arquitetural, mas o custo operacional recai sobre times que precisam integrar, testar e monitorar uma rede crescente de componentes independentes. O trade-off é real: você ganha flexibilidade (qualquer vendor pode escrever um driver), mas perde previsibilidade (falhas surgem em pontos diferentes, compatibilidade é uma responsabilidade distribuída, expertise fragmenta-se).

A pergunta provocativa: em um cluster Kubernetes com storage stateful em produção, quantos sidecars e drivers CSI você está operando sem visibilidade de falhas cruzadas entre eles?

Fontes

[Fonte: Kubernetes Blog] Spotlight on SIG Storage — entrevista com Xing Yang, co-chair de SIG Storage e Software Engineer da VMware by Broadcom, discutindo histórico, features recentes e roadmap para suporte a workloads de IA.