i’m currently authoring a Helm Chart for my Home Assistant Deployment on Kubernetes. The existing Helm Chart wasn’t really working on my K3S Cluster and i had to add edit the Configuration.yaml after the Deployment, so that Home Assistant would use the deployed MariaDB for example.
At the Moment my Home Assistant Instance is running on a Home Assistant VM with Supervisor on my QNAP NAS. But since the NAS is not the fastest i’m currently building a dedicated Kubernetes Cluster for my Home Assistant Deployment.
A simple examle is already running. I can deploy Home Assistant with a VSCode Server Sidecar and a MariaDB on my ARM based K8S Cluster (4 Raspberry PIs with K3S).
At the Moment i’ve not yet decided how to configure Home Assistant. For example when the User consider to deploy a MariaDB as Database i’ve to add the Recorder Configuration to Home Assistant, so that Home Assistant is aware of that databse.
I could deploy the configuration.yaml as a Kubernetes Config Map. Then Helm had full Control about the File and could add Entries for Database, panel_iframe (for VSCode). Otherwise i could use the Package Feature and add the YAML Entries as Packages. But that dosn’t seems to be the best solutions. With that i’ve to configure all the YAML Configuration for Home Assistant in Kubernetes and there’s always the problem that the Helm Chart will override my changes.
The other Option that i’m considerung is using the Packages Feature. I would deploy all the Package YAML Files in a separat Folder and add two Lines to the configuration.yaml:
homeassistant: packages: !include_dir_named packages
What would you prefer? Configure all through K8s and/or Helm or have the ability to configure the configuration.yaml as you like? From the Perspective of a Kubernetes Administrator i would move the Configuration Part to K8s and Helm. As a Home Assistant user i prefer the direct configuration via configuration.yaml.
Since most of the new Features/Ingration are mostly configured via the UI its the Question how much yaml config we’ll have in the future.