Lier les applications instrumentées APM à Kubernetes

Vous pouvez faire apparaître les métadonnées Kubernetes et les lier à vos agents APM sous forme de traces distribuées pour explorer les problèmes de performances et résoudre les erreurs de transaction. Pour plus d'informations, consultez cet article de blog sur le monitoring des performances des applications via Kubernetes.

Le produit injection métadonnée utilise un MutatingAdmissionWebhook pour ajouter les variables d'environnement suivantes au 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

Conseil

Notre projet d'injection de métadonnées Kubernetes est open source. Voici le code pour lier les données APM et d'infrastructure.

Compatibilité et exigences

Pour connecter vos applications à Kubernetes, vous devez pouvoir déployer « MutatingWebhookConfiguration » sur votre cluster Kubernetes.

Pour vérifier que vous disposez des autorisations requises, exécutez cette commande :

bash

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

Le résultat de la commande ci-dessus devrait ressembler à :

bash

$yes

Si vous voyez un résultat différent, suivez la documentation Kubernetes pour activer le contrôle d'admission dans votre cluster.

Exigences réseau

Pour que Kubernetes puisse communiquer avec notre MutatingAdmissionWebhook, le nœud control plane (ou le conteneur du serveur API, selon la configuration du cluster ) doit autoriser la sortie du trafic HTTPS sur le port 443 vers le pod de tous les autres nœuds du cluster.

Cela peut nécessiter une configuration spécifique en fonction de la configuration de votre infrastructure (sur site, AWS, Google Cloud, etc.).

Compatibilité de l'agent APM

Les agents New Relic suivants collectent les métadonnées Kubernetes :

Configurer l'injection de métadonnées

Lorsque vous installez notre intégration à l’aide de Helm, elle inclut l’injection de métadonnées. Lors de la configuration du graphique nri-bundle , assurez-vous d'activer le webhook d'injection de métadonnées comme suit.

nri-metadata-injection:
    enabled: true

Important : votre pod d'application devra être redémarré après le déploiement de nri-metadata-injection, afin qu'il puisse récupérer les variables d'environnement nécessaires.

Par défaut, tous les pods que vous créez qui incluent des agents APM ont les variables d'environnement correctes définies et l' injection de métadonnées s'applique à l'ensemble cluster. Pour vérifier que les variables d'environnement ont été définies, tout conteneur en cours d'exécution doit être arrêté et une nouvelle instance démarrée. Voir Valider l'injection de métadonnées pour plus d'informations.

Cette configuration par défaut utilise également l' API des certificats Kubernetes pour gérer automatiquement les certificats requis pour l'injection. Si besoin, vous pouvez limiter l' injection de métadonnées à un espace de nommage spécifique de votre cluster ou autogérer vos certificats.

Configuration personnalisée

Limiter l'espace de nommage soumis à injection

Vous pouvez limiter l' injection de métadonnées uniquement à un espace de nommage spécifique en utilisant des étiquettes.

Pour activer cette fonctionnalité, ajoutez ce qui suit au fichier values-newrelic.yaml :

nri-metadata-injection:
    injectOnlyLabeledNamespaces: true

Avec cette option, injection est uniquement appliquée aux espaces de nommage dont l'étiquette newrelic-metadata-injection est définie sur enabled:

bash

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

Utilisez cert-manager pour générer des certificats

Par défaut, notre graphique utilise kube-webhook-certgen pour générer automatiquement les certificats requis pour l'exécution du webhook.

Cependant, si vous avez installé cert-manager , vous pouvez configurer notre graphique pour l'utiliser à la place, ce qui peut rendre le déploiement beaucoup plus facile :

nri-metadata-injection:
  certManager:
    enabled: true

Gérer les certificats personnalisés

Conseil

La gestion manuelle des certificats webhook est recommandée uniquement aux utilisateurs avancés. L'équipe d'assistance de New Relic ne pourra peut-être pas vous aider à résoudre ce configuration.

Pour utiliser des certificats personnalisés, vous devez désactiver l'installation automatique des certificats lorsque vous effectuez l'installation à l'aide de Helm.

Pour désactiver l'installation des certificats, modifiez simplement nri-bundle Helm values.yaml comme ceci :

nri-metadata-injection:
  customTLSCertificate: true

Vous pouvez maintenant procéder à l’option de gestion des certificats personnalisés. Vous avez besoin de votre certificat, de votre clé de serveur et de votre ensemble d'autorité de certification (CA) codés au format PEM.

Si vous les avez au format de certificat standard (X.509), installez openssl et exécutez ce qui suit :

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

Si votre certificat et votre paire de clés sont dans un autre format, consultez la base de connaissances Digicert pour obtenir de l'aide.

Créez le secret TLS avec la paire certificat/clé signée et corrigez la configuration du webhook en mutation avec l'autorité de certification à l'aide des commandes suivantes :

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}'}]"

Important

Les certificats signés par Kubernetes ont une durée d'expiration d'un an. Pour plus d'informations, consultez le code source de Kubernetes sur GitHub.

Valider l'injection de métadonnées

lancer un nouveau pod et vérifier les variables d'environnement New Relic pour vérifier la bonne installation du webhook responsable de l'injection du fichier méta.

Créez un pod nginx factice en exécutant :
bash
```
$kubectl run test-nginx --image nginx -n newrelic
```
Vérifiez si les variables d’environnement New Relic ont été injectées :
bash
```
$kubectl exec -n newrelic test-nginx -- env | grep NEW_RELIC_METADATA_KUBERNETES
```

Le résultat attendu serait quelque chose comme ce qui suit :

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

Désactiver l'injection de métadonnées

Pour désinstaller l'injection de métadonnées, modifiez votre fichier values-newrelic.yaml comme suit :

webhook:
    enabled: false

Après cela, exécutez à nouveau la commande d’installation.

Dépannage

Suivez ces conseils de dépannage si nécessaire.

Problème

La création du secret par la tâche k8s-webhook-cert-manager échouait en raison de la version kubectl utilisée par l'image lors de l'exécution dans Kubernetes version 1.19.x, La nouvelle version 1.3.2 corrige ce problème, il suffit donc de réexécuter le travail en utilisant une version de mise à jour de l'image pour résoudre le problème.

Solution

Mettez à jour l'image k8s-webhook-cert-manager vers une version >= 1.3.2 et réexécutez le travail.
Vérifiez que le secret a été créé correctement et que le pod k8s-metadata-injection démarre.
Notez que la nouvelle version du manifeste et du nri-bundle sont déjà mises à jour avec la version correcte de l'image.

Problème

Aucune métadonnées Kubernetes n'est incluse dans l'attribut de transaction de votre agent APM ou dans le tracing distribué.

Solution

Vérifiez que les variables d'environnement injectées sont correctement définies en suivant les instructions décrites dans la section Valider l'injection des métadonnées .
S'ils n'existent pas, récupérez le nom du pod d'injection de métadonnées en exécutant :
bash
```
$kubectl get pods | grep newrelic-metadata-injection-deployment
$kubectl logs -f pod/my-pod
```

Dans un autre terminal, créez un nouveau pod et inspectez le log du déploiement de l' injection de métadonnées pour détecter les erreurs. Voir la section Valider l’injection de métadonnées pour créer un nouveau pod. Pour chaque pod créé, il devrait y avoir un ensemble de 4 nouvelles entrées dans le log, telles que :

{"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"}

S'il n'y a pas de nouvelles entrées dans le log, cela signifie que le serveur API ne peut pas communiquer avec le service webhook, cela peut être dû à des règles réseau ou à des groupes de sécurité rejetant la communication.

Pour vérifier si le serveur API ne parvient pas à communiquer avec le webhook, vous devez inspecter le log du serveur API pour rechercher des erreurs telles que :
bash
```
$failed calling webhook "metadata-injection.newrelic.com": THE_ERROR_REASON
```
Pour obtenir le log du serveur API :
Démarrez un proxy vers le serveur API Kubernetes en exécutant cette commande dans une fenêtre de terminal et maintenez-le en cours d'exécution.
bash
```
$kubectl proxy --port=8001
```
Créez un nouveau pod dans votre cluster, cela obligera le serveur API à essayer de communiquer avec le webhook. Cette commande créera une busybox.
bash
```
$kubectl create -f https://git.io/vPieo
```

Récupérer le log du serveur API.

bash

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

Supprimez le conteneur busybox.
bash
```
$kubectl delete -f https://git.io/vPieo
```
Inspectez le log pour détecter les erreurs.
bash
```
$grep -E 'failed calling webhook' apiserver.log
```
Conseil
L’une des exigences pour l’ injectionde métadonnées est que le serveur API doit être autorisé à sortir vers le pod exécuté sur le cluster. Si vous rencontrez des erreurs concernant les délais de connexion ou les connexions ayant échoué, assurez-vous de vérifier les groupes de sécurité et les règles de pare-feu du cluster.
S'il n'y a aucune entrée log dans le log du serveur API ou dans la métadonnées de déploiement injection , cela signifie que le webhook n'a pas été enregistré correctement.
Assurez-vous que la tâche de configuration de l'injection de métadonnées s'est exécutée avec succès en inspectant la sortie de cette commande :
bash
```
$kubectl get job newrelic-metadata-setup
```
Si la tâche n'est pas terminée, examinez le log de la tâche d'installation :
bash
```
$kubectl logs job/newrelic-metadata-setup
```
Assurez-vous que le CertificateSigningRequest est approuvé et émis en exécutant cette commande :
bash
```
$kubectl get csr newrelic-metadata-injection-svc.default
```
Assurez-vous que le secret TLS est présent en exécutant cette commande :
bash
```
$kubectl get secret newrelic-metadata-injection-secret
```
Assurez-vous que le bundle CA est présent dans la configuration du webhook en mutation :
bash
```
$kubectl get mutatingwebhookconfiguration newrelic-metadata-injection-cfg -o json
```

Assurez-vous que le TargetPort de la ressource Service correspond au Port du conteneur Deployment:

bash

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

Cette traduction automatique est fournie pour votre commodité.

Lier les applications instrumentées APM à Kubernetes

Conseil

Compatibilité et exigences

Exigences réseau

Compatibilité de l'agent APM

Configurer l'injection de métadonnées

Configuration personnalisée

Limiter l'espace de nommage soumis à injection

Utilisez cert-manager pour générer des certificats

Gérer les certificats personnalisés

Conseil

Important

Valider l'injection de métadonnées

Désactiver l'injection de métadonnées

Dépannage

Pas de métadonnées Kubernetes dans APM ni de tracing des transactions distribuées

Problème

Solution

Aucune métadonnées Kubernetes dans l'attribut transaction

Problème

Solution

Conseil

Cette traduction automatique est fournie pour votre commodité.

Lier les applications instrumentées APM à Kubernetes

Conseil

Compatibilité et exigences .css-21sua1{background:none;border:none;width:0;padding:0;}

Exigences réseau

Compatibilité de l'agent APM

Configurer l'injection de métadonnées

Configuration personnalisée

Limiter l'espace de nommage soumis à injection

Utilisez cert-manager pour générer des certificats

Gérer les certificats personnalisés

Conseil

Important

Valider l'injection de métadonnées

Désactiver l'injection de métadonnées

Dépannage

Aucune métadonnées Kubernetes dans l'attribut transaction

Compatibilité et exigences