Add kubernetes.node.hostname field with the actual hostname of the node

[jsoriano]

Describe the enhancement:

On some cases we need to correlate host names with kubernetes nodes, or filter events by kubernetes node using host names. On these cases we rely on host.name having a consistent value with kubernetes.node.name, but they are values of different nature:

• host.name is the hostname as returned by the operating system.
• kubernetes.node.name is the node name as registered in the Kubernetes API, what could in theory be any string that matches as DNS subdomain.

Even if the kubernetes node name is most of the times the host name, we have seen cases where the OS reports the hostname as FQDN, and the kubernetes name is the same, but without the domain, what leads to host.name and kubernetes.node.name to have different values.

Kubernetes API reports more data about nodes apart of their name, including some hostnames. We could include the hostname in the events as a kubernetes.node.hostname field.

Hostnames can be found as addresses in node metadata, and the definition is coherent with the value used in Beats for host.name (The hostname as reported by the node’s kernel), see https://v1-17.docs.kubernetes.io/docs/concepts/architecture/nodes/#addresses

Describe a specific use case for the enhancement or feature:

Metrics UI shows nodes per host.name, but when zooming into kubernetes views it expects the kubernetes.node.name to be coherent with host.name so it can link from one view to the other and show the expected data.

[elasticmachine]

Pinging @elastic/integrations-platforms (Team:Platforms)

[exekias]

This is a good point, I didn't know the hostname was available through the API! would it make sense to always set host.name from here instead of relying on add_host_metadata? That would actually kill the need for hostNetwork in Filebeat

[exekias]

Nice to see this moving forward, there is also the opportunity to reuse this for host inventory metadata, right @jsoriano ?