• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Configurez le routage multicompte pour l’agent eBPF de New Relic

Important

Le routage multicompte nécessite la version 1.5.0 ou supérieure du chart nr-ebpf-agent Helm. Cette fonctionnalité est uniquement disponible pour les déploiements Kubernetes de l'agent eBPF.

Si votre cluster Kubernetes héberge plusieurs équipes ou locataires, vous pouvez configurer l’agent eBPF de New Relic pour router la télémétrie vers un compte New Relic différent en fonction de l’espace de nommage Kubernetes dans lequel un workload s’exécute. Cela permet aux données de chaque équipe d’atterrir dans son propre compte tandis qu’un seul daemonset d’agent eBPF couvre l’ensemble du cluster.

Fonctionnement du routage multicompte

Le daemonset de l’agent eBPF lit un mappage entre espace de nommage et clé de licence à partir d’un secret Kubernetes, injecté en tant que variable d’environnement NAMESPACE_LICENSE_KEY_MAP. Vous fournissez ce mappage de l’une des deux manières suivantes, et elles sont mutuellement exclusives :

  • namespaceLicenseKeys — Définissez la carte directement dans votre values.yaml. Le chart le stocke dans un secret qu'il crée pour vous.
  • customSecretNamespaceLicenseKeys — Pointez vers un secret Kubernetes que vous créez et gérez vous-même, afin que les clés de licence n’apparaissent jamais dans values.yaml ou dans le contrôle de code source.

Conseil

Si vous définissez à la fois namespaceLicenseKeys et customSecretNamespaceLicenseKeys, namespaceLicenseKeys a la priorité et le secret personnalisé est ignoré. N’en définissez qu’un seul.

Pour un pod donné, l’agent recherche l’espace de nommage du pod dans le mappage :

  • Si l’espace de nommage est une clé dans la carte, la télémétrie de cet espace de nommage est acheminée vers le compte correspondant.
  • Si l'espace de nommage n'est pas dans le mappage, la télémétrie se rabat sur le licenseKey ou customSecretName global du cluster.

Configurer le routage multicompte

Choisissez l'une des options suivantes selon que vous souhaitez que la clé de licence soit en ligne dans values.yaml ou dans un secret que vous gérez séparément.

Ajoutez une carte namespaceLicenseKeys à votre values.yaml, avec une entrée par espace de nommage que vous souhaitez acheminer vers son propre compte :

namespaceLicenseKeys:
team-a: "NRAK-aaa..."
team-b: "NRAK-bbb..."

Puis appliquez la modification :

bash
$
helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

Prudence

Cela stocke les clés de licence directement dans values.yaml. Si vous validez ce fichier dans le contrôle source, utilisez plutôt l’option de secret personnalisé.

Créez un secret Kubernetes avec une clé de données nommée exactement NAMESPACE_LICENSE_KEY_MAP, dont la valeur est une carte espace de nommage vers clé de licence encodée en JSON. Le secret doit résider dans le même espace de nommage que la sortie eBPF agent.

apiVersion: v1
kind: Secret
metadata:
name: my-nr-namespace-keys
namespace: newrelic
type: Opaque
stringData:
NAMESPACE_LICENSE_KEY_MAP: '{"team-a":"NRAK-aaa...","team-b":"NRAK-bbb..."}'

Ensuite, référencez le secret dans values.yaml, et laissez namespaceLicenseKeys vide :

namespaceLicenseKeys: {}
customSecretNamespaceLicenseKeys: "my-nr-namespace-keys"

Appliquer la modification :

bash
$
helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

Important

La clé de données du secret doit être exactement NAMESPACE_LICENSE_KEY_MAP — le chart ne la renomme pas. La valeur doit être du JSON valide avec des clés et des valeurs entre guillemets doubles ; une map mal formée désactive entièrement le routage (l’agent la traite comme vide).

À savoir

  • Créez le secret personnalisé dans le même espace de nommage que la sortie eBPF agent (par exemple, newrelic), et non dans les espaces de nommage du workload que vous routez (comme team-a).
  • Ne définissez pas à la fois namespaceLicenseKeys et customSecretNamespaceLicenseKeys. Si les deux ne sont pas vides, la carte en ligne l’emporte silencieusement.
  • Les espaces de nommage qui ne sont pas listés dans la carte continuent d’utiliser le licenseKey ou customSecretName global du cluster. Consultez les paramètres de configuration K8s pour plus de détails sur ces paramètres.
Droits d'auteur © 2026 New Relic Inc.

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