frigate VS hull

The README thing is one of the reasons why I created Frigate.

If you are just starting out and decide to go with writing your own Helm Charts I'd like to suggest our HULL Helm Library Chart for that purpose.

With HULL we have proposed an alternative yet Helm based solution a year ago which that tries to do it upside down by first giving you a documented Kubernetes API style full access to each objects configuration. Only on top of that it provides you further advanced options to (re)introduce abstraction into the mix - only if you need them and they actually improve your configuration. Everything takes place in the values.yaml so there is no digging around in the templates folder and everything is in view.

The HULL library Helm chart provides a single common interface to specifying Kubernetes objects within Helm Charts. The interface itself is based on the Kubernetes API schema itself which is integrated as a JSON schema in the HULL chart. Since all objects are defined directly in the values.yaml under the hull key there is no need to create and maintain custom template files when creating objects with HULL, everything happens in the values.yaml.

Good, now proceed by creating a new empty HULL based Helm chart. The steps are documented here but you will create it from scratch here to understand what is needed.

As a reminder, the goal of this tutorial series is to demonstrate how to build Helm charts based on the HULL library chart by recreating the functionality of the original kubernetes-dashboard Helm chart with a HULL based chart from scratch. When you have followed the previous part of this tutorial on setting up a HULL base chart you have created a for now unconfigured Helm chart named kubernetes-dashboard-hull in the 02_setup subfolder of your working directory (we assume that's ~/kubernetes-dashboard-hull here). You can alternatively download the current chart state here and continue from there. Also you should have checked out and extracted the kubernetes-dashboard Helm chart to kubernetes-dashboard in your working directory because examining it will be frequently required.

the ability to specify any CustomResource as a customresource object instance. For CustomResources you additionally need to specify the kind and apiVersion besides the free form spec of your object.

We have built a Helm Library chart named HULL, it provides amongst other features full access to all defined objects and their properties at creation and deployment time. Think of it as an API to specify Kubernetes objects directly in a Helm charts values.yaml. If there is some functionality you want to add or use in a particular scenario you can just configure it and the Kubernetes objects are as you actually want them to be - every aspect can always be tuned at deploy time if needed without you having to get back to the chart creator via PRs, hack the chart or similar methods. All doable with Helm and the HULL library chart, no other tooling required!

We actually proposed an alternative way to solve the problem if you are Helm with our Helm library chart HULL.

It may be worthwhile to look at the recently added examles, these are more advanced chart values.yamls from products we are deploying this way. You can see it can be pretty concise to define your applications structure with HULL in comparison.

Downsides to this is that you would have to write out the full content of your config in the values.yaml and cannot use the templating capabilities any further. Within the values.yaml no templating is allowed (unless you base your chart on this library chart we have created ;) which may be a more advanced topic if you just got started)