Si vous exécutez la version 2, consultez ces erreurs d’intégration Kubernetes courantes. Ces erreurs apparaissent dans le log standard non détaillé de l’agent infrastructure . Si vous avez besoin d'un log plus détaillé, consultez les logs Kubernetes .
L'intégration de Kubernetes nécessite kube-state-metrics. Si cela manque, vous verrez une erreur comme celle-ci dans le log du conteneur newrelic-infra :
$2018-04-11T08:02:41.765236022Z time="2018-04-11T08:02:41Z" level=error $msg="executing data source" data prefix="integration/com.newrelic.kubernetes" $error="exit status 1" plugin name=nri-kubernetes stderr="time=\"2018-04-11T08:02:41Z\" $level=fatal msg=\"failed to discover kube-state-metrics endpoint, $got error: no service found by label k8s-app=kube-state-metrics\"\n"Les raisons courantes de cette erreur incluent :
kube-state-metricsn'a pas été déployé dans le cluster.kube-state-metricsest déployé à l'aide d'un déploiement personnalisé.- Il existe plusieurs versions de
kube-state-metricsen cours d'exécution et l'intégration Kubernetes ne trouve pas la bonne.
L'intégration Kubernetes détecte automatiquement kube-state-metrics dans votre cluster à l'aide de cette logique :
- Il recherche un service
kube-state-metricsexécuté sur l'espace de nommagekube-system. - Si cela n'est pas trouvé, il recherche une balise de service avec l'étiquette
"k8s-app: kube-state-metrics".
L'intégration nécessite également que le pod kube-state-métriques ait l'étiquette k8s-app: kube-state-metrics ou app: kube-state-metrics. Si aucun de ces éléments n'est trouvé, il y aura une entrée log comme celle-ci :
$2018-04-11T09:25:00.825532798Z time="2018-04-11T09:25:00Z" level=error $msg="executing data source" data prefix="integration/com.newrelic.kubernetes" $error="exit status 1" plugin name=nri-kubernetes stderr="time=\"2018-04-11T09:25:00Z\" $level=fatal msg=\"failed to discover nodeIP with kube-state-metrics, $got error: no pod found by label k8s-app=kube-state-metrics\"\nPour résoudre ce problème, ajoutez l’étiquette k8s-app=kube-state-metrics au pod kube-state-metrics .
Si les métriques des nœuds Kubernetes , du pod et du conteneur s'affichent mais que les métriques de l'espace de nommage, de la déploiement et de ReplicaSets sont manquantes, l'intégration Kubernetes ne parvient pas à se connecter à kube-state-metrics.
Indicateurs d'espace de nommage, de déploiement et de données ReplicaSet manquants :
- Dans le graphique # of K8s objects , ces données sont manquantes.
- les requêtes pour
K8sNamespaceSample,K8sDeploymentSampleetK8sReplicasetSamplen'affichent aucune donnée.
Il y a plusieurs raisons possibles à cela :
kube-state-metricsle service a été personnalisé pour écouter sur le port 80. Si vous utilisez un port différent, vous pouvez voir une erreur comme celle-ci dans le logverbose:bash$time="2018-04-04T09:35:47Z" level=error msg="executing data source"$data prefix="integration/com.newrelic.kubernetes" error="exit status 1"$plugin name=nri-kubernetes stderr="time=\"2018-04-04T09:35:47Z\"$level=fatal msg=\"Non-recoverable error group: error querying KSM.$Get http://kube-state-metrics.kube-system.svc.cluster.local:0/metrics:$net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)\"\n"Il s'agit d'un problème connu qui se produit dans certains clusters où il faut trop de temps à
kube-state-metricspour collecter toutes les informations du cluster avant de les envoyer à l'intégration.Pour contourner ce problème, augmentez le délai d'expiration du client kube-state-métriques.
kube-state-metricsl'instance s'exécute derrièrekube-rbac-proxy. New Relic ne prend actuellement pas en charge cette configuration. Vous pouvez voir une erreur comme celle-ci dans le logverbose:bash$time="2018-03-28T23:09:12Z" level=error msg="executing data source"$data prefix="integration/com.newrelic.kubernetes" error="exit status 1"$plugin name=nri-kubernetes stderr="time=\"2018-03-28T23:09:12Z\"$level=fatal msg=\"Non-recoverable error group: error querying KSM.$Get http://192.168.132.37:8443/metrics: net/http: HTTP/1.x$transport connection broken: malformed HTTP response \\\"\\\\x15\\\\x03\\\\x01\\\\x00\\\\x02\\\\x02\\\"\"\n"La charge utile KSM est assez importante et l'intégration Kubernetes qui traite la date est en train d'être interrompue. Étant donné que l’intégration n’est pas le processus principal du conteneur, le pod n’est pas redémarré. Cette situation peut être repérée dans le log du pod
newrelic-infraexécuté dans le même nœud de KSM :bash$time="2020-12-10T17:40:44Z" level=error msg="Integration command failed" error="signal: killed" instance=nri-kubernetes integration=com.newrelic.kubernetesPour contourner ce problème, augmentez les limites de mémoire de DaemonSet afin que le processus ne soit pas arrêté.
Le pod Newrelic et le compte de service newrelic ne sont pas déployés dans le même espace de nommage. C'est généralement parce que le contexte actuel spécifie un espace de nommage. Si tel est le cas, vous verrez une erreur comme celle-ci :
$time=\"2018-05-31T10:55:39Z\" level=panic msg=\"p$ods is forbidden: User \\\"system:serviceaccount:kube-system:newrelic\\\" cannot list pods at the cluster scope\"Pour vérifier si c'est le cas, exécutez :
$kubectl describe serviceaccount newrelic | grep Namespace$kubectl get pods -l name=newrelic-infra --all-namespaces$kubectl config get-contextsPour résoudre ce problème, modifiez l'espace de nommage du compte de service dans le fichier YAML New Relic DaemonSet pour qu'il soit identique à l'espace de nommage du contexte actuel :
- kind: ServiceAccount name: newrelic namespace: default---Ne pas voir les données control plane
Exécutez les commandes suivantes pour rechercher manuellement les nœuds control plane :
$kubectl get nodes -l node-role.kubernetes.io/control-plane=""Si les nœuds control plane suivent la convention d'étiquetage définie dans le composant du plan de contrôle, vous devriez obtenir une sortie comme :
$NAME STATUS ROLES AGE VERSION$ip-10-42-24-4.ec2.internal Ready control-plane 42d v1.14.8Si aucun nœud n'est trouvé, il existe deux scénarios :
Vos nœuds control plane n’ont pas les étiquettes requises qui les identifient comme plan de contrôle. Dans ce cas, vous devez ajouter les deux étiquettes à vos nœuds control plane .
Vous êtes dans un cluster géré et votre fournisseur gère les nœuds control plane pour vous. Dans ce cas, vous ne pouvez rien faire, car votre fournisseur limite l'accès à ces nœuds.
Pour identifier un pod d’intégration exécuté sur un nœud control plane , remplacez NODE_NAME dans la commande suivante par l’un des noms de nœud répertoriés à l’étape précédente :
$kubectl get pods --field-selector spec.nodeName=NODE_NAME -l name=newrelic-infra --all-namespacesLa commande suivante est la même que la précédente, sauf qu'elle sélectionne le nœud pour vous :
$kubectl get pods --field-selector spec.nodeName=$(kubectl get nodes -l node-role.kubernetes.io/control-plane="" -o jsonpath="{.items[0].metadata.name}") -l name=newrelic-infra --all-namespacesSi tout est correct, vous devriez obtenir un résultat comme :
$NAME READY STATUS RESTARTS AGE$newrelic-infra-whvzt 1/1 Running 0 6d20hSi l'intégration n'est pas en cours d'exécution sur vos nœuds control plane , vérifiez que le daemonset dispose de toutes les instances souhaitées en cours d'exécution et prêtes.
$kubectl get daemonsets -l app=newrelic-infra --all-namespacesReportez-vous à la section de documentation sur la découverte des nœuds et des composants control plane et recherchez les étiquettes que l'intégration utilise pour découvrir les composants. Exécutez ensuite les commandes suivantes pour voir s’il existe des pods avec de telles étiquettes et les nœuds sur lesquels ils s’exécutent :
$kubectl get pods -l k8s-app=kube-apiserver --all-namespacesS'il y a un composant avec l'étiquette donnée, vous devriez voir quelque chose comme :
$NAMESPACE NAME READY STATUS RESTARTS AGE$kube-system kube-apiserver-ip-10-42-24-42.ec2.internal 1/1 Running 3 49dLa même chose devrait être faite avec le reste des composants :
$kubectl get pods -l k8s-app=etcd-manager-main --all-namespaces$kubectl get pods -l k8s-app=kube-scheduler --all-namespaces$kubectl get pods -l k8s-app=kube-kube-controller-manager --all-namespacesPour récupérer le log, suivez les instructions sur obtenir le log à partir d' pod exécuté sur un nœud control plane . Le log d'intégration pour chaque composant le message suivant Running job: COMPONENT_NAME. Par exemple :
$Running job: scheduler$Running job: etcd$Running job: controller-manager$Running job: api-serverSi vous n'avez pas spécifié l'option configuration ETCD_TLS_SECRET_NAME, vous trouverez ce message dans le log :
$Skipping job creation for component etcd: etcd requires TLS configuration, none givenSi une erreur se produit lors de l'interrogation des métriques d'un composant, elle sera enregistrée après le message Running job .
Pour obtenir le point de terminaison du composant du control plane que vous souhaitez interroger, consultez le composant du plan de contrôle. Avec le point de terminaison, vous pouvez utiliser le pod d'intégration qui s'exécute sur le même nœud que le composant à interroger. Consultez ces exemples pour savoir comment interroger le planificateur Kubernetes :
$kubectl exec -ti POD_NAME -- wget -O - localhost:10251/metricsLa commande suivante fait la même chose que la précédente, mais choisit également le pod pour vous :
$kubectl exec -ti $(kubectl get pods --all-namespaces --field-selector spec.nodeName=$(kubectl get nodes -l node-role.kubernetes.io/control-plane="" -o jsonpath="{.items[0].metadata.name}") -l name=newrelic-infra -o jsonpath="{.items[0].metadata.name}") -- wget -O - localhost:10251/metricsSi tout est correct, vous devriez obtenir des métriques sur le format Prometheus, quelque chose comme ceci :
$Connecting to localhost:10251 (127.0.0.1:10251)$# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.$# TYPE apiserver_audit_event_total counter$apiserver_audit_event_total 0$# HELP apiserver_audit_requests_rejected_total Counter of apiserver requests rejected due to an error in audit logging backend.$# TYPE apiserver_audit_requests_rejected_total counter$apiserver_audit_requests_rejected_total 0$# HELP apiserver_client_certificate_expiration_seconds Distribution of the remaining lifetime on the certificate used to authenticate a request.$# TYPE apiserver_client_certificate_expiration_seconds histogram$apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0$apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0$apiserver_client_certificate_expiration_seconds_bucket{le="3600"} 0