(no title)
12345ieee | 1 year ago
I want the values.yaml to express business logic, like feature flags or external endpoint configuration, so that the Delivery team can easily read and update it.
The complex infrastructural components should derive from the business config and deploy the needed infrastructure to support it.
Still, I wish I had this tidy list of working kubernetes yaml templates years ago, when we started rolling our charts where I work. I'm definitely checking out some of the resources to see if there is some cool parameter I can steal, thanks for sharing.
doctorpangloss|1 year ago
As another commenter said:
> So you write the whole configuration of the helm chart in your values.yaml?
Well that is a mistake, but that aside.
Helm is an ultra low budget operator for "any" Kubernetes asset where "all" the changes to that asset are caused by people. While this chart has little hope, Helm charts can be pure business logic.
For example, will infrastructure values ever be changed once deployed? I've seen changes to resource requests, replicas, domain names (for marketing driven concerns), and complex upgrades from non-clustered to clustered applications.
Can some of this be expressed as a "business" parameter in a values.yaml? Yes. Charts should ship with Keda ScaledObjects, and then it becomes translatable into a business definition like, "what is the limit on latency you want?" instead of "what is the limit of memory usage you want?"
This chart should provide an example ScaledObject, and maybe all sorts of stuff from the ecosystem that is valuable. A useful chart would homogenize (or be very opinionated) about OIDC, for example, too. That is business -> infrastructure.
The strength of the Kubernetes ecosystem is in translating business concerns like "transactions per second" into code. Infrastructure is a major business concern.