• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

instalação no AWS EKS Fargate

visualização

Ainda estamos trabalhando nesse recurso, mas adoraríamos que você experimentasse!

Atualmente, esse recurso é fornecido como parte de um programa de visualização de acordo com nossas políticas de pré-lançamento.

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.

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

    , 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:

- apiGroups: [""]
resources:
- "nodes"
- "nodes/metrics"
- "nodes/stats"
- "nodes/proxy"
- "pods"
- "services"
- "namespaces"
verbs: ["get", "list"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]

Dica

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.

Importante

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

Aqui está o fluxo de trabalho de injeção:

Dica

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 abaixo para ver se deseja modificar algum aspecto da injeção automática.

Adicione o repositório New Relic Helm

Caso ainda não tenha feito isso, execute este comando para adicionar o repositório do New Relic Helm:

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

Crie um arquivo chamado values.yaml

Para instalar o operador responsável por injetar o sidecar da infraestrutura, crie um arquivo chamado values.yaml. Este arquivo 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"]

Implantar

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

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

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

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

  1. 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.
  2. 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 automática: 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
$
kubectl rollout restart deployment YOUR_APP

Injeção automática: Desinstalar

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
    $
    kubectl rollout restart deployment YOUR_APP
  3. Lixo colete os segredos:

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

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

Estes 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 namespace Fargate.
  • O contêiner sidecar no template específico da workload do monitor.

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.

Conclua estas etapas para injeção manual:

ClusterRole

Se ClusterRole não existir, crie-o e conceda as permissões necessárias para atingir o endpoint métrico. Você só precisa fazer isso uma vez, mesmo para monitoramento de vários aplicativos no mesmo 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

Carro lateral injetado

Para cada workload que você deseja monitor, adicione um contêiner secundário adicional para a imagem newrelic/infrastructure-k8s. 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
[...]

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.

ClusterRoleBinding

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.

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]

Segredo contendo

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

Crie o seguinte Secret que tenha uma licença com o valor codificado em Base64 do seu . É 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

Injeção manual: 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.

Injeção manual: Desinstale a integração 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:

Resolução de problemas

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]
Copyright © 2024 New Relic Inc.

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