Importante
El enrutamiento multicuenta requiere el chart nr-ebpf-agent Helm versión 1.5.0 o superior. Esta característica solo está disponible para los despliegues de Kubernetes del agente eBPF.
Si su clúster de Kubernetes aloja varios equipos o inquilinos, puede configurar el agente eBPF de New Relic para enrutar la telemetría a una cuenta de New Relic diferente según el namespace de Kubernetes en el que se ejecuta una carga de trabajo. Esto permite que los datos de cada equipo lleguen a su propia cuenta mientras un solo daemonset de agente eBPF cubre todo el clúster.
Cómo funciona el enrutamiento de múltiples cuentas
El daemonset del agente eBPF lee un mapa de namespace a clave de licencia de un secreto de Kubernetes, inyectado como la variable de entorno NAMESPACE_LICENSE_KEY_MAP. Puede proporcionar este mapa de una de dos maneras, y son mutuamente excluyentes:
namespaceLicenseKeys— Defina el mapa directamente en suvalues.yaml. El gráfico lo almacena en un secreto que crea para usted.customSecretNamespaceLicenseKeys— Apunte a un secreto de Kubernetes que usted mismo cree y administre, para que las claves de licencia nunca aparezcan envalues.yamlni en el control de código fuente.
Sugerencia
Si configura tanto namespaceLicenseKeys como customSecretNamespaceLicenseKeys, namespaceLicenseKeys tiene prioridad y se ignora el secreto personalizado. Configure solo uno.
Para un pod determinado, el agente busca el namespace del pod en el mapa:
- Si el namespace es una clave en el mapa, la telemetría de ese namespace se enruta a la cuenta correspondiente.
- Si el namespace no está en el mapa, la telemetría recurre al
licenseKeyocustomSecretNameglobal del clúster.
Configurar el enrutamiento de múltiples cuentas
Elija una de las siguientes opciones según si desea las claves de licencia en línea en values.yaml o en un secreto que administre por separado.
Agregue un mapa namespaceLicenseKeys a su values.yaml, con una entrada por namespace que desee enrutar a su propia cuenta:
namespaceLicenseKeys: team-a: "NRAK-aaa..." team-b: "NRAK-bbb..."Luego, aplique el cambio:
$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yamlAdvertencia
Esto almacena las claves de licencia directamente en values.yaml. Si confirma este archivo en el control de código fuente, use la opción de secreto personalizado en su lugar.
Cree un secreto de Kubernetes con una clave de datos llamada exactamente NAMESPACE_LICENSE_KEY_MAP, cuyo valor sea un mapa de namespace a clave de licencia codificado en JSON. El secreto debe residir en el mismo namespace que la versión eBPF agent.
apiVersion: v1kind: Secretmetadata: name: my-nr-namespace-keys namespace: newrelictype: OpaquestringData: NAMESPACE_LICENSE_KEY_MAP: '{"team-a":"NRAK-aaa...","team-b":"NRAK-bbb..."}'Luego, haz referencia al secreto en values.yaml y deja namespaceLicenseKeys vacío:
namespaceLicenseKeys: {}customSecretNamespaceLicenseKeys: "my-nr-namespace-keys"Aplique el cambio:
$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yamlImportante
La clave de datos del secreto debe ser exactamente NAMESPACE_LICENSE_KEY_MAP — el chart no la renombra. El valor debe ser un JSON válido con claves y valores entre comillas dobles; un mapa mal formado deshabilita el enrutamiento por completo (el agente lo trata como vacío).
Cosas que saber
- Cree el secreto personalizado en el mismo namespace que la versión de eBPF agent (por ejemplo,
newrelic), no en los namespace de la carga de trabajo que está enrutando (comoteam-a). - No establezcas tanto
namespaceLicenseKeyscomocustomSecretNamespaceLicenseKeys. Si ambos no están vacíos, el mapa en línea gana silenciosamente. - Los namespaces que no aparecen en el mapa continúan usando el
licenseKeyocustomSecretNameglobal del clúster. Consulta los parámetros de configuración de K8s para obtener detalles sobre esos ajustes.