[Feature]: Helm value for icinga2-master Endpoint address

[MTSym]

Affected Chart

icinga-stack

Please describe your feature request

By default the endpoint address for the icinga2-master is, afaik, the fullname of the pod.
The problem with this is the generated "Agent" configurations which want to connect to the cluster internal address even if they are installed outside the cluster. By having the host value configurable it is possible to avoid this and the Agent scripts should be copy&paste again.

[mocdaniel]

We will have to take a look if we can go ahead and change this - I remember something about the director kickstart breaking when meddling with the Endpoint configuration, but I'll have another look.

[CanisLupusLupus]

I had the same problem in my local deploy and I resolved it by setting icinga2.config.node_name to external name, i.e. to address used in ingress.

[mocdaniel]

I finally found the time to look at this issue and it raises some problems:

• The director will use the Endpoint configuration(s) of the parent zone's satellite(s)/leader(s)
• Therefore, it's not enough to e.g. change the FQDN given in the Director kickstart configuration
• We would need to actually change the NodeName of Icinga2, as CanisLupusLupus noted.
• This means, that cluster-internal components would get routed out of the cluster and back into the cluster instead of being able to use cluster-local routing.
  This is due to us relying on said NodeName for cluster-internal connections targeting the Icinga2 API, e.g. Icingaweb2 or Director.

I am not entirely sure whether this is a sane change to make or if it's more bearable for administrators to adapt the script, which gets generated by the Director upon host creation.

Feel free to share your thoughts on the situation, @MTSym @CanisLupusLupus @martialblog

[CanisLupusLupus]

I went with external FQDN as Icinga2 NodeName in my local deployment for simplification, to keep configuration customization to minimum and to have hassle-free user experience, at the cost (as pointed out by mocdaniel) of routing traffic outside of cluster.
Initially I tried to simply keep default NodeName and update Director generated host scripts, but this does not work out of the box - TLS fails because of host name mismatch. I am sure this can be solved either by:

• using custom cert with subject alt names on Icinga2 node
• with reverse proxy
• using dedicated satellite node for out of cluster agents

But all three options (I am sure there are more possibilities, but those three are the simplest ones that I can think of off hand and with some light skimming of Icinga2 docs) increase complexity and fragility of deployment.

[srvrguy]

I've run into this issue too, and I think it's probably worth the loss of cluster-local routing to resolve issues with satellite and agent setups. I'm personally patching things with Kustomize to keep the pod name more standardized and have a separate name for the cert, and director kickstart values.

If you are interested, I can submit a PR that will allow the selection of a different DNS name for the API stuff, while keeping the current default. This, I think, would be a good compromise. If you don't need external connections you can keep the default and get local routing. If you are going to need external API access, you can set the value to get that.