-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option for global kubernetes autodiscover #10578
Comments
👍 |
👍 to doing this, I would add a new parameter to |
👍 yes, such a scope would be very helpful. Actually I can see the following scope/namespace patterns (obviously requiring appropriate permissions):
At the moment I use a simple hack to the source code to disable (comment out) the check for the current node to get the cluster scope working for me, because I urgently needed it. |
|
It would make sense too for heartbeat. IMHO having a daemonset is not really necessary. |
#14738 added the |
Currently, beats in kubernetes are thought to be run as a daemon set where each beat collects information from the pods running in the same node, and from the node itself.
Autodiscover is built on this premise and it only discovers pods running in the same node.
Running the beat in the same node as the observed pods is necessary for example in filebeat because it needs access to local files, but it doesn't need to be necessary in metricbeat modules, that could be connecting to network endpoints.
(The kubernetes module is an exception to that, it collects information from the API and don't need to be associated to any node, and is actually recommended to be run from a single Deployment per cluster)
The proposal is to add an option to remove this dependency between autodiscover and the node where the beat is running, so, when possible, pods are discovered from a different node. This would allow different deployment architectures in special cases:
The text was updated successfully, but these errors were encountered: