// the find
cloud-ark/kubeplus
Kubernetes Operator for delivering SaaS-style, namespace-isolated application instances on Kubernetes
KubePlus wraps Helm charts in Kubernetes CRDs to provide per-tenant namespace isolation, RBAC delegation, resource quotas, and lifecycle management for multi-tenant application deployments. It targets platform teams and SaaS vendors who need to run dedicated application instances per customer without giving tenants cluster-admin access. Think of it as an automation layer that turns 'helm install' into a proper managed service primitive.
- The core abstraction is sound: converting a Helm chart's values.yaml into a CRD spec is a legitimate pattern that avoids building bespoke operators for every application, and the resource tracking across namespaces is genuinely useful for operators.
- Scoped kubeconfig generation for providers and consumers is a practical security feature - letting you delegate 'create an instance of this app' without granting kubectl access to the whole cluster is exactly what multi-tenant platforms need.
- Per-instance CPU/memory/network metrics exposed in Prometheus-compatible format is a real operational need that most DIY Helm multi-tenancy setups skip entirely.
- Solid set of worked examples (WordPress, MySQL, Supabase, Odoo) with actual Helm charts checked in, making it possible to actually evaluate the tool without writing everything from scratch.
- Installation is a mess - it requires a Python script to generate kubeconfig, wget-ing random files, manually setting PATH, and the automated install.sh is described as 'simplified' but that's doing a lot of work. For a tool aimed at platform teams, there's no operator-sdk/OLM-first install path documented prominently.
- The compiled HTML docs and Python venv artifacts are committed directly to the repo (docs/html/html/venv/...), which is a red flag for repo hygiene and suggests CI/CD practices that may affect code quality confidence.
- Network policy isolation is mentioned but the implementation depends on whatever CNI is running - there's no clear documentation of tested CNI compatibility or what happens when network policies are not enforced by the cluster's CNI plugin, which is a silent security hole.
- The license enforcement feature (limiting instance counts, expiry dates) is built into the operator itself rather than being delegated to an external policy engine, which means it's trivially bypassable by anyone with direct CRD access and creates a false sense of commercial enforcement.