Open jeremiahsnapp opened 4 months ago
I found the cleanupExtraneousDaemonSets method in the controller's code. It looks like that's what causes the controller to create a conflict when it tries to manage more than one DatadogAgent resource. The cleanupExtraneousDaemonSets
method gets a list of all daemonset resources that have the labels agent.datadoghq.com/component: agent
and app.kubernetes.io/managed-by: datadog-operator
. As the controller manages each resource it sees the other resource's daemonset as extraneous and deletes it.
If this is by design, can someone add documentation to make it clear that the datadog-operator can only manage a single daemonset?
Is it possible to add some other unique label per DatadogAgent resource that would only match and delete daemonsets related to a particular DatadogAgent resource?
I have datadog-operator 1.7.0 installed and a working DatadogAgent resource which configures a cluster-agent deployment and node-agent daemonset in my kubernetes cluster. This is working fine but I want to create multiple DatadogAgent resources that are configured to run node-agents on different sets of nodes with different configurations for the node-agents. For example, I have a set of nodes that i want to have APM disabled.
I tried creating a second DatadogAgent configuration that has
clusterAgent.disabled=true
, since I don't need more cluster-agents installed, but when I add this to the cluster the datadog-operator doesn't seem to like it. It creates the second daemonset and deletes the first daemonset and then creates the first daemonset and deletes the second daemonset and just loops like that.I don't see any documentation about the operator being limited to only a single DatadogAgent though. I do see documentation about the DatadogAgentProfile (DAP) which does allow for custom node-agent configurations per a set of nodes but it doesn't let me disable APM. DAP customizations are very limited.