DevOps · 21/06/2026

CSI como Desacoplamento de Armazenamento Expõe o Trade-off Real: Abstração de Interface vs Multiplicação de Surface de Falha em Distributed Systems

Container Storage Interface (CSI) abstraiu a integração de storage em Kubernetes, mas moveu a complexidade de gerenciamento para múltiplos sidecars e drivers de terceiros. A tese: centralizar a abstração descentralizou a responsabilidade operacional, aumentando pontos críticos de falha em arquiteturas que rodam workloads com estado.

O que está acontecendo

Quando Kubernetes nasceu, era exclusivamente stateless. A ideia era simples: containers efêmeros, nenhuma persistência. Mas a realidade operacional forçou o projeto a abraçar workloads com estado. O SIG Storage foi criado justamente para resolver esse problema fundamental: como conectar containers a sistemas de armazenamento de forma padronizada?

Inicialmente, isso foi feito através de plugins in-tree — código acoplado ao kernel do Kubernetes que gerenciava volumes. Cada novo provider de storage significava um PR no projeto core, testes integrados, release cycle acoplada ao próprio Kubernetes. Era monolítico, mas havia uma única fonte de verdade.

A resposta foi o Container Storage Interface (CSI): um padrão que permitiu que terceiros desenvolvessem e mantivessem drivers de storage fora do código core do Kubernetes. Parecia a solução perfeita. E em teoria, era. Na prática, CSI transferiu o gerenciamento de um monólito acoplado para um ecossistema distribuído de sidecars que rodam dentro do cluster e falam com drivers externos.

Hoje, um cluster Kubernetes com storage stateful precisa gerenciar: csi-provisioner, csi-attacher, csi-resizer, csi-snapshotter e múltiplos drivers de storage. Cada um é um processo independente, cada um tem seu próprio ciclo de vida, cada um é um ponto de falha crítico para dados em repouso.

Insights e Riscos

• Multiplicação de Sidecars = Multiplicação de Superfícies de Falha: Um cluster com 3 providers de storage agora executa ~9-12 sidecars CSI críticos. Cada um pode falhar independentemente, cada um traz latência de health checks, cada um consome recursos. A "simplicidade" de CSI é uma ilusão: você não eliminou a complexidade, apenas a distribuiu.

• Isolamento de Falha vs Cascata Operacional: Quando um csi-provisioner falha em um vendor específico, esse vendor fica indisponível. Mas em um cluster multi-tenant ou multi-storage, isso pode criar isolamento falho: requests pendentes acumulam, timeouts crescem, o kubelet fica pendurado em operações de volume. Não é falha isolada; é contaminação lenta do plane de controle.

• Versionamento Descentralizado = Incompatibilidade Silenciosa: Cada driver CSI tem seu próprio release cycle. Um upgrade do Kubernetes 1.28 para 1.29 não garante compatibilidade automática com drivers de terceiros. O SIG Storage define a interface, mas não obriga conformidade. Você descobre problemas em produção, não em labs.

• Data Protection Working Group Reconhece o Buraco: Features como Volume Group Snapshot e Changed Block Tracking (CBT) são essenciais para backup e disaster recovery. Mas essas são adições ao CSI, não refinamentos. Cada feature nova é um sidecar novo, ou extensão de sidecars existentes. A dívida técnica cresce.

• AI Workloads Amplificam o Problema: O documento menciona que AI workloads se tornaram a norma. Modelos grandes rodam em volumes distribuídos, requerem I/O intensivo, snapshot rápido, replicação eficiente. CSI resolve o problema de heterogeneidade (múltiplos providers), mas não resolve o problema de operabilidade em escala: monitorar a saúde de 12 sidecars para garantir que um modelo de 100GB não perca coerência de dados é uma tarefa operacional adulta.

O que muda na prática

Engenheiro de Segurança: CSI sidecars têm identidades de serviço Kubernetes (RBAC). Cada sidecarsidecar precisa permissões específicas no apiserver, no kubelet, no storage system backend. Multiplicar sidecars = multiplicar superfícies de RBAC. Um erro de configuração em um sidecar CSI pode dar acesso a volumes que não deveria ter. Auditoria de permissões CSI é não-trivial e raramente é feita de forma contínua.

Arquiteto: A decisão "usamos CSI" parece arquitetônica, mas é operacional. CSI define como drivers falam com Kubernetes, não como você vai gerenciar a saúde desses drivers em produção. Um arquiteto precisa decidir: qual é meu SLO para provisioning de volume? Qual é meu timeout de attach? Como eu monitorar degradação silenciosa de um sidecar que não falha, mas fica lento? CSI força essas decisões para baixo na stack operacional.

DevOps/MLOps: Você agora tem um job: manter múltiplos sidecars CSI vivos e responsivos. Rollout de atualizações de driver não é automático; é um ritual. Rollback de driver pode significar revert de todas as operações de volume em flight. Em um cluster rodar MLOps, onde você tem pipelines de treinamento dependendo de volumes montados, um sidecar lento é um pipeline lento. A observabilidade de CSI é rudimentar: logs distribuídos entre kubelet, sidecars e drivers externos. Correlacionar um volume quebrado é buscar uma agulha em um palheiro.

Conclusão direta

CSI foi a resposta correta para o problema errado. O problema real não era "como fazer drivers de storage se acoplem ao Kubernetes", era "como operar storage stateful em distributed systems de forma confiável e observável". CSI resolveu o primeiro, ignorou o segundo. Hoje, clusters produção com storage complexo rodam um ecossistema de sidecars que ninguém monitorou completamente, ninguém testou end-to-end com falhas de rede reais, e ninguém sabe qual é o SLO de uma operação de snapshot distribuída.

A ironia: SIG Storage centraliza a padronização e descentraliza a operação. É um trade-off arquitetural clássico, mas ninguém o nomeia explicitamente quando você adota CSI.

Pergunta provocativa: Se CSI multiplicou seus pontos de falha críticos de storage para resolver heterogeneidade, qual é o custo operacional real dessa abstração em clusters que rodam modelo de IA de 500GB dependendo de snapshot atômico cross-múltiplos-volumes?

Fontes

[Fonte: Kubernetes Blog] Spotlight on SIG Storage: In our ongoing SIG Spotlight series — Storage in Kubernetes headed as AI workloads become the norm, Container Storage Interface (CSI), Volume Group Snapshot, Changed Block Tracking (CBT)