• /
  • EnglishEspañolFrançais日本語한국어Português
  • Inicia sesiónComenzar ahora

Agent Control overview

preview

We're still working on this feature, but we'd love for you to try it out!

This feature is currently provided as part of a preview program pursuant to our pre-release policies.

Managing observability infrastructure across a large, diverse environment is challenging. Manually deploying and configuring multiple agents on Kubernetes clusters is time-consuming, prone to errors, and difficult to keep consistent. This manual toil makes it hard to quickly add new instrumentation, optimize configurations, and keep agents updated.

Agent Control provides a single, unified solution for managing all your New Relic and OpenTelemetry agents. It runs as a lightweight supervisor within your Kubernetes clusters, communicating with the New Relic platform to receive remote configurations and deployment instructions. This eliminates the need for manual intervention on each host, allowing you to manage your entire fleet from a single, centralized location.

Architecture

Agent Control's power comes from its use of a declarative, GitOps-like approach to agent management. It treats the desired state of your instrumentation as a single source of truth, ensuring that what you configure in New Relic Control is what's running on your clusters.

The declarative engine: Flux on Kubernetes

On Kubernetes, Agent Control leverages Flux, a powerful and widely adopted CNCF project, as its declarative engine. Flux's controllers automatically deploy and update agents based on the configuration provided by Agent Control.

This declarative approach provides several key benefits:

  • Consistency: Eliminates configuration drift across your clusters.
  • Automation: Automatically applies configuration changes and updates, reducing manual toil.
  • Reliability: Provides a self-healing mechanism, as Flux continuously monitors and reconciles the state of your agents to match your desired configuration.

The diagram below shows how Agent Control connects to New Relic Control (the backend and UI) and Flux (the on-cluster engine) to manage your agents:

Agent Control architecture for agent management

Centralized remote configuration

Agent Control can use local or remote configurations. While local configurations are defined in the initial installation file, remote configurations are fetched from New Relic Control and rendered directly to your agents. This allows you to manage everything from a central point (and UI), including:

  • Credentials: Agent Control can pull sensitive credentials from external secret providers like Vault, rendering them into the agent's configuration at runtime. This enhances security by keeping credentials out of the configuration itself.
  • Agent Configuration: It automatically converts remote configurations into a format that is compatible with the underlying agent. This means you can manage different types of agents (e.g., Infrastructure Agent, OpenTelemetry Collector) with a single, unified process.

The future of agent management

This powerful architecture lays the foundation for future features that will further enhance your observability experience:

  • Fleet-wide commands: The ability to send commands and perform actions on your entire fleet of agents.
  • Advanced communication: Direct, real-time communication with agents for on-demand troubleshooting and data collection.
  • Enhanced security: Further integration with security providers and automated credential management.

Importante

To enable this level of control and communication, Agent Control requires specific permissions. It needs to be configured with the necessary access to pull configurations and to interact with local systems to manage the agent lifecycle. When deploying Agent Control, ensure you understand and grant the required permissions to maintain a secure and functional environment. Refer to the following section on Agent Control permissions.

Agent Control permissions

Deploying and managing agents in a Kubernetes cluster requires a clear understanding of the necessary permissions. Here, we'll explain the roles of both Agent Control and Flux and how they interact to securely install, update, and remove agents while ensuring that each agent only has the permissions it needs.

Kubernetes

In a Kubernetes environment, Agent Control uses Flux as its declarative engine to install, update, and uninstall agents. As such, Agent Control needs permissions to manage Flux resources, and Flux itself needs elevated permissions to manage the agent workloads.

  • Permissions for Agent Control: Agent Control requires permissions to create, read, update, and delete Flux-specific Custom Resources, such as HelmRelease and HelmRepository. This allows Agent Control to tell Flux what to do without needing direct cluster-admin access itself.
  • Permissions for Flux: Flux requires high-level permissions, typically with a cluster-admin role, to manage the lifecycle of any Helm chart it's instructed to deploy. This includes creating Deployments, DaemonSets, Services, and other core Kubernetes resources on behalf of the user. For security, it's a best practice to ensure that only trusted and verified configurations are used with Agent Control.

Agent-specific permissions

Different agent types and their configurations require different permissions. For example, an agent that collects metrics from the Kubernetes API needs more permissions than an agent that only reads logs from files.

Agent Control is designed to manage these permissions flexibly. While Flux requires a high level of access to function, our goal is to ensure that Agent Control only requests the minimum required permissions for the specific combination of agents you are deploying.

For detailed information on the specific permissions required by each agent, refer to Supported agent types.

Prerequisites

Before you begin deploying Agent Control to your Kubernetes clusters, ensure that you meet the following prerequisites:

  • Helm 3: Helm version 3 must be installed on your machine. For installation instructions, see Installing Helm.
  • New Relic license key: You'll need a license key to report telemetry to your New Relic account.
  • Kubernetes cluster name: Have the name of your Kubernetes cluster ready. You'll reference it during the installation process.
  • Auth Domain Manager: To set up Agent Control and connect it to Fleet Control, you must have the Authentication Domain Manager role. For more info, refer to User Management Concepts.

Environment support

Agent Control currently only supports Kubernetes. We are working on a public preview for on-host Linux systems, and support for other environments will be added in the future.

Important: Existing instrumentation

If your Kubernetes cluster is already instrumented with New Relic, you must uninstall the existing instrumentation before installing Agent Control. After installing Agent Control, you can use New Relic Control to install and manage all infrastructure agents on the cluster. For guidance on this process, refer to Manage existing instrumentation with Agent Control.

warning

Multiple installations of Agent Control on the same cluster are not supported.

Compatibility

Agent Control is compatible with:

  • Last three minor Kubernetes releases
  • Minikube, Kind, Amazon EKS, Azure AKS, and Google GKE

For system requirements related to the New Relic Kubernetes infrastructure agent and the New Relic OpenTelemetry (NRDOT) collector, refer to:

Next step

After you've confirmed compatibility and met all the prerequisites, you're ready to install Agent Control on your Kubernetes clusters.

Copyright © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.