Vincular aplicativo APM-instrumentado ao Kubernetes

Você pode exibir metadados Kubernetes e vinculá-los ao seu agente APM como rastreamento distribuído para explorar problemas de desempenho e solucionar erros de operação. Para obter mais informações, consulte esta postagem do blog sobre monitoramento de desempenho de aplicativos via Kubernetes.

O produto metadados injeção usa um MutatingAdmissionWebhook para adicionar as seguintes variáveis de ambiente ao pod:

NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME
NEW_RELIC_METADATA_KUBERNETES_NODE_NAME
NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME
NEW_RELIC_METADATA_KUBERNETES_DEPLOYMENT_NAME
NEW_RELIC_METADATA_KUBERNETES_POD_NAME
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_IMAGE_NAME

Dica

Nosso projeto de injeção de metadados do Kubernetes é de código aberto. Aqui está o código para vincular o APM e os dados de infraestrutura.

Compatibilidade e requisitos

Para vincular seu aplicativo e Kubernetes, você deve ser capaz de implantar MutatingWebhookConfigurations em seu cluster do Kubernetes.

Para verificar se você tem as permissões necessárias, você pode executar o seguinte comando:

bash

$kubectl auth can-i create mutatingwebhookconfigurations.admissionregistration.k8s.io -A

A saída do comando acima deve ser algo semelhante a:

yes

Se você vir um resultado diferente, siga a documentação do Kubernetes para habilitar o controle de admissão em seu cluster.

Requisitos de rede

Para que Kubernetes se comunique com nosso MutatingAdmissionWebhook, o nó mestre (ou o contêiner do servidor API , dependendo de como o cluster está configurado) deve ter permissão de saída para tráfego HTTPS na porta 443 para pod em todos os outros nós do cluster.

Isso pode exigir configuração específica dependendo de como a infraestrutura está configurada (local, AWS, Google Cloud, etc.).

Compatibilidade APM do agente

O seguinte agente New Relic coleta metadados Kubernetes :

Configure a injeção de metadados

A injeção de metadados está incluída quando você instala nossa integração usando Helm. Apenas certifique-se de que, ao configurar o gráfico nri-bundle , o webhook que injeta os metadados esteja ativado:

nri-metadata-injection:
  enabled: true

Seu pod de aplicativo precisará ser reiniciado após a implantação do webhook, para que eles possam coletar as variáveis de ambiente necessárias.

Por padrão, todos os pods criados que incluem o agente APM têm as variáveis de ambiente corretas definidas e a injeção de metadados se aplica a todo o cluster. Para verificar se as variáveis de ambiente foram definidas, qualquer contêiner em execução deve ser interrompido e uma nova instância iniciada (consulte Validar a injeção de metadados).

Essa configuração padrão também usa a API de certificados Kubernetes para gerenciar automaticamente os certificados necessários para a injeção. Se necessário, você pode limitar a injeção de metadados a namespaces específicos em seu cluster ou autogerenciar seus certificados.

Configuração personalizada

Limitar namespace sujeito a injeção

Você pode limitar a injeção de metadados apenas a namespaces específicos usando rótulos.

Para ativar esse recurso, adicione o seguinte ao arquivo values-newrelic.yaml :

nri-metadata-injection:
  injectOnlyLabeledNamespaces: true

Com esta opção, a injeção é aplicada apenas aos namespaces que possuem o rótulo newrelic-metadata-injection definido como enabled:

bash

$kubectl label namespace YOUR_NAMESPACE newrelic-metadata-injection=enabled

Use o cert-manager para gerar certificados

Por padrão, nosso gráfico usa kube-webhook-certgen para gerar automaticamente os certificados necessários para a execução do webhook.

No entanto, se você tiver o cert-manager instalado, poderá configurar nosso gráfico para usar o cert-manager, o que pode simplificar significativamente o processo de implantação:

nri-metadata-injection:
  certManager:
    enabled: true

Gerenciar certificados personalizados

Dica

O gerenciamento manual de certificados de webhook é recomendado apenas para usuários avançados. A equipe de suporte New Relic pode não ser capaz de ajudar na resolução de problemas nesta configuração.

Para usar certificados personalizados, você precisa desabilitar a instalação automática de certificados ao instalar usando o Helm.

Para desativar a instalação de certificados, basta modificar o Helm nri-bundle values.yaml assim:

nri-metadata-injection:
  customTLSCertificate: true

Agora você pode prosseguir com a opção de gerenciamento de certificado personalizado.

Você precisa do certificado, da chave do servidor e do pacote da Autoridade de Certificação (CA) codificados no formato PEM.

Se você os tiver no formato de certificado padrão (X.509), instale openssl e execute o seguinte:

bash

$openssl x509 -in YOUR_CERTIFICATE_FILENAME -outform PEM -out YOUR_CERTIFICATE_FILENAME.pem
$openssl x509 -in YOUR_SERVER_KEY_FILENAME -outform PEM -out YOUR_SERVER_KEY_FILENAME.pem 
$openssl x509 -in YOUR_CA_BUNDLE_FILENAME -outform PEM -out YOUR_BUNDLE_FILENAME.pem

Se o seu par de certificado/chave estiver em outro formato, consulte a base de conhecimento da Digicert para obter mais ajuda.

Crie o segredo TLS com o par de certificado/chave assinado e corrija a configuração mutante do webhook com a CA usando os seguintes comandos:

bash

$kubectl create secret tls YOUR_NEWRELIC_METADATA_INJECTION_ADMISSION \
>  --key=YOUR_PEM_ENCODED_SERVER_KEY \
>  --cert=YOUR_PEM_ENCODED_CERTIFICATE \
>  --dry-run -o yaml |
$kubectl -n newrelic apply -f -
$
$caBundle=$(cat YOUR_PEM_ENCODED_CA_BUNDLE | base64 | td -d $'\n')
$kubectl patch mutatingwebhookconfiguration newrelic-metadata-injection-cfg --type='json' -p "[{'op': 'replace', 'path': '/webhooks/0/clientConfig/caBundle', 'value':'${caBundle}'}]"

Importante

Os certificados assinados pelo Kubernetes têm validade de um ano. Para obter mais informações, consulte o código-fonte do Kubernetes no GitHub.

Validar a injeção de metadados

Para validar se o webhook (responsável por injetar os metadados) foi instalado corretamente, implante um novo pod e verifique as variáveis de ambiente New Relic .

Crie um pod nginx fictício executando:

bash

$kubectl run test-nginx --image nginx -n newrelic

Verifique se as variáveis de ambiente do New Relic foram injetadas:

bash

$kubectl exec -n newrelic test-nginx -- env | grep NEW_RELIC_METADATA_KUBERNETES

A saída esperada seria algo como o seguinte:

NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME=THE_CLUSTER_NAME
NEW_RELIC_METADATA_KUBERNETES_NODE_NAME=nodea
NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME=newrelic
NEW_RELIC_METADATA_KUBERNETES_POD_NAME=test-nginx
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME=nginx

Desative a injeção de metadados

Para desativar/desinstalar a injeção de metadados, altere seu arquivo values-newrelic.yaml da seguinte forma:

webhook:
  enabled: false

E execute novamente o comando de instalação.

Resolução de problemas

Siga estas dicas de resolução de problemas conforme necessário.

Problema

A criação do segredo pelo trabalho k8s-webhook-cert-manager falhava devido à versão kubectl usada pela imagem ao executar no Kubernetes versão 1.19.x, A nova versão 1.3.2 corrige esse problema, portanto basta executar novamente o job usando uma versão atualizada da imagem para corrigir o problema.

Solução

Atualize a imagem k8s-webhook-cert-manager (para uma versão >= 1.3.2) e execute novamente a tarefa.
O segredo será criado corretamente e o pod k8s-metadata-injection poderá ser iniciado.
Observe que a nova versão do manifesto e do nri-bundle já está atualizada com a versão correta da imagem.

Problema

Não há metadados Kubernetes incluídos no atributo de transação do seu agente APM ou no distributed tracing.

Solução

Verifique se as variáveis de ambiente estão sendo injetadas corretamente seguindo as instruções descritas na etapa Validar sua instalação .
Se eles não estiverem presentes, obtenha o nome do pod de injeção de metadados executando:
bash
```
$kubectl get pods | grep newrelic-metadata-injection-deployment
$kubectl logs -f pod/my-pod
```

Em outro terminal, crie um novo pod (por exemplo, consulte Validar sua instalação) e inspecione o log da implantação de metadados em busca de erros. Para cada pod criado deve haver um conjunto de 4 novas entradas no log como:

{"level":"info","ts":"2020-04-09T12:55:32.107Z","caller":"server/main.go:139","msg":"POST https://newrelic-metadata-injection-svc.default.svc:443/mutate?timeout=30s HTTP/2.0\" from 10.11.49.2:32836"}
{"level":"info","ts":"2020-04-09T12:55:32.110Z","caller":"server/webhook.go:168","msg":"received admission review","kind":"/v1, Kind=Pod","namespace":"default","name":"","pod":"busybox1","UID":"6577519b-7a61-11ea-965e-0e46d1c9335c","operation":"CREATE","userinfo":{"username":"admin","uid":"admin","groups":["system:masters","system:authenticated"]}}
{"level":"info","ts":"2020-04-09T12:55:32.111Z","caller":"server/webhook.go:182","msg":"admission response created","response":"[{\"op\":\"add\",\"path\":\"/spec/containers/0/env\",\"value\":[{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME\",\"value\":\"adn_kops\"}]},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_NODE_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"spec.nodeName\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.namespace\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_POD_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.name\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME\",\"value\":\"busybox\"}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CONTAINER_IMAGE_NAME\",\"value\":\"busybox\"}}]"}
{"level":"info","ts":"2020-04-09T12:55:32.111Z","caller":"server/webhook.go:257","msg":"writing response"}

Se não houver novas entradas no log, significa que o apiserver não está conseguindo se comunicar com o serviço webhook, isso pode ser devido a regras de rede ou grupos de segurança rejeitando a comunicação.

Para verificar se o apiserver não está conseguindo se comunicar com o webhook, você deve inspecionar o log do apiserver em busca de erros como:
```
failed calling webhook "metadata-injection.newrelic.com": THE_ERROR_REASON
```
Para obter o log do apiserver:
1. Inicie um proxy para o servidor API Kubernetes executando o seguinte comando em uma janela de terminal e mantenha-o em execução.
  bash
```
$kubectl proxy --port=8001
```
2. Crie um novo pod no seu cluster, isso fará com que o apiserver tente se comunicar com o webhook. O comando a seguir criará um busybox.
  bash
```
$kubectl create -f https://git.io/vPieo
```
3. Recupere o log do apiserver.
  bash
```
$curl localhost:8001/logs/kube-apiserver.log > apiserver.log
```
4. Exclua o contêiner do busybox.
  bash
```
$kubectl delete -f https://git.io/vPieo
```
5. Inspecione o log em busca de erros.
  bash
```
$grep -E 'failed calling webhook' apiserver.log
```
  Dica
  Um dos requisitos para a injeção de metadados é que o apiserver tenha permissão de saída para o pod em execução no cluster. Se você encontrar erros relacionados a tempos limite de conexão ou falhas de conexão, verifique os grupos de segurança e as regras de firewall do cluster.
Se não houver entradas log no log do apiserver ou nos metadados de inserção de implantação, significa que o webhook não foi registrado corretamente.
Certifique-se de que o trabalho de configuração de injeção de metadados foi executado com êxito inspecionando a saída de:
bash
```
$kubectl get job newrelic-metadata-setup
```
Se o trabalho não for concluído, investigue o log do trabalho de configuração:
bash
```
$kubectl logs job/newrelic-metadata-setup
```
Certifique-se de que CertificateSigningRequest seja aprovado e emitido executando:
bash
```
$kubectl get csr newrelic-metadata-injection-svc.default
```
Certifique-se de que o segredo TLS esteja presente executando:
bash
```
$kubectl get secret newrelic-metadata-injection-secret
```
Certifique-se de que o pacote CA esteja presente na configuração do webhook mutante:
bash
```
$kubectl get mutatingwebhookconfiguration newrelic-metadata-injection-cfg -o json
```

Certifique-se de que o TargetPort do recurso Service corresponda ao Port do contêiner do Deployment:

bash

$kubectl describe service/newrelic-metadata-injection-svc
$kubectl describe deployment/newrelic-metadata-injection-deployment

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

Vincular aplicativo APM-instrumentado ao Kubernetes

Dica

Compatibilidade e requisitos

Requisitos de rede

Compatibilidade APM do agente

Configure a injeção de metadados

Configuração personalizada

Limitar namespace sujeito a injeção

Use o cert-manager para gerar certificados

Gerenciar certificados personalizados

Dica

Importante

Validar a injeção de metadados

Desative a injeção de metadados

Resolução de problemas

Não há metadados Kubernetes no APM ou transação distributed tracing

Problema

Solução

Não há metadados Kubernetes no atributo da transação

Problema

Solução

Dica

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

Vincular aplicativo APM-instrumentado ao Kubernetes

Dica

Compatibilidade e requisitos .css-21sua1{background:none;border:none;width:0;padding:0;}

Requisitos de rede

Compatibilidade APM do agente

Configure a injeção de metadados

Configuração personalizada

Limitar namespace sujeito a injeção

Use o cert-manager para gerar certificados

Gerenciar certificados personalizados

Dica

Importante

Validar a injeção de metadados

Desative a injeção de metadados

Resolução de problemas

Não há metadados Kubernetes no atributo da transação

Compatibilidade e requisitos