# Kubernetes autodiscover provider with "hostNetwork: true"

**URL:** <https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091>\
**Category:** Beats\
**Tags:** metricbeat\
**Created:** [June 15, 2018, 12:23pm UTC](https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091 "2018-06-15T12:23:26Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hamelg](https://avatars.discourse-cdn.com/v4/letter/h/ecae2f/32.png) [@hamelg](https://discuss.elastic.co/u/hamelg)\
**Post date:** [June 15, 2018, 12:23pm UTC](https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091/1 "2018-06-15T12:23:26Z")

</div>

I want to setup a metricbeat pod to gather host's metrics AND also to collect other metrics in containers via the kubernetes provider.

Exemple :

```
## Collect apache metrics in apache containers
   metricbeat.autodiscover:
      providers:
        - type: kubernetes
          templates:
            - condition:
                equals:
                  kubernetes.labels.metricbeat: "apache"
              config:
                - module: apache
                  metricsets: ["status"]
                  hosts: ["http://${data.host}:8089"]

## collect k8s nodes statistics
    metricbeat.modules:
    - module: kubernetes
      metricsets:
        - node
        - system
      hosts: ["https://localhost:10250"]

```

To allow to connect to the node's kubelet ([https://localhost:10250](https://localhost:10250)), the metricbeat pod is setup with "hostNetwork: true" [1].

When the metricbeat is starting up, it logs the errors :

```
Querying for pod failed with error: %!(EXTRA string=kubernetes api: Failure 404 pods "myHost.zzz.xx" not found)
Unable to find pod, setting host to localhost

```

and the provider collects nothing.

a possible workaround is to setup 2 pods :  
1 pod to run the kubernetes autodiscover providers with hostNetwork: false  
1 pod to run the kubernetes modules with hostNetwork: true.

Is there a mean to run successfully the kubernetes autodiscover provider with "hostNetwork: true" ?

[1] [https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces)

---

<div class="post-metadata">

**Author:** ![\_flo](https://avatars.discourse-cdn.com/v4/letter/_/f17d59/32.png) [@\_flo](https://discuss.elastic.co/u/_flo)\
**Post date:** [June 15, 2018, 9:35pm UTC](https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091/2 "2018-06-15T21:35:36Z")

</div>

Hi,

Have you tested with the ClusterFirstWithHostNet DNS Policy

> **[DNS for Services and Pods - Kubernetes](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)**
>
> DNS for Services and Pods

Regards

---

<div class="post-metadata">

**Author:** ![hamelg](https://avatars.discourse-cdn.com/v4/letter/h/ecae2f/32.png) [@hamelg](https://discuss.elastic.co/u/hamelg)\
**Post date:** [June 18, 2018, 8:34am UTC](https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091/3 "2018-06-18T08:34:57Z")

</div>

> [@\_flo](#):
>
> ClusterFirstWithHostNet

Unfortunately, it makes no difference.  
It seems the issue comes from how the hostname is setup in the pod :  
When hostNetwork is true, the pod is setup with the node hostname where the pod is running.  
When hostNetwork is false, the pod is setup with the pod name.  
So, with hostNetwork:true the kubernetes provider looks up the node to follow with the pod hostname, and it doesn't find it.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 16, 2018, 8:35am UTC](https://discuss.elastic.co/t/kubernetes-autodiscover-provider-with-hostnetwork-true/136091/4 "2018-07-16T08:35:01Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.