kubara is a tool that packages reusable Kubernetes platform architecture through catalogs, rather than individual application charts like Helm. A built-in catalog provides an opinionated baseline (delivery, networking, security, observability, storage, recovery), while an optional external catalog lets platform teams add organization-specific services without modifying the maintained baseline. config.yaml expresses cluster-specific intent, and kubara generates platform-components and platform-configs that Git and Argo CD reconcile. A worked example walks through building an external catalog with vCluster, vCluster Platform, Sveltos, and Kube Resource Orchestrator to run a load and scale test simulating 15,000 clusters and 75,000 applications at roughly a tenth of the cost of dedicated managed clusters (~€120,000 vs ~€1.2 million). The piece also covers collision handling between built-in and external service definitions, the --catalog-overwrite flag, and guidance on when to create an external catalog versus just editing config.yaml.
Table of contents
Learn how to build reusable Kubernetes platforms with kubara’s built-in and custom catalogs.What Is a kubara Catalog?The Built-In Catalog: A Maintained Starting PointThe External Catalog: Your Organization’s Platform ArchitectureHow Built-In and External Catalogs Work TogetherQuestions this post answers
What is the difference between a Helm chart and a kubara catalog?
A Helm chart packages a single application, while a kubara catalog packages an entire platform architecture, including service definitions, templates, Helm charts, optional Terraform modules, Kustomize files, and configuration models needed to generate a consistent Kubernetes platform across clusters. config.yaml then selects and configures which catalog services apply to a given cluster. Teams weighing platform tooling approaches can compare notes on architecture reuse patterns via daily.dev.
How much cheaper is it to simulate thousands of Kubernetes clusters with vCluster instead of provisioning real managed clusters?
Simulating 1,000 virtual clusters with five applications each using vCluster cost approximately €120,000 on STACKIT, versus an estimated €1.2 million for the equivalent setup using dedicated managed Kubernetes clusters, roughly a tenfold cost reduction for load and scale testing at that scope. Engineers scoping large-scale Kubernetes load tests can track cost-saving techniques like this on daily.dev.
What happens if an external kubara catalog defines a service with the same name as one in the built-in catalog?
kubara rejects the collision by default and generation fails safely, protecting teams from accidentally overriding a maintained built-in definition. Overriding it requires explicitly passing the --catalog-overwrite flag, which should only be used after verifying the dependencies of the replaced component, since other services may expect resources like Certificate or ServiceMonitor from it. Platform teams designing safe override workflows for shared infrastructure definitions can follow such patterns on daily.dev.