greencap-k8s
GreenCap es una plataforma web ligera para monitorear y gestionar clusters Kubernetes, alternativa más amigable que OpenShift o Rancher para equipos individuales y pequeñas a medianas empresas.
Ficha actualizada 22 sept 2026, 22:24 · upstream 22 sept 2026, 22:00 · release v0.7.9
Qué es greencap-k8s
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
GreenCap es una plataforma web para operar Kubernetes a través de interfaz gráfica en lugar de terminal. Un comando único (./setup/setup.sh) provisiona un cluster local con GreenCap listo para usar, además de permitir conectar clusters existentes como minikube, kind o gestionados. Está diseñado para individuos y equipos pequeños/medianos que estudian, desarrollan y prueban contra Kubernetes, sin el peso operativo de plataformas empresariales.
La plataforma opera sobre dos capas: una capa inicial con ./setup/setup.sh que provisiona un cluster local mediante minikube, y una capa de gestión que actúa como layer sobre clusters existentes. No es un tool de ciclo de vida del cluster, sino que opera lo que reside dentro de ellos.
Es multiusuario y RBAC-native: cada usuario no-admin tiene un ServiceAccount correspondiente, con acceso exactamente igual al otorgado por Kubernetes a su rol.
- Desarrolladores individuales o equipos pequeños que necesitan probar y desarrollar contra Kubernetes sin configurar infraestructura compleja
- Equipes de desarrollo que requieren una interfaz gráfica para gestionar despliegues, escalabilidad y observabilidad en Kubernetes
- Entidades que necesitan monitoreo y gestión de recursos (pods, deployments, services) sin usar herramientas como OpenShift o Rancher
- Equipos que buscan un punto único de control para operaciones diarias de clusters Kubernetes
- Pruebas de integración donde se necesita un entorno local con Kubernetes configurado rápidamente
- Provisiona un cluster real (minikube) en un solo comando, eliminando la necesidad de configurar infraestructura desde cero
- Interfaz web completa que opera todos los recursos del cluster: workloads, networking, storage, autoscaling y más
- No requiere hand-writing YAML: ofrece wizards guiados para desplegar desde imágenes, Docker Compose o Helm charts
- Soporta múltiples fuentes de acceso (kubeconfig, API server URL + token) con monitoreo en tiempo real del estado de conexión
- Permite ver dependencias inferidas entre servicios mediante un grafo interactivo de topología
- Soporta Kubernetes Operators a través de OLM y tiene un repositorio propio de imágenes
- Depende de Docker para provisionar el cluster local, lo que puede ser un obstáculo en entornos sin Docker o con Docker limitado
- No incluye herramientas nativas de observabilidad como Prometheus, Grafana ni logging centralizado (solo muestra logs del pod)
- La interfaz web no es escalable a nivel de infraestructura: para clusters grandes se requiere una capa de orquestación externa
- El despliegue desde Dockerfile requiere construir el image in-cluster con Kaniko, lo que puede ser lento en entornos pequeños
- No incluye herramientas de CI/CD ni gestión de dependencias entre servicios (solo permite desplegar recursos individuales)
- La configuración de RBAC debe ser gestionada por los administradores del cluster, no es parte de la plataforma
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.
Requisito mínimo: Docker instalado. El wizard detecta automáticamente kubectl, minikube y helm, ofreciendo instalación automática si faltan.,Para producción: se recomienda usar un cluster real (minikube, kind o managed) en lugar de la instancia local provisionada por el wizard para evitar problemas de persistencia.,En entornos Linux/macOS, el comando ./setup/setup.sh instala Docker y kubectl automáticamente. En Windows, se recomienda instalar Docker Desktop primero.,Para producción: se debe configurar un cluster real con RBAC definido (ClusterRole, ClusterRoleBinding) antes de usar GreenCap como capa de gestión.,En entornos multi-tenant o multi-cluster, se recomienda crear un namespace dedicado para la plataforma y gestionar los ServiceAccounts correspondientes.,Se puede ejecutar el build local en desarrollo con BUILD_LOCAL=true, pero en producción siempre se debe usar una imagen publica
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.