[Metricbeat] Added daemonsetHostNetworking switch

[kalioz]

• Chart version not bumped (the versions are all bumped and released at the same time)
• README.md updated with any new values or changes
• Updated template tests in ${CHART}/tests/*.py
• Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Since #315 has been closed here is a PR to add the hostNetwork setting to the daemonset pods.

Why > some metrics use the pod's name instead of the host name when hostNetwork is not set. This is showing in kibana's Infrastructure panel.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[cla-checker-service]

Author of the following commits did not sign a Contributor Agreement:
8e2beae, c4d5f15

Please, read and sign the above mentioned agreement if you want to contribute to this project

[cla-checker-service]

Author of the following commits did not sign a Contributor Agreement:
8e2beae, c4d5f15, 97667da

Please, read and sign the above mentioned agreement if you want to contribute to this project

[pbecotte]

I closed that PR because I found a better way of doing it. In my metricbeat config I did

secretMounts:
    - name: elastic-certificate-pem
      secretName: elastic-certificates
      path: /usr/share/metricbeat/config/certs
extraEnvs:
    - name: 'NODE_HOSTNAME'
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: 'NODE_HOST_IP'
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP

and

metricbeat.yml: |
    name: "${NODE_HOSTNAME}"
    metricbeat.modules:
    -  module: kubernetes
        add_metadata: true
        metricsets:
          - container
          - node
          - pod
          - system
        host: "${NODE_HOSTNAME}"
        hosts: ["https://${NODE_HOST_IP}:10250"]
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        ssl.certificate_authorities:
          - /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

This config is best when A. the kubelet node name is not routable from within a pod, B. your kubelet is serving https at port 10250. C. Your kubelet has its ip address listed as a "server alternate name" on its certificate

Depending, you may want to use http://${NODE_HOST_IP}:10255 (if you have the insecure read only port enabled on your cluster). In that case, the token file and ssl.certificate_authorities can be left out. If you have to use https but the node ip address isn't on the certificate, you'll have to use insecure mode on the https connection.

[kalioz]

thanks @pbecotte , adding name: "${NODE_NAME}" indeed is a better way to solve this problem.

[FedeBev]

@pbecotte I'm trying your solution but I can't make it work due the following error:

https://<MY_IP>:10250/stats/summary: x509: cannot validate certificate for <MY_IP> because it doesn't contain any IP SANs

Moreover, I think the /var/run/secrets/kubernetes.io/serviceaccount/ca.crt is not right for the kubelet but is for the kube api server.

Our solution:
Our cluster is created using RKE, to make it works we had to mount the host path /var/lib/kubelet/pki/ where RKE stores the kubelet CA certificate and we had to use the /var/lib/kubelet/pki/kubelet.crt certificate for the ssl.certificate_authorities value and the name of the host instead the host IP.

[pbecotte]

Awesome! It was using RKE that I built out that solution. Even better, the code is publicly available.
The key points here are you have to tell RKE to add the IP SANs to the certificate. I was on DigitalOcean and also had to manually install the cloud-provider for that to work. Here are the key lines in my config- let me know if this gets it working?

https://gitlab.com/devblog/infrastructure/blob/master/modules/rancher/cluster/main.tf#L71
https://gitlab.com/devblog/infrastructure/blob/master/modules/rancher/cluster/main.tf#L53
https://gitlab.com/devblog/infrastructure/blob/master/argocharts/elastic/values.yaml#L70

[pbecotte]

To further clarify, you are right, that IS the kube-api CA. RKE will use that CA to generate valid kubelet certificates if you set the generate_serving_certificate option instead of having each kubelet create the entire CA.