Instale a integração do Kubernetes

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.

Compatibilidade e requisitos

Antes de instalar a integração do Kubernetes, revise a compatibilidade e os requisitos.

Para verificar sua versão do Windows:

1. Abra uma janela de comando.

2. Execute o seguinte comando:

   bash

   Copiar

   $
   Reg Query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v
   $
   ReleaseIdcmd.exe

   Exemplo: Obtenha o Kubernetes para Windows de um contêiner BusyBox

   Execute este comando:

   bash

   Copiar

   $
   kubectl exec -it busybox1-766bb4d6cc-rmsnj -- Reg Query
   $
   "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ReleaseId

   Você deverá ver algo assim:

   bash

   Copiar

   $
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
   $
   ReleaseId   REG_SZ  1809

   Para 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):

3. Adicione o repositório de gráficos do New Relic Helm:

   bash

   Copiar

   $
   helm repo add newrelic https://helm-charts.newrelic.com

4. Crie um namespace para newrelic:

   bash

   Copiar

   $
   kubectl create namespace newrelic

5. Instale o kube-state-métrica.

   bash

   Copiar

   $
   helm repo add ksm https://kubernetes.github.io/kube-state-metrics
   $
   helm install ksm ksm/kube-state-metrics --version 2.13.2

   Importante

   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.

6. 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 nodes
   enableWindows: true
   windowsOsList:
     - version: 2019            # Human-readable version identifier
       imageTag: 2-windows-1809-alpha  # Tag to be used for nodes running the windows version above
       buildNumber: 10.0.17763         # Build number for your nodes running the version above. Used as a selector.
     - version: 20h2
       imageTag: 2-windows-20H2-alpha
       buildNumber: 10.0.19042
     - version: 2022
       imageTag: 2-windows-ltsc2022-alpha
       buildNumber: 10.0.20348
   nodeSelector:
     kubernetes.io/os: linux         # Selector for Linux installation.
   windowsNodeSelector:
     kubernetes.io/os: windows       # Selector for Windows installation.

   Copiar

7. Instale a integração com:

   bash

   Copiar

   $
   helm upgrade --install newrelic newrelic/newrelic-infrastructure \
   >
   --namespace newrelic --create-namespace \
   >
   --version 2.7.2 \
   >
   -f values-newrelic.yaml

8. Verifique se o pod está sendo implantado e atinge um estado estável:

   bash

   Copiar

   $
   kubectl -n newrelic get pods -w

   O 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 e ProcessSample não são gerados.
  • Algumas métricasKubernetes estão faltando porque o kubelet do Windows não as possui:

• Nó:

  • fsInodes: não enviado
  • fsInodesFree: não enviado
  • fsInodesUsed: não enviado
  • memoryMajorPageFaultsPerSecond: sempre retorna zero como valor
  • memoryPageFaults: sempre retorna zero como valor
  • memoryRssBytes: sempre retorna zero como valor
  • runtimeInodes: não enviado
  • runtimeInodesFree: não enviado
  • runtimeInodesUsed: não enviado

• Pod:

  • net.errorsPerSecond: não enviado
  • net.rxBytesPerSecond: não enviado
  • net.txBytesPerSecond: não enviado

• Contêiner:

  • containerID: não enviado
  • containerImageID: não enviado
  • memoryUsedBytes: 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 usar memoryWorkingSetBytes .

• Volume:

  • fsUsedBytes: zero, então fsUsedPercent é 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

  Copiar

  $
  error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": error calling kubelet endpoint. Got status code: 500

• Problema 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çãoTIMEOUT . Você pode ver se está sendo afetado por esse problema ativando o log detalhado e procurando mensagens do tipo:

  bash

  Copiar

  $
  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.

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:

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.

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:

• Injeção automática (recomendada)

• Injeção manual

  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 de Secrets, 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á:

1. Adicione um contêiner secundário ao pod que contém a integração do New Relic Kubernetes.

2. Se um segredo não existir, crie um no mesmo namespace do pod que contém a New Relic

   chave de licença

   , que é necessário para que o arquivo secundário relate dados.

3. 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:

   Copiar

• 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:
  
  <img
    title="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:
  
  ```shell
  helm repo add newrelic https://helm-charts.newrelic.com

  Copiar

  Entã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 values
  global:
    # -- 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 -- false
    privileged: true
  
    # -- (bool) Must be set to `true` when deploying in an EKS Fargate environment
    # @default -- false
    fargate: true
  
  ## Enable nri-bundle sub-charts
  
  newrelic-infra-operator:
    # Deploys the infrastructure operator, which injects the monitoring sidecar into Fargate pods
    enabled: true
    tolerations: 
    - key: "eks.amazonaws.com/compute-type"
      operator: "Equal"
      value: "fargate"
      effect: "NoSchedule"
    config:
      ignoreMutationErrors: true
      infraAgentInjection:
        # 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-b
  
  newrelic-infrastructure:
    # Deploys the Infrastructure Daemonset to EC2 nodes.  Disable for Fargate-only clusters.
    enabled: true
  
  nri-metadata-injection:
    # Deploy our mutating admission webhook to link APM and Kubernetes entities
    enabled: true
  
  kube-state-metrics:
    # Deploys Kube State Metrics.  Disable if you are already running KSM in your cluster.
    enabled: true
  
  nri-kube-events:
    # Deploy the Kubernetes events integration.
    enabled: true
  
  newrelic-logging:
    # Deploys the New Relic's Fluent Bit daemonset to EC2 nodes.  Disable for Fargate-only clusters.
    enabled: true
  
  newrelic-prometheus-agent:
    # Deploys the Prometheus agent for scraping Prometheus endpoints.
    enabled: true
    config:
      kubernetes:
        integrations_filter:
          enabled: true
          source_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"]

  Copiar

  Finalmente, depois de criar e ajustar o arquivo, você pode implantar a solução usando o seguinte comando do Helm:

  bash

  Copiar

  $
  helm upgrade --install newrelic-bundle newrelic/nri-bundle -n newrelic --create-namespace -f values.yaml

  Importante

  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ância DaemonSet é 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 um BatchJob.

  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

  Copiar

  $
  kubectl rollout restart deployment YOUR_APP

  Desinstale 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 como false, no arquivo values.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:

1. Desinstale completamente a versão do Helm.

2. Abra o pod para remover o sidecar:

   bash

   Copiar

   $
   kubectl rollout restart deployment YOUR_APP

3. Lixo colete os segredos:

   bash

   Copiar

   $
   kubectl delete secrets -n YOUR_NAMESPACE -l newrelic/infra-operator-created=true

   Limitações conhecidas: injeção automática

   Aqui estão alguns problemas que você deve estar ciente ao usar a injeção automática:

4. 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.

5. 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ção nri-kubernetes

• Um ClusterRoleBinding vinculando o ClusterRole e a conta de serviço do pod

• O segredo que armazena a New Relic licenseKey em cada namespaceFargate

• O 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:

1. 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.

   Função do Cluster

   Você pode usar este trecho conforme aparece abaixo, sem nenhuma alteração:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       app: newrelic-infrastructure
     name: newrelic-newrelic-infrastructure-infra-agent
   rules:
   - apiGroups:
     - ""
     resources:
     - nodes
     - nodes/metrics
     - nodes/stats
     - nodes/proxy
     - pods
     - services
     verbs:
     - get
     - list
   - nonResourceURLs:
     - /metrics
     verbs:
     - get

   Copiar

2. 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.

   ContainerToInject

   Pegue o contêiner do trecho a seguir e injete-o na workload que deseja monitor, especificando o nome do seu FargateProfile na variável customAttributes. Observe que os volumes podem ser definidos como emptyDir: {}.

   Dica

   No caso especial de uma implantação KSM, você também precisa remover a variável de ambiente DISABLE_KUBE_STATE_METRICS e aumentar as solicitações e limites de recursos.

   apiVersion: apps/v1
   kind: Deployment
   spec:
   template:
   spec:
   containers:
   - name: newrelic-infrastructure
     env:
     - name: NRIA_LICENSE_KEY
       valueFrom:
         secretKeyRef:
           key: license
           name: newrelic-newrelic-infrastructure-config
     - name: NRIA_VERBOSE
       value: "1"
     - name: DISABLE_KUBE_STATE_METRICS
       value: "true"
     - name: CLUSTER_NAME
       value: testing-injection
     - name: COMPUTE_TYPE
       value: serverless
     - name: NRK8S_NODE_NAME
       valueFrom:
         fieldRef:
           apiVersion: v1
           fieldPath: spec.nodeName
     - name: NRIA_DISPLAY_NAME
       valueFrom:
         fieldRef:
           apiVersion: v1
           fieldPath: spec.nodeName
     - name: NRIA_CUSTOM_ATTRIBUTES
       value: '{"clusterName":"$(CLUSTER_NAME)", "computeType":"$(COMPUTE_TYPE)", "fargateProfile":"[YOUR FARGATE PROFILE]"}'
     - name: NRIA_PASSTHROUGH_ENVIRONMENT
       value: KUBERNETES_SERVICE_HOST,KUBERNETES_SERVICE_PORT,CLUSTER_NAME,CADVISOR_PORT,NRK8S_NODE_NAME,KUBE_STATE_METRICS_URL,KUBE_STATE_METRICS_POD_LABEL,TIMEOUT,ETCD_TLS_SECRET_NAME,ETCD_TLS_SECRET_NAMESPACE,API_SERVER_SECURE_PORT,KUBE_STATE_METRICS_SCHEME,KUBE_STATE_METRICS_PORT,SCHEDULER_ENDPOINT_URL,ETCD_ENDPOINT_URL,CONTROLLER_MANAGER_ENDPOINT_URL,API_SERVER_ENDPOINT_URL,DISABLE_KUBE_STATE_METRICS,DISCOVERY_CACHE_TTL
     image: newrelic/infrastructure-k8s:2.4.0-unprivileged
     imagePullPolicy: IfNotPresent
     resources:
       limits:
         memory: 100M
         cpu: 200m
       requests:
         cpu: 100m
         memory: 50M
     securityContext:
       allowPrivilegeEscalation: false
       readOnlyRootFilesystem: true
       runAsUser: 1000
     terminationMessagePath: /dev/termination-log
     terminationMessagePolicy: File
     volumeMounts:
     - mountPath: /var/db/newrelic-infra/data
       name: tmpfs-data
     - mountPath: /var/db/newrelic-infra/user_data
       name: tmpfs-user-data
     - mountPath: /tmp
       name: tmpfs-tmp
     - mountPath: /var/cache/nr-kubernetes
       name: tmpfs-cache
   [...]

   Copiar

3. Crie um ClusterRoleBinding, ou adicione a um já criado o ServiceAccount do aplicativo que será monitorado. Toda a carga de trabalho pode compartilhar o mesmo ClusterRoleBinding, mas o ServiceAccount de cada uma deve ser adicionado a ela.

   ClusterRoleBinding

   Crie o seguinte ClusterRoleBinding que tenha como assuntos a conta de serviço do pod que você deseja monitor.

   Dica

   Você não precisa repetir a mesma conta de serviço duas vezes. Cada vez que você quiser monitor um pod com uma conta de serviço que ainda não esteja incluída, basta adicioná-lo à lista.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: newrelic-newrelic-infrastructure-infra-agent
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: newrelic-newrelic-infrastructure-infra-agent
   subjects:
   - kind: ServiceAccount
     name: [INSERT_SERVICE_ACCOUNT_NAME_OF_WORKLOAD]
     namespace: [INSERT_SERVICE_ACCOUNT_NAMESPACE_OF_WORKLOAD]

   Copiar

4. Crie um segredo contendo a New Relic chave de licença. Cada namespace precisa de seu próprio segredo.

   Segredo

   Crie o seguinte Secret que tenha uma licença com o valor codificado em Base64 do seu chave de licença. É necessário um segredo em cada namespace onde um pod que você deseja monitor está em execução.

   apiVersion: v1
   data:
     license: INSERT_YOUR_NEW_RELIC_LICENSE_ENCODED_IN_BASE64
     kind: Secret
   metadata:
     name: newrelic-newrelic-infrastructure-config
     namespace: [INSERT_NAMESPACE_OF_WORKLOAD]
     type: Opaque

   Copiar

   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 chave de licença. 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 e ClusterRoleBinding 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 regras nodeAffinity não estão configuradas corretamente.

  Verifique novamente se a solução foi instalada com a opção global.fargate para true, por meio da linha de comando (--set global.fargate=true) ou no arquivo values.yaml . Se o método de instalação não for Helm, você precisará adicionar manualmente nodeAffinity regras para excluir nós do Fargate.

  Evento FailedScheduling devido a contaminação não tolerada

  Lembre-se de adicionar no arquivo values.yaml o tolerations 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..

  Copiar

  Evento FailedScheduling devido a muitos pods

  Verifique 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..

  Copiar

  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:

1. 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.

2. 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:

1. 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.

2. 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.

   Inicie o instalador

   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 chave de licençae do nome do cluster do Kubernetes:

3. Encontre e copie seu chave de licença.

4. Escolha um nome de exibição para seu cluster. Por exemplo, você poderia usar a saída de:

   bash

   Copiar

   $
   kubectl config current-context

   Importante

   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 (como kubectl 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 um MutatingAdmissionWebhook 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

1. 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

   Copiar

   $
   kubectl config get-contexts

   E mude para o contexto desejado usando:

   bash

   Copiar

   $
   kubectl config use-context _CONTEXT_NAME_

2. Adicione o repositório de gráficos do New Relic Helm:

   bash

   Copiar

   $
   helm repo add newrelic https://helm-charts.newrelic.com

3. Crie 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 significantly
     enabled: true
   nri-metadata-injection:
     # Deploy our webhook to link APM and Kubernetes entities
     enabled: true
   nri-kube-events:
     # Report Kubernetes events
     enabled: true
   newrelic-logging:
     # Report logs for containers running in the cluster
     enabled: true
   kube-state-metrics:
     # Deploy kube-state-metrics in the cluster.
     # Set this to true unless it is already deployed.
     enabled: true

   Copiar

4. Certifique-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

   Copiar

   $
   helm upgrade --install newrelic-bundle newrelic/nri-bundle \
   >
   --namespace newrelic --create-namespace \
   >
   -f values-newrelic.yaml \
   >
   --dry-run \
   >
   --debug

   Observe e ajuste os seguintes sinalizadores:

   • global.licenseKey=YOUR_NEW_RELIC_LICENSE_KEY: deve ser definido como um

     chave de licença

     vá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 como true 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.

5. Instale a integração do Kubernetes executando o comando sem --debug e --dry-run:

   bash

   Copiar

   $
   helm upgrade --install newrelic-bundle newrelic/nri-bundle \
   >
   --namespace newrelic --create-namespace \
   >
   -f values-newrelic.yaml

   Importante

   Verifique se você está usando o Kubernetes versão 1.27.x ou uma versão inferior compatível com.

6. Verifique se o pod está sendo implantado e atinge um estado estável:

   bash

   Copiar

   $
   kubectl -n newrelic get pods -w

   Você 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?

  Deixe um comentário.

  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áfico newrelic-infrastructure , você adicionaria o seguinte ao values-newrelic.yaml:

  # General settings that apply to all the child charts
  global:
    licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
    cluster: _K8S_CLUSTER_NAME_
  
  # ... Other settings as shown above
  
  # Specific configuration for the newrelic-infrastructure child chart
  newrelic-infrastructure:
    verboseLog: true  # Enable debug logs
    privileged: 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 chart
  newrelic-logging:
    fluentBit:
    retryLimit: 10

  Copiar

  Você 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=10

  Copiar

  A lista completa de flags que você pode ajustar (como scrape-interval) para cada gráfico filho pode ser encontrada em seus respectivos repositórios:

• newrelic-infrastructure

• Configurar log de depuração, modo de privilégio, monitoramento do plano de controle, etc.

• nri-kube-events

• nri-metadata-injection

• Configure como o webhook para ligação APM é implantado.

• Configure quais endpoints do Prometheus serão copiados.

• newrelic-logging

• 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

  Instalação guiada (recomendada)

  Você pode instalar no piloto automático do GKE usando o mesmo fluxo de instalação da nossa guia de instalação guiada .

  Leme manual

  Seu comando completo do Helm deve ser semelhante ao seguinte:

  bash

  Copiar

  $
  KSM_IMAGE_VERSION="v2.10.0" && \
  >
  helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && \
  >
  kubectl create namespace newrelic ; helm upgrade --install newrelic-bundle newrelic/nri-bundle \
  >
  --set global.licenseKey=<Your License Key> \
  >
  --set global.cluster=<Your Cluster Name> \
  >
  --namespace=newrelic \
  >
  --set newrelic-infrastructure.privileged=false \
  >
  --set newrelic-infrastructure.controlPlane.enabled=false \
  >
  --set newrelic-infrastructure.kubelet.config.scheme=http \
  >
  --set newrelic-infrastructure.kubelet.config.port=10255 \
  >
  --set global.lowDataMode=true \
  >
  --set kube-state-metrics.image.tag=${KSM_IMAGE_VERSION} \
  >
  --set kube-state-metrics.enabled=true \
  >
  --set kubeEvents.enabled=true \
  >
  --set newrelic-prometheus-agent.enabled=true \
  >
  --set newrelic-prometheus-agent.lowDataMode=true \
  >
  --set newrelic-prometheus-agent.config.kubernetes.integrations_filter.enabled=false \
  >
  --set newrelic-pixie.enabled=false
  $
  --set logging.enabled=true 
  $
  --set newrelic-logging.lowDataMode=true 
  $
  --set newrelic-logging.fluentBit.linuxMountPath=/var/log  
  $
  --set newrelic-logging.fluentBit.persistence.mode=persistentVolume 
  $
  --set newrelic-logging.fluentBit.persistence.persistentVolume.storageClass=standard-rwx

  O Fluent Bit pode usar um volume FileStore para evitar perda de dados ou log duplicado durante reinicializações ou reimplantações pod do Fluent Bit. O uso do FileStore acarreta custos adicionais, cobrados pelo Google. Recomendamos consultar seu administrador do Google Cloud ou visitar a documentação do FileStore para obter detalhes. A API Google FileStore precisa estar ativada no seu projeto do GKE. Verifique este documento para saber mais sobre como ativar API.

  Se você não quiser usar o FileStore, adicione o seguinte:

  • Defina "newrelic-logging.fluentBit.persistence.mode" como "none"
  • Remover "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass"

  Verifique nossos documentos do gráfico Helm para obter mais informações.

  Manifesto

  Atualize seu comando de manifesto com os seguintes sinalizadores:

  • Defina "newrelic-infrastructure.privileged", "newrelic-infrastructure.controlPlane.enabled" como false.

  • Adicionar "newrelic-infrastructure.kubelet.config.scheme":"http"

  • Adicionar "newrelic-infrastructure.kubelet.config.port":"10255"

  • Adicionar "logging.enabled":"true"

  • Adicionar "newrelic-logging.lowDataMode":"true"

  • Adicionar "newrelic-logging.fluentBit.linuxMountPath":"/var/log"

  • Adicionar "newrelic-logging.fluentBit.persistence.mode":"persistentVolume"

  • Adicionar "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass":"standard-rwx"

  • Remova o Pixie carga do comando, pois o Pixie não é compatível no momento com o GKE Autopilot.

    O Fluent Bit pode usar um volume FileStore para evitar perda de dados ou log duplicado durante reinicializações ou reimplantações pod do Fluent Bit. O uso do FileStore acarreta custos adicionais, cobrados pelo Google. Recomendamos consultar seu administrador do Google Cloud ou visitar a documentação do FileStore para obter detalhes. A API Google FileStore precisa estar ativada no seu projeto do GKE. Verifique este documento para saber mais sobre como ativar API.

    Se você não quiser usar o FileStore, adicione o seguinte:

  • Defina "newrelic-logging.fluentBit.persistence.mode" como "none"

  • Remover "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass"

    Aqui está um comando que cria um arquivo de manifesto e o aplica ao cluster:

    bash

    Copiar

    $
    KSM_IMAGE_VERSION="v2.10.0" && \
    >
    curl -X POST https://k8s-config-generator.service.newrelic.com/generate -H 'Content-Type: application/json' -d '{"global.cluster":"<Your Cluster Name>","global.namespace":"newrelic","newrelic-infrastructure.privileged":"false","newrelic-infrastructure.controlPlane.enabled":"false","newrelic-infrastructure.kubelet.config.scheme":"http","newrelic-infrastructure.kubelet.config.port":"10255","global.lowDataMode":"true","kube-state-metrics.image.tag":"'${KSM_IMAGE_VERSION}'","kube-state-metrics.enabled":"true","kubeEvents.enabled":"true","newrelic-prometheus-agent.enabled":"true","newrelic-prometheus-agent.lowDataMode":"true","newrelic-prometheus-agent.config.kubernetes.integrations_filter.enabled":"false","logging.enabled":"true", "newrelic-logging.lowDataMode":"true", "newrelic-logging.fluentBit.linuxMountPath":"/var/log", "newrelic-logging.fluentBit.persistence.mode":"persistentVolume", "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass":"standard-rwx","global.licenseKey":"<Your License Key"}'  > newrelic.yaml && (kubectl create namespace newrelic ; kubectl apply -f newrelic.yaml)