Importante
O roteamento de várias contas requer o gráfico nr-ebpf-agent Helm versão 1.5.0 ou superior. Este recurso está disponível apenas para implantações do Kubernetes do agente eBPF.
Se o seu cluster do Kubernetes hospeda várias equipes ou locatários, você pode configurar o agente eBPF do New Relic para rotear a telemetria para uma conta diferente do New Relic com base no namespace do Kubernetes em que um workload é executado. Isso permite que os dados de cada equipe cheguem à sua própria conta, enquanto um único daemonset do agente eBPF cobre todo o cluster.
Como o roteamento de múltiplas contas funciona
O daemonset do agente eBPF lê um mapa de namespace para chave de licença de um secret do Kubernetes, injetado como a variável de ambiente NAMESPACE_LICENSE_KEY_MAP. Você fornece esse mapa de uma de duas maneiras, e elas são mutuamente exclusivas:
namespaceLicenseKeys— Defina o mapa diretamente no seuvalues.yaml. O gráfico armazena isso em um segredo que ele cria para você.customSecretNamespaceLicenseKeys— Aponte para um secret do Kubernetes que você mesmo cria e gerencia, para que as chaves de licença nunca apareçam emvalues.yamlou no controle de versão.
Dica
Se você definir tanto namespaceLicenseKeys quanto customSecretNamespaceLicenseKeys, namespaceLicenseKeys terá precedência e o segredo personalizado será ignorado. Defina apenas um.
Para um determinado pod, o agente procura o namespace do pod no mapa:
- Se o namespace for uma chave no mapa, a telemetria desse namespace será roteada para a conta correspondente.
- Se o namespace não estiver no mapa, a telemetria retornará ao
licenseKeyoucustomSecretNameglobal do cluster.
Configurar roteamento de várias contas
Escolha uma das seguintes opções com base em se você deseja chaves de licença embutidas em values.yaml ou em um segredo que você gerencia separadamente.
Adicione um mapa namespaceLicenseKeys ao seu values.yaml, com uma entrada por namespace que você deseja rotear para sua própria conta:
namespaceLicenseKeys: team-a: "NRAK-aaa..." team-b: "NRAK-bbb..."Em seguida, aplique a alteração:
$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yamlCuidado
Isso armazena as chaves de licença diretamente em values.yaml. Se você confirmar este arquivo no controle de versão, use a opção de secret personalizado em vez disso.
Crie um secret do Kubernetes com uma chave de dados nomeada exatamente NAMESPACE_LICENSE_KEY_MAP, cujo valor é um mapa de namespace para chave de licença codificado em JSON. O secret deve residir no mesmo namespace que a versão 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..."}'Em seguida, referencie o secret em values.yaml e deixe namespaceLicenseKeys vazio:
namespaceLicenseKeys: {}customSecretNamespaceLicenseKeys: "my-nr-namespace-keys"Aplique a alteração:
$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yamlImportante
A chave de dados do secret deve ser exatamente NAMESPACE_LICENSE_KEY_MAP — o chart não a renomeia. O valor deve ser um JSON válido com chaves e valores entre aspas duplas; um mapa malformado desativa totalmente o roteamento (o agente o trata como vazio).
Coisas a saber
- Crie o segredo personalizado no mesmo namespace da versão eBPF agent (por exemplo,
newrelic), não nos namespaces de workload que você está roteando (comoteam-a). - Não defina tanto
namespaceLicenseKeysquantocustomSecretNamespaceLicenseKeys. Se ambos não estiverem vazios, o mapa inline vence silenciosamente. - Os namespaces que não estão listados no mapa continuam a usar o
licenseKeyoucustomSecretNameglobal do cluster. Consulte os parâmetros de configuração do K8s para obter detalhes sobre essas configurações.