Présentation

La version 2 de l'intégration Kubernetes présente des paramètres et des exigences différents de la version 3. Ce document passe en revue les paramètres qui sont différents de la version 3 et dont vous aurez besoin pour la version 2. Si nous ne spécifions rien de différent, vous pouvez utiliser les paramètres de la version 3.

Prudence

New Relic a rendu obsolète la version 2 et recommande de ne pas l'utiliser. Nous maintenons cette documentation pour les utilisateurs qui utilisent encore la version 2 même si nous ne la supportons plus.

Consultez Introduction à l’intégration de Kubernetes pour démarrer avec la version actuelle de Kubernetes.

Pour comprendre les modifications de la version 3, consultez le document Modifications introduites dans l’intégration Kubernetes version 3 .

Monitoring control plane avec la version d'intégration 2

Cette section explique comment configurer control plane monitoring sur les versions 2 et antérieures de l'intégration.

Veuillez noter que ces versions avaient des options de découverte automatique moins flexibles et ne prenaient pas en charge le point de terminaison externe. Nous vous recommandons fortement de mettre à jour vers la version 3 dès que possible.

Découverte automatique et configuration par défaut : `hostNetwork` et `privileged`

Dans les versions inférieures à la v3, lorsque l'intégration est effectuée à l'aide de privileged: false, le paramètre hostNetwork pour le composant control plane sera également défini sur false.

Découverte des control plane et des composants control plane

L'intégration Kubernetes s'appuie sur les conventions d'étiquetage kubeadm pour découvrir les nœuds control plane et les composants control plane . Cela signifie que les nœuds control plane doivent être étiquetés avec node-role.kubernetes.io/control-plane="".

Les composants control plane doivent avoir soit les étiquettes k8s-app, soit les étiquettes tier et component. Consultez ce tableau pour connaître les combinaisons et valeurs d'étiquettes acceptées :

Composant	Étiquette	Point de terminaison
Serveur API	Kubeadm / Kops / ClusterAPI `k8s-app=kube-apiserver` `tier=control-plane component=kube-apiserver` OpenShift `app=openshift-kube-apiserver apiserver=true`	`localhost:443/metrics` par défaut (peut être configuré) si la demande échoue revient à `localhost:8080/metrics`
etcd	Kubeadm / Kops / ClusterAPI `k8s-app=etcd-manager-main` `tier=control-plane component=etcd` OpenShift `k8s-app=etcd`	`localhost:4001/metrics`
Planificateur	Kubeadm / Kops / ClusterAPI `k8s-app=kube-scheduler` `tier=control-plane component=kube-scheduler` OpenShift `app=openshift-kube-scheduler scheduler=true`	`localhost:10251/metrics`
Responsable contrôleur	Kubeadm / Kops / ClusterAPI `k8s-app=kube-controller-manager` `tier=control-plane component=kube-controller-manager` OpenShift `app=kube-controller-manager kube-controller-manager=true`	`localhost:10252/metrics`

Lorsque l'intégration détecte qu'elle s'exécute à l'intérieur d'un nœud control plane , elle essaie de trouver les composants qui s'exécutent sur le nœud en recherchant les pods qui correspondent aux étiquettes répertoriées dans le tableau ci-dessus. Pour chaque composant en cours d’exécution, l’intégration envoie une demande à son point de terminaison de métriques.

Configuration

monitoring du plan de contrôle est automatique pour les agents exécutés à l'intérieur des nœuds control plane . Le seul composant qui nécessite une étape supplémentaire pour s'exécuter est etcd, car il utilise l'authentification TLS mutuelle (mTLS) pour requests des clients. Le serveur API peut également être configuré pour être interrogé à l'aide du port sécurisé.

Important

monitoring du plan de contrôle pour OpenShift 4.x nécessite configuration supplémentaire. Pour plus d'informations, consultez la section Configuration d'OpenShift 4.x.

etcd

Afin de configurer mTLS pour interroger etcd, vous devez définir ces deux options de configuration :

Option	Valeur
`ETCD_TLS_SECRET_NAME`	Nom d'un secret Kubernetes qui contient la configuration mTLS. Le secret doit contenir les clés suivantes : `cert`: le certificat qui identifie le client effectuant la demande. Il doit être signé par une autorité de certification de confiance etcd. `key`: la clé privée utilisée pour générer le certificat client. `cacert`: l'autorité de certification racine utilisée pour identifier le certificat du serveur etcd. Si l'option `ETCD_TLS_SECRET_NAME` n'est pas définie, les métriques etcd ne seront pas récupérées.
`ETCD_TLS_SECRET_NAMESPACE`	L'espace de nommage où le secret spécifié dans le `ETCD_TLS_SECRET_NAME` a été créé. S'il n'est pas défini, l'espace de nommage `default` est utilisé.

Option

Valeur

ETCD_TLS_SECRET_NAME

Nom d'un secret Kubernetes qui contient la configuration mTLS.

Le secret doit contenir les clés suivantes :

cert: le certificat qui identifie le client effectuant la demande. Il doit être signé par une autorité de certification de confiance etcd.
key: la clé privée utilisée pour générer le certificat client.
cacert: l'autorité de certification racine utilisée pour identifier le certificat du serveur etcd.
Si l'option ETCD_TLS_SECRET_NAME n'est pas définie, les métriques etcd ne seront pas récupérées.

ETCD_TLS_SECRET_NAMESPACE

L'espace de nommage où le secret spécifié dans le ETCD_TLS_SECRET_NAME a été créé. S'il n'est pas défini, l'espace de nommage default est utilisé.

Serveur API

Par défaut, les métriques du serveur API sont des requêtes utilisant le point de terminaison localhost:8080 non sécurisé. Si ce port est désactivé, vous pouvez également interroger ces métriques via le port sécurisé. Pour activer cela, définissez l’option de configuration suivante dans le fichier manifeste d’intégration Kubernetes :

Option	Valeur
`API_SERVER_ENDPOINT_URL`	L'URL (sécurisée) pour requêter les métriques. Le serveur API utilise `localhost:443` par défaut Assurez-vous que le `ClusterRole` a été mis à jour vers la version la plus récente trouvée dans le manifeste Ajouté dans la version 1.15.0

Option

Valeur

API_SERVER_ENDPOINT_URL

L'URL (sécurisée) pour requêter les métriques. Le serveur API utilise localhost:443 par défaut

Assurez-vous que le ClusterRole a été mis à jour vers la version la plus récente trouvée dans le manifeste

Ajouté dans la version 1.15.0

Important

Notez que le port peut être différent selon le port sécurisé utilisé par le serveur API.

Par exemple, dans Minikube, le port sécurisé du serveur API est 8443 et donc API_SERVER_ENDPOINT_URL doit être défini sur https://localhost:8443

Configuration d'OpenShift

les composants du plan de contrôle sur OpenShift 4.x utilisent des URL de point de terminaison qui nécessitent une authentification SSL et basée sur un compte de service. Par conséquent, vous ne pouvez pas utiliser les URL de point de terminaison par défaut .

Important

Lors de l'installation de openshift via Helm, spécifiez la configuration pour inclure automatiquement ces points de terminaison. Les paramètres openshift.enabled=true et openshift.version="4.x" incluront le point de terminaison sécurisé et activeront l'exécution /var/run/crio.sock .

Pour configurer control plane monitoring sur OpenShift, supprimez le commentaire des variables d’environnement suivantes dans le manifeste personnalisé. Les valeurs d'URL sont préconfigurées sur les URL de base par défaut pour les control plane monitoring métriques du point de terminaison dans OpenShift 4.x.

- name: "SCHEDULER_ENDPOINT_URL"
        value: "https://localhost:10259
        - name: "ETCD_ENDPOINT_URL"
        value: "https://localhost:9979"
        - name: "CONTROLLER_MANAGER_ENDPOINT_URL"
        value: "https://localhost:10257"
        - name: "API_SERVER_ENDPOINT_URL"
        value: "https://localhost:6443"

Important

Même si le ETCD_ENDPOINT_URL personnalisé est défini, etcd nécessite que l'authentification HTTPS et mTLS soit configurée. Pour en savoir plus sur la configuration de mTLS pour etcd dans OpenShift, consultez Configurer mTLS pour etcd dans OpenShift.

Log de Kubernetes

Si vous souhaitez générer un log détaillé et obtenir des informations sur la version et configuration , consultez simplement les informations ci-dessous.

Pour l'intégration Kubernetes , l'agent infrastructure ajoute uniquement une entrée log en cas d'erreur. Les erreurs les plus courantes sont affichées dans le log standard (non détaillé). Si vous effectuez une enquête plus approfondie par vous-même ou avec l'assistance New Relic, vous pouvez activer le mode verbeux.

Prudence

Le mode verbeux augmente considérablement la quantité d'informations envoyées au fichier de log. N'activez ce mode que temporairement à des fins de dépannage et réinitialisez le niveau de log une fois terminé.

Pour activer le logging détaillé à l’aide d’un fichier manifeste :

Activer le logging détaillé : dans le fichier de déploiement, définissez la valeur de NRIA_VERBOSE sur 1.
Appliquez la configuration modifiée en exécutant :
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Laissez le mode verbeux pendant quelques minutes ou jusqu'à ce qu'une activité suffisante se soit produite.
Désactiver le mode verbeux : redéfinissez la valeur NRIA_VERBOSE sur 0.
Appliquez la configuration restaurée en exécutant :
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Obtenir une liste des nœuds dans l’environnement :
bash
```
$kubectl get nodes --all-namespaces
```

Obtenez une liste des infrastructure et du pod kube-state-métriques :

bash

$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'

Récupérez le log du pod se connectant à kube-state-metrics.
Récupérer la configuration du service kube-state-metrics .

Prudence

Pour activer le logging détaillé à l’aide de Helm :

Exécutez cette commande :

bash

$helm upgrade -n <namespace> --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=true newrelic/nri-bundle

Laissez le mode verbeux pendant quelques minutes ou jusqu'à ce qu'une activité suffisante se soit produite.

Lorsque vous disposez des informations dont vous avez besoin, désactivez le logging détaillé :

bash

$helm upgrade --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=false newrelic/nri-bundle

Appliquez la configuration restaurée en exécutant :
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Obtenir une liste des nœuds dans l’environnement :
bash
```
$kubectl get nodes --all-namespaces
```

Obtenez une liste des infrastructure et du pod kube-state-métriques :

bash

$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'

Récupérez le log du pod se connectant à kube-state-metrics.
Récupérer la configuration du service kube-state-metrics .

Pour obtenir le log du pod se connectant à kube-state-metrics:

Exécutez cette commande :

bash

$kubectl get pods --all-namespaces -o wide | grep kube-state-metrics

Recherchez un résultat similaire à celui-ci :

bash

$kube-system   kube-state-metrics-5c6f5cb9b5-pclhh     2/2
$    Running   4          4d        172.17.0.3   minikube

Obtenez le pod New Relic qui s'exécute sur le même nœud que kube-state-metrics:

bash

$kubectl describe node minikube | grep newrelic-infra

Recherchez un résultat similaire à celui-ci :

bash

$default                    newrelic-infra-5wcv6                     100m (5%)
$0 (0%)      100Mi (5%)       100Mi (5%)

Récupérez le log des nœuds en exécutant :
bash
```
$kubectl logs newrelic-infra-5wcv6
```

Pour obtenir le log d’un pod exécuté sur un nœud control plane :

Obtenez les nœuds étiquetés comme control plane:

bash

$kubectl get nodes -l node-role.kubernetes.io/control-plane=""

Recherchez un résultat similaire à celui-ci :

bash

$NAME                         STATUS  ROLES          AGE   VERSION
$ip-10-42-24-4.ec2.internal   Ready   control-plane  42d   v1.14.8

Récupérez le pod New Relic qui s’exécute sur l’un des nœuds renvoyés à l’étape précédente :
bash
```
$kubectl get pods --field-selector spec.nodeName=ip-10-42-24-4.ec2.internal -l name=newrelic-infra --all-namespaces
```
Recherchez un résultat similaire à celui-ci :
bash
```
$newrelic-infra-whvzt
```
Récupérez le log des nœuds en exécutant cette commande :
bash
```
$kubectl logs newrelic-infra-whvzt
```

Monitorer les services exécutés sur Kubernetes

Les services de monitoring dans Kubernetes fonctionnent en exploitant notre agent infrastructure et notre intégration sur hôte et un mécanisme de découverte automatique pour les pointer vers un pod avec un sélecteur spécifié.

Consultez le document Activer monitoring des services à l’aide du graphique Helm pour savoir comment procéder. Consultez cet exemple pour la version 2, qui montre la configuration yaml pour l'intégration Redis ajoutée au fichier values.yml du graphique nri-bundle .

newrelic-infrastructure:
    integrations_config:
    - name: nri-redis.yaml
    data:
    discovery:
    command:
    # Run NRI Discovery for Kubernetes
    # https://github.com/newrelic/nri-discovery-kubernetes
    exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
    match:
    label.app: redis
    integrations:
    - name: nri-redis
    env:
    # using the discovered IP as the hostname address
    HOSTNAME: ${discovery.ip}
    PORT: 6379
    labels:
    env: test

Ajouter un service YAML à la configuration d'intégration Kubernetes

Si vous utilisez la version 2 de l'intégration Kubernetes, vous devez ajouter une entrée pour ce ConfigMap dans la section volumes et volumeMounts du spec du DaemonSet, afin de garantir que tous les fichiers du ConfigMap sont montés dans /etc/newrelic-infra/integrations.d/.

Cette traduction automatique est fournie pour votre commodité.

Prudence

Monitoring control plane avec la version d'intégration 2

Découverte automatique et configuration par défaut : `hostNetwork` et `privileged`

Découverte des control plane et des composants control plane

Configuration

Important

etcd

Serveur API

Important

Configuration d'OpenShift

Important

Important

Log de Kubernetes

Activer le logging détaillé à l'aide d'un fichier manifeste

Prudence

Activer le logging détaillé à l'aide de Helm

Prudence

Obtenir le log du pod se connectant à kube-state-métriques

Obtenir le log d'un pod exécuté sur un nœud control plane

Monitorer les services exécutés sur Kubernetes

Ajouter un service YAML à la configuration d'intégration Kubernetes

Cette traduction automatique est fournie pour votre commodité.

Présentation

Prudence

Monitoring control plane avec la version d'intégration 2 .css-21sua1{background:none;border:none;width:0;padding:0;}

Découverte automatique et configuration par défaut : hostNetwork et privileged

Découverte des control plane et des composants control plane

Configuration

Important

etcd

Serveur API

Important

Configuration d'OpenShift

Important

Important

Log de Kubernetes

Activer le logging détaillé à l'aide de Helm

Obtenir le log du pod se connectant à kube-state-métriques

Obtenir le log d'un pod exécuté sur un nœud control plane

Monitorer les services exécutés sur Kubernetes

Ajouter un service YAML à la configuration d'intégration Kubernetes

Monitoring control plane avec la version d'intégration 2

Découverte automatique et configuration par défaut : `hostNetwork` et `privileged`