Home assistant Helm chart, Issue in combination with MetalLB

[tabnul]

Good evening, first of all thanks for your helm chart. It helps a lot.

I do have an issue. . I use MetalLB and the NGinx ingress on K3s. I enable appdaemon and configurator, i set a loadbalanced ip. The helm chart creates 1 service instead of 3. The result is that i am unable to bind all 3 services on port 80 and have to use the ports when accessing the services.

I think this could be solved by using a seperate service / lb per enabled pod.

[onedr0p]

Are you trying to scale home assistant? That is not wise...

[tabnul]

Are you trying to scale home assistant? That is not wise...

I am not scaling. It is for redundancy / Failover purposes.

[onedr0p]

If you don't pin HA to a node using any affinities, k8s will by default failover HA to another node if the node it's running on dies.

[tabnul]

If you don't pin HA to a node using any affinities, k8s will by default failover HA to another node if the node it's running on dies.

Yes, and how do you access it once it failovered, using the same dns? This is where metallb comes in.

[onedr0p]

I don't know what to tell you, I also use Metallb and if the node with HA on it fails, it will simply failover to another node in my cluster.

[tabnul]

I don't know what to tell you, I also use Metallb and if the node with HA on it fails, it will simply failover to another node in my cluster.

Yes, and that functions, that is not the issue.

The issue is that this helm chart creates 1 service instead of 3. Due to the nature of how Metallb works (layer2) you are then unable to have multiple services running on port 80 (e.g. appdaemon, configurator, hass). Instead i have them now running on their original ports. It would be better to have them allrunning on normal HTTP(s) port and seperate it by DNS instead of port.

If there is a way to accomplish this , let me know. But AFAIK this is a limitation by the implementation of this chart and the cause is the fact that it creates 1 service for all selected/enabled components.

[billimek]

The answer to this issue is to break-out appDaemon into it's own separate 'service' (with an independently-configurable service type).

[billimek]

An example implementation of a dedicated 'service' can be the ~sonarr exporter service~ blocky tcp service in case anyone wants to take a crack at implementing a change to the home-assistant chart.

[billimek]

@tabnul another thing to consider is setting the existing appdaemon ingress settings to leverage your existing ingress controller to route external clients to appdaemon, instead of trying to tie all of the different services directly to port 80 on their own dedicated IP addresses.

[tabnul]

Thanks @billimek , will look into that. The current documentation of the HASS helm chart to me actually implies that you can separately configure a service (every addon has a .service.type / .service.LoadbalancerIP configuration )

[tabnul]

@tabnul another thing to consider is setting the existing appdaemon ingress settings to leverage your existing ingress controller to route external clients to appdaemon, instead of trying to tie all of the different services directly to port 80 on their own dedicated IP addresses.

I dont know exactly what you mean here. Wouldnt this bypass the MetalLB ip adress?

[billimek]

@tabnul yes, it would. You need to consider if you really want or need to have each service running in home-asssitant to be directly addressable via metalLB, or if you can access the service(s) via an ingress controller.

Personally speaking, and based on what I've seen done elsewhere, you want to leverage MetalLB to get IP addresses for the ingress controller itself and for any other non-http[s] based services (e.g. DNS service, unifi controller service, etc).

For all 'web' based services (i.e. things listening on port 80 or 443 handling http/https traffic), it's generally better to leverage an ingress controller to denote access to those services via a hostname controlled by the ingress controller.

For example in my cluster, most of the metallb-provided IPs are dedicated to services that can't already be handled by the ingress controller. The ingress controller itself has a metallb-provided IP address but I access home-assistant (and the vcsode addon 'service' via hostnames served by the ingress controller:

Does that sort of make sense?

TL;DR:

• "web" (http/https) based traffic 'should' be handled via an ingress controller
• non-web traffic that need to be accessed external from the cluster should leverage something like MetalLB to get a routable IP for clients outside the cluster

[tabnul]

@tabnul yes, it would. You need to consider if you really want or need to have each service running in home-asssitant to be directly addressable via metalLB, or if you can access the service(s) via an ingress controller.

Personally speaking, and based on what I've seen done elsewhere, you want to leverage MetalLB to get IP addresses for the ingress controller itself and for any other non-http[s] based services (e.g. DNS service, unifi controller service, etc).

For all 'web' based services (i.e. things listening on port 80 or 443 handling http/https traffic), it's generally better to leverage an ingress controller to denote access to those services via a hostname controlled by the ingress controller.

For example in my cluster, most of the metallb-provided IPs are dedicated to services that can't already be handled by the ingress controller. The ingress controller itself has a metallb-provided IP address but I access home-assistant (and the vcsode addon 'service' via hostnames served by the ingress controller:

Does that sort of make sense?

TL;DR:

• "web" (http/https) based traffic 'should' be handled via an ingress controller
• non-web traffic that need to be accessed external from the cluster should leverage something like MetalLB to get a routable IP for clients outside the cluster

Thanks, i did not know this is an option and it seems indeed the best option.

However today I swapped over to RKE (which has nginx builtin) but i miss the nginx ingress controller that i had with K3s+nginx. Going to look how i can enable that or create a new one.

Thanks so far :)