Add samples for Beats setup #2041
Conversation
| k8s-app: metricbeat | ||
| spec: | ||
| serviceAccountName: metricbeat | ||
| hostNetwork: true |
There was a problem hiding this comment.
Why does the deployment need access to the host network?
There was a problem hiding this comment.
It is to report the actual hostname of the machine and not the name of the metricbeat container when fetching node-wide metrics from kube-state-metrics (elastic/beats#7463).
There was a problem hiding this comment.
We indeed use this to report host metadata, by using the add_host_metadata processor. We could consider copying NODE_NAME to host.name, but would lose the rest
|
API version nits and a question about the deployment. I know that is what the upstream yaml has but I was still curious why. Upstream already updated all the api versions I'm pretty sure. I didn't get a chance to use this yet but it seems super useful. It also seems like this is a very good candidate for a helm chart because of all the hardcoded name references. I'm coming around to the idea of a helm chart that would deploy the operator and the config you just provided. |
|
Interestingly the upstream Metricbeat and Filebeat manifests still use the beta versions. |
It seems that since elastic/beats#13851 and elastic/beats#14046, there is no more beta versions. > curl -s https://raw.githubusercontent.com/elastic/beats/master/deploy/kubernetes/metricbeat-kubernetes.yaml | grep apiVersion | sort | uniq -c
2 apiVersion: apps/v1
2 apiVersion: rbac.authorization.k8s.io/v1
5 apiVersion: v1 |
|
It might also be convenient to create the apiVersion: v1
kind: Namespace
metadata:
name: beats |
|
Nice to see this happening! we were in the process of adding exactly this, but the other way around, see elastic/beats#14131. A later step would be to add this to the Beats docs. |
| host: ${NODE_NAME} | ||
| hints.enabled: true | ||
|
|
||
| setup.dashboards.enabled: true |
There was a problem hiding this comment.
Hey! How about moving all these kibana related stuff to the Deployment config map?
Deployment stands as a singleton for the whole cluster so it will far less expensive to load the dashboards from there instead of from each of the Daemonset instances.
Also maybe using env vars for the KIBANA_HOST and KIBANA_PORT might make it prettier.
See also: https://github.com/elastic/beats/pull/14131/files#diff-6c4e791fd61d7fd51348955d49d87917R219
There was a problem hiding this comment.
I followed your examples and fixed up my metricbeat config. I am not sure about where the right place for these examples is, feels wrong to duplicate it in both repos?
I also raised #2051 to discuss next steps
|
jenkins test this please |
This reverts commit 12e9420.
I used these manifests for testing but thought it might be helpful for others as well to have them in our samples directory.