pillar-csi
Driver CSI en Go para clústeres Kubernetes autoalojados que exporta ZFS zvols y LVM LV locales sobre NVMe-oF/TCP usando configfs directo, sin overhead de sistema de archivos distribuido.
Ficha actualizada 24 sept 2026, 14:39 · upstream 24 sept 2026, 14:38 · release v0.1.0
Qué es pillar-csi
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
pillar-csi es un driver CSI basado en Go diseñado para clústeres Kubernetes bare-metal o autoalojados. Exporta almacenamiento local (ZFS zvols o LVM logical volumes) desde un nodo dedicado al resto del clúster mediante NVMe-oF/TCP, utilizando escritura directa a configfs del kernel sin dependencias externas como SSH o Python.
El despliegue se gestiona declarativamente mediante CRDs de cluster scope: PillarAgent localiza el agente de almacenamiento, PillarStore define pools (ZFS/LVM), PillarProtocol configura protocolos (NVMe-oF/TCP, iSCSI, NFS) y PillarStorageClass genera StorageClasses automáticamente. El controlador reconcilia estos recursos mientras los agentes DaemonSet gestionan la interfaz de datos.
No es un sistema de archivos distribuido: replica ni pooliza almacenamiento entre nodos, sino que exporta el almacenamiento existente tal cual. Soporta CSI operations completas (CreateVolume, DeleteVolume, ExpandVolume, etc.) y modos de acceso ReadWriteOnce/ReadOnlyMany con Filesystem o Block.
- Almacenamiento persistente local en clústeres Kubernetes bare-metal sin replicación
- Exportar ZFS zvols existentes a múltiples pods mediante NVMe-oF/TCP
- Alternativa ligera a drivers CSI comerciales para homelab o infraestructura propia
- Provisionamiento de volúmenes con StorageClass declarativo vía CRDs
- Escrito en Go como binario estático único sin dependencias externas en el nodo
- Configuración declarativa completa mediante CRDs (PillarAgent, PillarStore, etc.)
- Escritura directa a configfs del kernel sin SSH ni Python daemons
- Soporte nativo para NVMe-oF/TCP sobre Ethernet estándar sin RDMA
- mTLS opt-in con cert-manager o secrets propios para cifrado gRPC
- No replica ni distribuye almacenamiento entre nodos (no es un sistema de archivos distribuido)
- Solo NVMe-oF/TCP en fase 1; iSCSI y NFS están diseñados pero no implementados
- Requiere módulos del kernel nvmet/nvmet_tcp en nodos de almacenamiento
- No soporta ZFS datasets ni Btrfs subvolumes en la versión actual
- Kubernetes ≥ 1.24 obligatorio para probes nativos gRPC
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Despliegue vía Helm en namespace pillar-csi con --create-namespace. Activar mTLS opcional (--set mtls.enabled=true). Nodos de almacenamiento requieren módulos nvmet/nvmet_tcp; workers necesitan nvme_tcp/nvme_fabrics. Kernel Linux ≥ 5.0 suficiente para NVMe-oF/TCP. Aplicar CRDs (PillarAgent, PillarStore, PillarProtocol) antes del StorageClass.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.