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 conectar seu aplicativo ao Kubernetes, você precisa ser capaz de implantar `MutatingWebhookConfiguration' em seu cluster do Kubernetes.

Para verificar se você tem as permissões necessárias, execute este comando:

bash

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

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

bash

$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ó do plano de controle (ou contêiner do servidor API , dependendo de como o cluster está configurado) deve permitir a saída do tráfego HTTPS na porta 443 para o pod em todos os outros nós do cluster.

Isso pode exigir configuração específica dependendo de como sua 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

Quando você instala nossa integração usando Helm, ela inclui injeção de metadados. Ao configurar o gráfico nri-bundle , certifique-se de ativar o webhook de injeção de metadados da seguinte maneira.

nri-metadata-injection:
    enabled: true

Após implantar o webhook, reinicie seu aplicativo pod. Eles precisam selecionar 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 para obter mais informações.

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 usá-lo, o que pode tornar a implantação muito mais fácil:

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 certificado e par de chaves estiverem 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

implantar um novo pod e verificar as variáveis de ambiente do New Relic para verificar a correta instalação do webhook responsável por injetar os metadados.

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 desinstalar a injeção de metadados, altere seu arquivo values-newrelic.yaml da seguinte forma:

webhook:
    enabled: false

Depois disso, 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.
Verifique se o segredo foi criado corretamente e se o pod k8s-metadata-injection foi 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 configuradas corretamente e injetadas seguindo as instruções descritas na seção Validar a injeção de metadados .

Se eles não existirem, 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 e inspecione o log da implantação de metadados em busca de erros. Consulte a seção Validar a injeção de metadados para criar um novo pod. 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 servidor API não consegue 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 servidor API não consegue se comunicar com o webhook, você deve inspecionar o log do servidor API em busca de erros como:
bash
```
$failed calling webhook "metadata-injection.newrelic.com": THE_ERROR_REASON
```
Para obter o log do servidor API :
Inicie um proxy para o servidor API Kubernetes executando este comando em uma janela de terminal e mantenha-o em execução.
bash
```
$kubectl proxy --port=8001
```
Crie um novo pod em seu cluster, isso fará com que o servidor API tente se comunicar com o webhook. Este comando criará um busybox.
bash
```
$kubectl create -f https://git.io/vPieo
```

Recuperar o log do servidor API .

bash

$curl localhost:8001/logs/kube-apiserver.log > apiserver.log

Exclua o contêiner do busybox.
bash
```
$kubectl delete -f https://git.io/vPieo
```
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 servidor API 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 servidor API 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 da injeção de metadados foi executado com êxito inspecionando a saída deste comando:
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 este comando:
bash
```
$kubectl get csr newrelic-metadata-injection-svc.default
```
Certifique-se de que o segredo TLS esteja presente executando este comando:
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 na transação atributo

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 na transação atributo

Compatibilidade e requisitos