instalação no AWS EKS Fargate

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.

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:

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

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

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

## 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"]

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

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.

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:

$
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

   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

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.

Conclua estas etapas para injeção manual:

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

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
[...]

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]

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.

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:

• 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

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

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:

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]