A integração New Relic Kubernetes oferece total observabilidade da integridade e do desempenho do seu ambiente, aproveitando o agente New Relic Infrastructure . Este agente coleta dados de telemetria do seu cluster usando diversas integrações New Relic , como o Kubernetes evento integração, o agente Prometheus e o plug-in New Relic Logs Kubernetes .
Opções de instalação
Para instalar nossa integração com Kubernetes, recomendamos que você siga as instruções aqui para nossa experiência de instalação guiada. Recomendamos esta ferramenta de instalação interativa para servidores, VM e ambientes sem privilégios .
A experiência de instalação guiada simplifica o processo de instalação da integração New Relic Kubernetes e oferece controle sobre quais recursos estão habilitados e quais dados são coletados. Ele também oferece uma opção de início rápido que inclui alguns recursos opcionais pré-construídos, como painel e alertas junto com a integração Kubernetes para que você possa obter visibilidade instantânea do seu cluster do Kubernetes.
Você pode escolher uma das três opções a seguir:
CLI New Relic
Um comando Helm com valores obrigatórios pré-preenchidos
Um manifesto simples
Navegando na instalação guiada de integração do Kubernetes
Depois de iniciar a instalação guiada, utilize as informações a seguir para ajudá-lo a tomar decisões sobre a configuração.
Dica
As etapas a seguir ignoram as etapas preliminares do início rápido. Se você escolheu a instalação guiada com o início rápido, basta clicar nas páginas Confirm your Kubernetes quickstart installation e Installation plan para acessar as principais páginas de instalação guiada descritas abaixo.
Prepare-se para instalar
Prepare seu sistema Kubernetes para a instalação guiada:
Se manifestos personalizados tiverem sido usados em vez do Helm, você precisará primeiro remover a instalação antiga usando
kubectl delete -f previous-manifest-file.yml
e, em seguida, prosseguir novamente com o instalador guiado. Isso gerará um conjunto atualizado de manifestos que podem ser implantados usandokubectl apply -f manifest-file.yml
.Certifique-se de usar as versões suportadas Kubernetes e verifique as notas preliminares para seus serviços gerenciados ou plataforma em nossa página de compatibilidade e requisitos.
Certifique-se de ter sua New Relic . Você pode configurar uma conta gratuita – sem necessidade de cartão de crédito.
Certifique-se de que o domínio newrelic Dockerhub (
https://hub.docker.com/u/newrelic
) e o registro do Google (registry.k8s.io
) sejam adicionados à sua lista de permissões. É daqui que a instalação extrairá as imagens do contêiner. Observe que pode ser necessário seguir os comandos para identificar o domínio de registro adicional do Google a ser adicionado à sua lista branca, porqueregistry.k8s.io
normalmente redireciona para o domínio de registro local (por exemplo,asia-northeast1-docker.pkg.dev
) com base na sua região.Se você estiver instalando nossa integração em uma nuvem gerenciada, dê uma olhada nestas notas preliminares antes de continuar:
Comece a instalação guiada
Comece sua instalação guiada clicando em uma das opções abaixo:
Opção de instalação guiada
Descrição
Use-o se a sua New Relic organização não usar o da UE data center e você não precisar do painel de bônus e dos alertas do início rápido.
Use-o se a sua organização New Relic usar o data center da UE e você não precisar do painel de bônus e do alerta do início rápido.
Use esta opção se sua organização New Relic não usar o data center da UE e você também quiser instalar algum painel de bônus e alerta do início rápido.
Configure sua instalação
Na página Configure the Kubernetes Integration preencha os seguintes campos:
Campo
Descrição
Enviaremos seus dados para esta conta
Escolha a conta New Relic na qual você deseja gravar seus dados do Kubernetes.
Nome do cluster
Nome cluster é o nome que usaremos para tag seus dados Kubernetes para que você possa filtrar os dados específicos do cluster no qual está instalando esta integração. Isso é importante se você optar por conectar vários clusters à sua conta New Relic , portanto escolha um nome que você reconheça.
Namespace para a integração
Namespace for the integração é o namespace que usaremos para hospedar a integração do Kubernetes em seu cluster. Recomendamos usar o namespace padrão
newrelic
.Selecione dados adicionais
Na página Select the additional data you want to gather, escolha as opções certas para você:
Raspe o endpoint do Prometheus
Ao selecionar esta opção, instalaremos o Prometheus em modo agente para coletar métricas do endpoint do Prometheus exposto em seu cluster. Expanda os recolhedores para ver detalhes sobre cada opção:
Reúna dados log
Você pode personalizar os detalhes dos dados log na interface de instalação:
Habilite insights de nível de serviço, solicitações de corpo inteiro e perfis de aplicativos por meio do Pixie
Pixie é uma ferramenta de observação de código aberto para aplicativo Kubernetes que utiliza eBPF para coletar automaticamente dados de telemetria. Se você não tem o Pixie instalado em seu cluster, mas deseja aproveitar a poderosa coleta e visualização de dados de telemetria do Pixie na plataforma New Relic, verifique Enable service-level insights, full-body requests, and application profiles through Pixie.
Se você já estiver usando o Community Cloud, selecione Community Cloud hosted Pixie is already running on this cluster. Tenha em mente o seguinte sobre as diferentes maneiras pelas quais o Pixie pode ser hospedado. A New Relic oferece um nível diferente de suporte de integração para cada opção de hospedagem Pixie.
Conclua sua instalação
Finalize a configuração da instalação do Kubernetes escolhendo um dos seguintes métodos de instalação na última etapa da instalação guiada:
Guided Install (recommended): esta opção fará download e usará automaticamente a CLI
newrelic-cli
para instalar e configurar a integração do Kubernetes.Helm 3: use esta opção se preferir usar o Helm para instalar e configurar a integração do Kubernetes. Esta opção instala o gráfico Helm
nri-bundle
, que você pode configurar posteriormente com as opções descritas aqui.Manifest: selecione esta opção se preferir gerar um manifesto do Kubernetes no formato YAML e instalá-lo manualmente com
kubectl
.Dica
Não está vendo dados? Se você completou as etapas acima e ainda não está vendo os dados, confira esta página de resolução de problemas.
Use esta opção quando você tiver um sistema Kubernetes baseado em Windows. Observe que existem várias limitações para a integração do Windows.
visualização
Este recurso está atualmente em versão prévia.
Compatibilidade e requisitos
Antes de instalar a integração do Kubernetes, revise a compatibilidade e os requisitos.
Importante
Ao utilizar contêiner no Windows, a versão do host do contêiner e a versão da imagem do contêiner devem ser iguais. Nossa integração com Kubernetes pode ser executada nas versões Windows LTSC 2019 (1809), 20H2 e LTSC 2022.
Para verificar sua versão do Windows:
Abra uma janela de comando.
Execute o seguinte comando:
bash$Reg Query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v$ReleaseIdcmd.exeExemplo: Obtenha o Kubernetes para Windows de um contêiner BusyBox
Execute este comando:
bash$kubectl exec -it busybox1-766bb4d6cc-rmsnj -- Reg Query$"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ReleaseIdVocê deverá ver algo assim:
bash$HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion$ReleaseId REG_SZ 1809Para um mapeamento útil entre IDs de lançamento e versões do sistema operacional, veja aqui.
Instalar
Você pode instalar a integração do Kubernetes para Windows usando Helm. Veja um exemplo de como instalar a integração em um cluster com nós com diferentes versões de build do Windows (1809 e 2004):
Adicione o repositório de gráficos do New Relic Helm:
bash$helm repo add newrelic https://helm-charts.newrelic.comCrie um namespace para newrelic:
bash$kubectl create namespace newrelicInstale o kube-state-métrica.
bash$helm repo add ksm https://kubernetes.github.io/kube-state-metrics$helm install ksm ksm/kube-state-metrics --version 2.13.2Importante
Este comando serve para instalar o kube-state-métrica, uma dependência obrigatória da integração, num nó Linux. Não oferecemos suporte à instalação para nós não Linux e, se você instalá-lo em um nó não Linux, a implantação poderá falhar. Recomendamos usar
nodeSelector
para escolher um nó Linux. Isto pode ser feito editando a implantação kube-state-métrica.Crie um arquivo
values-newrelic.yaml
com os seguintes dados a serem usados pelo Helm:global:licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_cluster: _K8S_CLUSTER_NAME_enableLinux: true # Set to true if your cluster also has linux nodesenableWindows: truewindowsOsList:- version: 2019 # Human-readable version identifierimageTag: 2-windows-1809-alpha # Tag to be used for nodes running the windows version abovebuildNumber: 10.0.17763 # Build number for your nodes running the version above. Used as a selector.- version: 20h2imageTag: 2-windows-20H2-alphabuildNumber: 10.0.19042- version: 2022imageTag: 2-windows-ltsc2022-alphabuildNumber: 10.0.20348nodeSelector:kubernetes.io/os: linux # Selector for Linux installation.windowsNodeSelector:kubernetes.io/os: windows # Selector for Windows installation.Instale a integração com:
bash$helm upgrade --install newrelic newrelic/newrelic-infrastructure \>--namespace newrelic --create-namespace \>--version 2.7.2 \>-f values-newrelic.yamlVerifique se o pod está sendo implantado e atinge um estado estável:
bash$kubectl -n newrelic get pods -wO gráfico do Helm criará um DaemonSet para cada versão do Windows que estiver na lista e usará o NodeSelector para implantar o pod correspondente por nó.
Limitações
As seguintes limitações se aplicam à integração do Kubernetes para Windows:
O agente do Windows envia apenas as amostras do Kubernetes (
K8sNodeSample
,K8sPodSample
, etc.)SystemSample
,StorageSample
,NetworkSample
eProcessSample
não são gerados.- Algumas métricasKubernetes estão faltando porque o kubelet do Windows não as possui:
Nó:
fsInodes
: não enviadofsInodesFree
: não enviadofsInodesUsed
: não enviadomemoryMajorPageFaultsPerSecond
: sempre retorna zero como valormemoryPageFaults
: sempre retorna zero como valormemoryRssBytes
: sempre retorna zero como valorruntimeInodes
: não enviadoruntimeInodesFree
: não enviadoruntimeInodesUsed
: não enviado
Pod:
net.errorsPerSecond
: não enviadonet.rxBytesPerSecond
: não enviadonet.txBytesPerSecond
: não enviado
Contêiner:
containerID
: não enviadocontainerImageID
: não enviadomemoryUsedBytes
: na interface, isso é exibido no cartão pod que aparece quando você clica em um pod e não mostra dados. Em breve corrigiremos isso atualizando nossos gráficos para usarmemoryWorkingSetBytes
.
Volume:
fsUsedBytes
: zero, entãofsUsedPercent
é zero
Problemas conhecidos com o Windows Kubelet
Existem alguns problemas com a versão Windows do Kubelet que podem impedir a integração de buscar dados:
Problema 90554: esse problema faz com que o Kubelet retorne 500 erros quando a integração faz uma solicitação ao endpoint
/stats/summary
. Ele será incluído na versão 1.19 do Kubernetes e foi portado para as versões 1.16.11, 1.17.7 e 1.18.4. Não há solução do lado da integração para este problema, aconselhamos que você atualize para uma das versões do patch o mais rápido possível. Você pode ver se está sendo afetado por esse problema ativando o log detalhado e procurando mensagens do tipo:bash$error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": error calling kubelet endpoint. Got status code: 500Problema 87730: esse problema torna a métrica do Kubelet muito lenta ao executar carga mínima. Isso faz com que a integração falhe com um erro de tempo limite. Um patch para esse problema foi adicionado ao Kubernetes 1.18 e portado para 1.15.12, 1.16.9 e 1.17.5. Aconselhamos você a atualizar para uma das versões de patch o mais rápido possível. Para atenuar esse problema, você pode aumentar o tempo limite de integração com a opção de configuração
TIMEOUT
. Você pode ver se está sendo afetado por esse problema ativando o log detalhado e procurando mensagens do tipo:bash$error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Use esta opção ao monitorar a carga de trabalho Kubernetes no EKS Fargate. Esta integração injeta automaticamente um sidecar contendo o agente de infraestrutura e a integração nri-Kubernetes em cada pod que precisa ser monitorado.
Visualização
Este recurso está atualmente em versão prévia.
New Relic suporta monitoramento de carga de trabalho Kubernetes no EKS Fargate injetando automaticamente um sidecar contendo o agente de infraestrutura e a nri-kubernetes
integração em cada pod que precisa ser monitorado.
Caso o mesmo cluster do Kubernetes também contenha nós EC2, nossa solução também será implantada como DaemonSet
em todos eles. Nenhum sidecar será injetado em pods programados em nós EC2 e nenhum DaemonSet
será implantado em nós Fargate. Aqui está um exemplo de instância híbrida com nós Fargate e EC2:
Em um ambiente misto, a integração usa apenas um arquivo secundário para nós do Fargate.
New Relic coleta todas as métricas suportadas para todos os objetos Kubernetes , independentemente de onde eles estão agendados, sejam nós Fargate ou EC2. Observe que, devido às limitações impostas pelo Fargate, a integração do New Relic está limitada à execução em modo sem privilégios nos nós do Fargate. Isso significa que as métricas que geralmente são buscadas diretamente do host, como processos em execução, não estarão disponíveis para nós Fargate.
O agente em ambos os cenários extrairá dados da Kube State métrica (KSM), Kubelet e cAdvisor e enviará os dados no mesmo formato.
Importante
Assim como para qualquer outro cluster do Kubernetes, nossa solução ainda requer que você implante e monitor uma instância Kube State métrica (KSM). Nosso Helm Chart e/ou instalador fará isso automaticamente por padrão, embora esse comportamento possa ser desabilitado se o seu cluster já tiver uma instância funcional do KSM. Esta instância KSM será monitorada como qualquer outra workload: injetando um arquivo secundário se for agendado em um nó Fargate ou com a instância local do DaemonSet
se for agendado em um nó EC2.
Outros componentes da solução New Relic para Kubernetes, como nri-prometheus
, nri-metadata-injection
e nri-kube-events
, não possuem particularidades e serão implantados pelo nosso Helm Chart normalmente como seriam em ambientes não Fargate.
instalação
Você pode escolher entre duas alternativas para instalar a observabilidade completa do New Relic em seu cluster EKS Fargate:
Independentemente da abordagem escolhida, a experiência é exatamente a mesma depois de instalada. A única diferença é como o contêiner é injetado. Recomendamos configurar a injeção automática com o operador de monitoramento de infraestrutura New Relic porque isso eliminará a necessidade de editar manualmente cada implantação que você deseja monitor.
Injeção automática (recomendada)
Por padrão, quando o suporte do Fargate estiver ativado, o New Relic implantará um operador no cluster (
newrelic-infra-operator
). Uma vez implantado, este operador injetará automaticamente o sidecar de monitoramento nos pods que estão programados nos nós Fargate, ao mesmo tempo que gerencia a criação e a atualização deSecrets
,ClusterRoleBindings
, e quaisquer outros recursos relacionados.Este operador aceita uma variedade de opções avançadas de configuração que podem ser usadas para restringir ou ampliar o escopo da injeção, através do uso de seletores de rótulos para pod e namespace.
O que a operadora faz
Nos bastidores, o operador configura um
MutatingWebhookConfiguration
, que permite modificar os objetos pod que estão prestes a ser criados no cluster. Neste evento, e quando o pod que está sendo criado corresponder à configuração do usuário, o operador irá:
Adicione um contêiner secundário ao pod que contém a integração do New Relic Kubernetes.
Se um segredo não existir, crie um no mesmo namespace do pod que contém a New Relic
, que é necessário para que o arquivo secundário relate dados.
Adicione a conta de serviço do pod a um
ClusterRoleBinding
previamente criado pelo gráfico do operador, que concederá a este sidecar as permissões necessárias para atingir o endpoint métrico Kubernetes .O
ClusterRoleBinding
concede as seguintes permissões ao pod que está sendo injetado:rules:
apiGroups: [""] resources:
- "nodes"
- "nodes/metrics"
- "nodes/stats"
- "nodes/proxy"
- "pods"
- "services"
- "namespaces" verbs: ["get", "list"]
nonResourceURLs: ["/metrics"] verbs: ["get"]
<Callout variant="tip">Para que o sidecar seja injetado e, portanto, obtenha a métrica do pod implantado antes da instalação do operador, é necessário realizar manualmente um rollout (restart) da implantação afetada. Desta forma, quando o pod for criado, o operador poderá injetar o sidecar de monitoramento. A New Relic optou por não fazer isso automaticamente para evitar interrupções inesperadas de serviço e picos de uso de recursos.</Callout><Callout variant="important">Lembre-se de criar um perfil do Fargate com um seletor que declare o namespace `newrelic` (ou o namespace que você escolher para a instalação).</Callout>Aqui está o fluxo de trabalho de injeção:<imgtitle="Diagram showing the workflow of sidecar injection"alt="Diagram showing the workflow of sidecar injection"src={kubernetesFargateWorkflow}/>#### Instalação de injeção automática [#auto-injection-install]<Callout variant="tip">As etapas a seguir são para uma configuração padrão. Antes de concluí-los, sugerimos que você dê uma olhada na seção [de configuração](#config-auto) abaixo para ver se deseja modificar algum aspecto da injeção automática.</Callout>Primeiro, adicione o repositório New Relic Helm, caso ainda não tenha feito isso:```shellhelm repo add newrelic https://helm-charts.newrelic.comEntão, para instalar o operador responsável por injetar o sidecar da infraestrutura, crie um arquivo chamado
values.yaml
, que será utilizado para definir sua configuração:## Global valuesglobal:# -- The cluster name for the Kubernetes cluster.cluster: "_YOUR_K8S_CLUSTER_NAME_"# -- The license key for your New Relic Account. This will be preferred configuration option if both `licenseKey` and `customSecret` are specified.licenseKey: "_YOUR_NEW_RELIC_LICENSE_KEY_"# -- (bool) In each integration it has different behavior. Enables operating system metric collection on each EC2 K8s node. Not applicable to Fargate nodes.# @default -- falseprivileged: true# -- (bool) Must be set to `true` when deploying in an EKS Fargate environment# @default -- falsefargate: true## Enable nri-bundle sub-chartsnewrelic-infra-operator:# Deploys the infrastructure operator, which injects the monitoring sidecar into Fargate podsenabled: truetolerations:- key: "eks.amazonaws.com/compute-type"operator: "Equal"value: "fargate"effect: "NoSchedule"config:ignoreMutationErrors: trueinfraAgentInjection:# Injection policies can be defined here. See [values file](https://github.com/newrelic/newrelic-infra-operator/blob/main/charts/newrelic-infra-operator/values.yaml#L114-L125) for more detail.policies:- namespaceName: namespace-a- namespaceName: namespace-bnewrelic-infrastructure:# Deploys the Infrastructure Daemonset to EC2 nodes. Disable for Fargate-only clusters.enabled: truenri-metadata-injection:# Deploy our mutating admission webhook to link APM and Kubernetes entitiesenabled: truekube-state-metrics:# Deploys Kube State Metrics. Disable if you are already running KSM in your cluster.enabled: truenri-kube-events:# Deploy the Kubernetes events integration.enabled: truenewrelic-logging:# Deploys the New Relic's Fluent Bit daemonset to EC2 nodes. Disable for Fargate-only clusters.enabled: truenewrelic-prometheus-agent:# Deploys the Prometheus agent for scraping Prometheus endpoints.enabled: trueconfig:kubernetes:integrations_filter:enabled: truesource_labels: ["app.kubernetes.io/name", "app.newrelic.io/name", "k8s-app"]app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb", "velero", "harbor", "argocd", "istio"]Finalmente, depois de criar e ajustar o arquivo, você pode implantar a solução usando o seguinte comando do Helm:
bash$helm upgrade --install newrelic-bundle newrelic/nri-bundle -n newrelic --create-namespace -f values.yamlImportante
Ao implantar a solução em um cluster híbrido (com nós EC2 e Fargate), certifique-se de que a solução não esteja selecionada por nenhum perfil Fargate; caso contrário, a instância
DaemonSet
ficará presa em um estado pendente. Para ambientes somente fargate, isso não é uma preocupação porque nenhuma instânciaDaemonSet
é criada.Configuração
Você pode configurar diferentes aspectos da injeção automática. Por padrão, o operador injetará o sidecar de monitoramento em todos os pods implantados em nós Fargate que não fazem parte de um
Job
ou de umBatchJob
.Este comportamento pode ser alterado através de opções de configuração. Por exemplo, você pode definir seletores para restringir ou ampliar a seleção de pods injetados, atribuir recursos ao operador e ajustar o arquivo secundário. Além disso, você pode adicionar outros atributos, rótulos e variáveis de ambiente. Consulte o gráfico README.md e values.yaml.
Importante
Especificar suas próprias regras de injeção personalizadas descartará o conjunto de regras padrão que impede a injeção de sidecar em pods que não estão programados no Fargate. Certifique-se de que suas regras personalizadas tenham o mesmo efeito; caso contrário, no cluster híbrido que também possui o
DaemonSet
implantado, o pod programado no EC2 será monitorado duas vezes, levando a dados incorretos ou duplicados.Atualize para a versão mais recente ou para uma nova configuração
Para atualizar para a versão mais recente da integração do EKS Fargate, atualize o repositório Helm usando
helm repo update newrelic
e reinstale o pacote simplesmente executando novamente o comando acima.Para atualizar a configuração do agente de infraestrutura injetado ou do próprio operador, modifique o
values-newrelic.yaml
e faça upgrade da versão do Helm com a nova configuração. O operador é atualizado imediatamente e sua carga de trabalho será instrumentada com a nova versão na próxima reinicialização. Se desejar atualizá-los imediatamente, você pode forçar a reinicialização da sua carga de trabalho executando:bash$kubectl rollout restart deployment YOUR_APPDesinstale a integração do Fargate
Para desinstalar o sidecar realizando a injeção automática, mas manter o restante da solução New Relic, usando Helm, desative o infra-operador configurando
infra-operator.enabled
comofalse
, no arquivovalues.yaml
ou na linha de comando (--set
) e execute novamente o comando de instalação acima.É altamente recomendável manter o sinalizador
--set global.fargate=true
, pois ele não permite a injeção automática, mas torna outros componentes da instalação cientes do Fargate, evitando comportamentos indesejados.Para desinstalar toda a solução:
Desinstale completamente a versão do Helm.
Abra o pod para remover o sidecar:
bash$kubectl rollout restart deployment YOUR_APPLixo colete os segredos:
bash$kubectl delete secrets -n YOUR_NAMESPACE -l newrelic/infra-operator-created=trueLimitações conhecidas: injeção automática
Aqui estão alguns problemas que você deve estar ciente ao usar a injeção automática:
Atualmente não há nenhum controlador que monitore todo o cluster para garantir que os segredos que não são mais necessários sejam coletados como lixo. No entanto, todos os objetos compartilham o mesmo rótulo que pode ser usado para remover todos os recursos, se necessário. Injetamos o rótulo
newrelic/infra-operator-created: true
, que você pode usar para excluir recursos com um único comando.No momento, não é possível usar o sidecar injetado para monitor serviços em execução no pod. O sidecar monitor apenas o próprio Kubernetes . Porém, o usuário avançado pode querer excluir esses pods da injeção automática e injetar manualmente uma versão customizada do sidecar com integração no host habilitada, configurando-os e montando sua configuração no local apropriado. Para obter ajuda, consulte este tutorial.
Injeção manual
Se você tiver alguma dúvida sobre a injeção automática, poderá injetar o sidecar manualmente diretamente, modificando os manifestos da carga de trabalho agendada que será agendada nos nós Fargate. Observe que adicionar o sidecar à implantação agendada em nós EC2 pode levar a dados incorretos ou duplicados, especialmente se esses nós já estiverem sendo monitorados com o
DaemonSet
.Os seguintes objetos são necessários para que o arquivo secundário relate dados com êxito:
O
ClusterRole
fornece a permissão necessária para a integraçãonri-kubernetes
Um
ClusterRoleBinding
vinculando oClusterRole
e a conta de serviço do podO segredo que armazena a New Relic
licenseKey
em cada namespaceFargateO contêiner sidecar no modelo de especificação da workloaddo monitor
Instalação de injeção manual
Dica
Estas etapas de configuração manual são para uma instalação genérica. Antes de concluí-los, dê uma olhada na seção de configuração abaixo para ver se deseja modificar algum aspecto da injeção automática.
Complete o seguinte para injeção manual:
Se
ClusterRole
não existir, crie-o e conceda as permissões necessárias para atingir o endpoint métrico. Isso só precisa ser feito uma vez, mesmo para monitoramento de vários aplicativos no mesmo cluster.Para cada workload que você deseja monitor, adicione um contêiner secundário adicional para a imagem
newrelic/infrastructure-k8s
. Aqui está um exemplo de um sidecar injetado.Crie um
ClusterRoleBinding
, ou adicione a um já criado oServiceAccount
do aplicativo que será monitorado. Toda a carga de trabalho pode compartilhar o mesmoClusterRoleBinding
, mas oServiceAccount
de cada uma deve ser adicionado a ela.Crie um segredo contendo a New Relic . Cada namespace precisa de seu próprio segredo.
Configuração
Ao adicionar manualmente o manifesto do agente secundário, você pode usar qualquer opção de configuração do agente para configurar o comportamento do agente. Para obter ajuda, consulte Definições de configuração do agente de infraestrutura.
Atualize para a versão mais recente
Para atualizar qualquer um dos componentes, basta modificar o yaml implantar.
Atualizar qualquer um dos campos do contêiner injetado fará com que o pod seja recriado.
Importante
O agente não pode carregar a quente a New Relic . Após atualizar o segredo, é necessário implantar novamente a implantação.
Desinstale a integração do Fargate
Para remover o contêiner injetado e os recursos relacionados, basta remover o seguinte:
O sidecar da carga de trabalho que não deve mais ser monitorado.
Todos os segredos que contêm a licença newrelic.
ClusterRole
eClusterRoleBinding
objetos.Observe que a remoção do contêiner secundário fará com que o pod seja recriado.
Exploração madeireira
O registro em log do New Relic não está disponível em nós do Fargate devido a restrições de segurança impostas pela AWS, mas aqui estão algumas opções de registro:
Se você estiver usando o Fluentbit para registro, consulte Plug-inKubernetes para encaminhamento de logs.
Se seus dados log já estiverem sendo monitorados pelo AWS FireLens, consulte Plug-in AWS FireLens para encaminhamento de logs.
Se os dados log já estiverem sendo monitorados pelo log do Amazon CloudWatch, consulte Transmitir log usando o Kinesis Data Firehose.
Consulte AWS Lambda para enviar log do CloudWatch.
Consulte Três maneiras de encaminhar log do Amazon ECS para New Relic.
Resolução de problemas
Réplicas do DaemonSet estão sendo implantadas em nós Fargate
Se você notar que alguma réplica do Infra
DaemonSet
está sendo programada em nós do Fargate, pode ser porque as regrasnodeAffinity
não estão configuradas corretamente.Verifique novamente se a solução foi instalada com a opção
global.fargate
paratrue
, por meio da linha de comando (--set global.fargate=true
) ou no arquivovalues.yaml
. Se o método de instalação não for Helm, você precisará adicionar manualmentenodeAffinity
regras para excluir nós do Fargate.Evento
FailedScheduling
devido a contaminação não toleradaLembre-se de adicionar no arquivo
values.yaml
otolerations
descrito em Instalação de injeção automática se você receber o seguinte evento ao tentar criar um pod:LAST SEEN | TYPE | REASON | OBJECT | MESSAGE:--|:--|:--|:--|:--3m9s (x2 over 8m10s) | Warning | FailedScheduling | Pod/no-fargate-deploy-cbddd6ccf-8f9x4 | 0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..Evento
FailedScheduling
devido a muitos podsVerifique se há um perfil do Fargate com um seletor que nomeie o namespace onde a instalação está ocorrendo se você receber o seguinte evento ao tentar criar um pod:
LAST SEEN | TYPE | REASON | OBJECT | MESSAGE:--|:--|:--|:--|:--61s | Warning | FailedScheduling | Pod/newrelic-bundle-newrelic-infra-operator-admission-create-d8ggt | 0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod..Veja seus dados EKS
Aqui está um exemplo da aparência de um nó Fargate na interface New Relic :
Para visualizar seus dados da AWS:
Vá para
one.newrelic.com > All capabilities > Infrastructure > Kubernetes
e siga um destes procedimentos:
- Selecione um nome de integração para visualizar os dados.
- Selecione o ícone Explorar dados para visualizar os dados da AWS.
Filtre seus dados usando duas tags Fargate:
computeType=serverless
fargateProfile=[name of the Fargate profile to which the workload belongs]
Se quiser usar o Helm para instalar a integração, você tem duas opções:
Nossa experiência de instalação guiada, que fornecerá um comando Helm com os campos obrigatórios pré-preenchidos. Esta opção também permite instalar nossa integração como manifestos simples, em vez de uma versão do Helm.
Configuração manual através do arquivo
values.yaml
. Esta guia irá guiá-lo sobre como fazer isso.Helm é um gerenciador de pacotes baseado no Kubernetes. Facilita a instalação, atualizações ou rastreamento de revisão e gerencia a dependência dos serviços que você instala no Kubernetes. Se ainda não o fez, crie sua conta New Relic gratuita abaixo para começar a monitorar seus dados hoje mesmo.
Compatibilidade e requisitos
Certifique-se de que o Helm esteja instalado em sua máquina. A versão 3 da integração do Kubernetes requer a versão 3 do Helm.
Para instalar a integração do Kubernetes usando Helm, você precisará do New Relic e do nome do cluster do Kubernetes:
Encontre e copie seu .
Escolha um nome de exibição para seu cluster. Por exemplo, você poderia usar a saída de:
bash$kubectl config current-contextImportante
Mantenha esses valores em um local seguro, pois você precisará deles posteriormente durante o processo de instalação.
Instale a integração do Kubernetes com Helm
New Relic possui vários gráficos Helm para os diferentes componentes que oferecem diferentes recursos para a plataforma:
newrelic-infrastructure
: contém a integração principal do Kubernetes e o agente de infraestrutura. Este é o componente principal da New Relic Kubernetes experiência do , responsável por relatar a maioria dos dados que aparecem no Kubernetes dashboard e no cluster do Kubernetes Explorer.newrelic-logging
: Fornece um DaemonSet com o New Relic plug-in de saída Fluent Bit da para encaminhar facilmente seu log para New Relic.nri-kube-events
: coleta e relata eventos cluster (comokubectl get events
) para New Relic.newrelic-prometheus-agent
: O Prometheus Configurator do New Relic configura um Prometheus no modo agente e usa nosso endpoint de gravação remota para relatar métricas para New Relic.nri-metadata-injection
: configura umMutatingAdmissionWebhook
mínimo que injeta algumas variáveis de ambiente no contêiner. Estes contêm metadados sobre o cluster e instalação New Relic e serão posteriormente captados pelo aplicativo instrumentado usando APM, permitindo correlacionar dados APM e infraestrutura.nri-statsd
: Integração New Relic StatsD.Embora você possa instalar esses componentes separadamente, recomendamos fortemente que você use a tabela
nri-bundle
. A New Relic fornece este gráfico, que atua como um wrapper ou metapacote para os gráficos individuais mencionados acima. O uso deste gráfico permite estas vantagens:Ele fornece controle total sobre quais componentes estão instalados. Cada componente é instalado como uma dependência separada do Helm. Você pode configurá-los individualmente usando o parâmetro mencionado aqui.
Ele garante que as versões instaladas sejam compatíveis entre si.
Ele garante que seus valores de configuração sejam consistentes nos gráficos instalados.
O gráfico
nri-bundle
é aquele instalado e configurado por nossa instalação guiada do Kubernetes.Instalando e configurando
nri-bundle
com Helm
Certifique-se de usar o contexto apropriado na máquina onde executará o Helm e
kubectl
:Você pode verificar os contextos disponíveis com:
bash$kubectl config get-contextsE mude para o contexto desejado usando:
bash$kubectl config use-context _CONTEXT_NAME_Adicione o repositório de gráficos do New Relic Helm:
bash$helm repo add newrelic https://helm-charts.newrelic.comCrie um arquivo chamado
values-newrelic.yaml
, que será usado para definir sua configuração:global:licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_cluster: _K8S_CLUSTER_NAME_newrelic-prometheus-agent:# Automatically scrape prometheus metrics for annotated services in the cluster# Collecting prometheus metrics for large clusters might impact data usage significantlyenabled: truenri-metadata-injection:# Deploy our webhook to link APM and Kubernetes entitiesenabled: truenri-kube-events:# Report Kubernetes eventsenabled: truenewrelic-logging:# Report logs for containers running in the clusterenabled: truekube-state-metrics:# Deploy kube-state-metrics in the cluster.# Set this to true unless it is already deployed.enabled: trueCertifique-se de que tudo esteja configurado corretamente no gráfico executando o seguinte comando. Observe que estamos especificando
--dry-run
e--debug
, portanto nada será instalado nesta etapa:bash$helm upgrade --install newrelic-bundle newrelic/nri-bundle \>--namespace newrelic --create-namespace \>-f values-newrelic.yaml \>--dry-run \>--debugObserve e ajuste os seguintes sinalizadores:
global.licenseKey=YOUR_NEW_RELIC_LICENSE_KEY
: deve ser definido como umválido para sua conta.
global.cluster=K8S_CLUSTER_NAME
: É usado para identificar o cluster na interface New Relic , portanto deve ser um valor descritivo não usado por nenhum outro cluster do Kubernetes configurado em sua conta New Relic .kube-state-metrics.enabled=true
: Definir comotrue
instalará automaticamente a Kube State métrica (KSM) para você, que é necessária para o funcionamento de nossa integração. Você pode definir isso como falso se o KSM já estiver presente em seu cluster, mesmo que esteja em um namespace diferente.newrelic-prometheus-agent.enabled=true
: Iremos implantar nosso agente Prometheus, que coleta automaticamente dados do endpoint Prometheus presente no cluster.nri-metadata-injection.enabled=true
: instalará nosso webhook mínimo, que adiciona variáveis de ambiente que, por sua vez, permite vincular o aplicativo instrumentado com New Relic APM ao Kubernetes.
Nossos gráficos do Kubernetes possuem um conjunto abrangente de sinalizadores e ajustes que podem ser editados para melhor atender às suas necessidades específicas. Por favor, verifique a seção Configurar a integração abaixo para ver o que pode ser alterado.
Instale a integração do Kubernetes executando o comando sem
--debug
e--dry-run
:bash$helm upgrade --install newrelic-bundle newrelic/nri-bundle \>--namespace newrelic --create-namespace \>-f values-newrelic.yamlImportante
Verifique se você está usando o Kubernetes versão 1.27.x ou uma versão inferior compatível com.
Verifique se o pod está sendo implantado e atinge um estado estável:
bash$kubectl -n newrelic get pods -wVocê deveria ver:
newrelic-nrk8s-ksm
pod.newrelic-nrk8s-kubelet
pod para cada nó em seu cluster.newrelic-nrk8s-control-plane
pod para cada nó mestre em seu cluster, se houver.newrelic-kube-state-metrics
pod, se você incluiu o KSM em nossa instalação.newrelic-nri-kube-events
pod, se você ativou o relatório de eventos Kubernetes .prometheus-agent
pod, se você ativou a integração do agente Prometheus .newrelic-newrelic-logging
pod para cada nó em seu cluster, se você ativou a integração de criação de log.Este documento ajudou você na instalação?
Configurar a integração
Nosso gráfico
nri-bundle
. cujas instruções de instalação podem ser encontradas acima, atua como um wrapper ou meta-pacote para alguns outros gráficos, que contêm os componentes de nossa solução. Ao oferecer esse wrapper, podemos fornecer um conjunto controlado de nossos componentes com versões que sabemos serem compatíveis entre si, mantendo os gráficos dos componentes relativamente simples.O gráfico
nri-bundle
agrupa vários gráficos individuais para coletar diferentes dados de telemetria e enviá-los para o New Relic. O pacote permite ativar seletivamente os gráficos secundários desejados, dependendo de suas necessidades. Para configurar cada componente individual, você deve usar o sistema de dependência do Helm, o que, resumidamente, significa que a configuração de cada gráfico filho deve ser colocada em uma seção separada (nomeada após cada gráfico filho) no arquivo values-newrelic.yml. Por exemplo, para configurar o gráficonewrelic-infrastructure
, você adicionaria o seguinte aovalues-newrelic.yaml
:# General settings that apply to all the child chartsglobal:licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_cluster: _K8S_CLUSTER_NAME_# ... Other settings as shown above# Specific configuration for the newrelic-infrastructure child chartnewrelic-infrastructure:verboseLog: true # Enable debug logsprivileged: false # Install with minimal privileges# Other options from https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-infrastructure-v3# Specific configuration for the newrelic-logging child chartnewrelic-logging:fluentBit:retryLimit: 10Você também pode passar opções de gráfico filho por meio da linha de comando, prefixando-as com o nome do gráfico filho e substituindo o aninhamento por pontos:
helm upgrade --install newrelic-bundle newrelic/nri-bundle \--namespace=newrelic \--set global.licenseKey=_YOUR_NEW_RELIC_LICENSE_KEY_ \--set global.cluster=_K8S_CLUSTER_NAME_ \--set newrelic-infrastructure.privileged=false \--set newrelic-infrastructure.verboseLog=true \--set newrelic-logging.fluentBit.retryLimit=10A lista completa de flags que você pode ajustar (como scrape-interval) para cada gráfico filho pode ser encontrada em seus respectivos repositórios:
Configurar log de depuração, modo de privilégio, monitoramento do plano de controle, etc.
Configure como o webhook para ligação APM é implantado.
Configure quais endpoints do Prometheus serão copiados.
Configure qual log ou atributo log será enviado para New Relic.
Dica
Ao especificar opções de configuração para os gráficos secundários, você deve colocá-los em uma seção com o nome do gráfico em seu
values-newrelic.yaml
.Dica
Para passar opções de gráfico filho por meio da linha de comando, você precisa prefixá-las com o nome do gráfico filho e substituir o aninhamento por pontos.
Há três maneiras de instalar a integração do Kubernetes no cluster do GKE Autopilot:
A CLI do New Relic encontrada em nossa instalação guiada
Um comando Helm com valores obrigatórios pré-preenchidos
Um manifesto simples com valores obrigatórios pré-preenchidos
Use seus dados do Kubernetes
Aprender mais sobre:
- Modos sem privilégios e privilegiados
- Explorando seus dados Kubernetes na interface
- Utilizando seus dados Kubernetes com consultas, em gráficos, para alertas, etc.