All Kubernetes clusters are unique and have different sets of capabilities. See the Kubernetes page to understand the basic requirements for Kubernetes cluster before you start deploying.
The Artifacts page explains Helm charts as our distribution model, which is compatible with many deployment workflows and CI/CD tools. On this stage you should register necessary Helm repositories and prepare the initial configurations for the releases.If you are starting from scratch and don’t have a strong tooling preference - we recommend you to try the “infrastructure-as-code” approach that is described in our Quick Start guide.
We recommend you to deploy to get things running early. It’s always easier to progressively customize a working deployment than to plan out everything ahead.On this stage we recommend you to deploy the Node using in-memory transient storage and dummy auth which we will subsequently replace with real implementations.If you are using our deployment template, once again follow the Quick Start guide.
Most companies will have their own preferences for storage, databases, security, and disaster recovery workflows. For this reason in a production deployment we expect you to provide storage to Kamu Node. All storage solutions we provide with our deployment examples are meant for demonstrative purposes only and must not be used for data of any value.See Storage page for the list of supported storage systems for data lake and operational data.
Kamu Node is designed to provide optimal performance of all workloads according to the available cluster capacity, applying back pressure when needed. If you are deploying the node in a Kubernetes cluster shared with other applications you may want to restrict the resource usage of the node to prevent applications from “starving” one another. Limiting capacity can also be done for cost management.See Capacity page to understand available configuration options and the back pressure strategies the node uses when resources are insufficient.