Je ne vois pas de lien hypertexte/connexion entre mon volume persistant Kubernetes et le périphérique de stockage back-end correspondant. Mon volume persistant Kubernetes est configuré en utilisant le nom d’hôte du serveur de stockage.

Procédez comme suit pour désinstaller l’agent Telegraf existant, puis réinstaller l’agent Telegraf le plus récent. Vous devez utiliser Telegraf version 2.0 ou ultérieure et le stockage en cluster Kubernetes doit être activement surveillé par Cloud Insights.

Je vois des messages dans les journaux qui ressemblent aux messages suivants : E0901 15:21:39.962145 1 réflecteur.Go:178] k8s.io/kube-State-metrics/interne/magasin/constructeur.Go:352 : échec de la liste *v1.MutatingWebhookConfiguration : le serveur n’a pas pu trouver la ressource demandée E0901 15 178:21.43.168161.0.352.0.0.0.0.1.0.0.0.1.0.0.0.0.0.0.1.0.0.1.0.0.1.0.1.0.0.1.1.0.0.0.1.0.0.1.0.0.0.0.

Ces messages peuvent se produire si vous exécutez des metrics d’état kube version 2.0.0 ou supérieure avec les versions Kubernetes inférieures à 1.20. Pour obtenir la version Kubernetes : kubectl version pour obtenir la version kube-state-metrics : kubectl get deployment/kube-state-metrics -o jsonpath='{..image}' pour éviter que ces messages se produisent, les utilisateurs peuvent modifier leur déploiement de metrics kube-state-metrics pour désactiver les baux suivants : hookingwebconfigurations. Ressources=certificats,demandes persistantes,configmaps,cronjobs,demonets, déploiements,noeuds finaux,horizontalepodpodscalers,ingresources,details,resuts,undats,depositionsstatees,depositigmats,defiees,resottes,depositionssecuts,defiees,dees,depositionunedats,delimantees,delimantees,deficedats,dees,delimantees,delimantees,delimantees,deficedats,delimantees,deficedats,delimantees,deficedats,deficedats,dees,delimantees,delimantees,dees,delimantees,deficedats,dees,delimantees,delimantees,delimantees,delimantees,de vaillewebconfiguration,v'

Je vois des messages d’erreur de Telegraf ressemblant aux messages suivants, mais Telegraf démarre et s’exécute : oct 11 14:23:41 ip-172-31-39-47 systemd[1] : lancé l’agent serveur piloté par des plug-ins pour signaler des mesures dans InfluxDB. Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827] : heure="2021-10-11T14:23:41Z" level=erreur msg="Impossible de créer le répertoire de cache. /etc/telegraf/.cache/flocon de neige, err: mkdir /etc/telegraf/.ca che: permission refusée. Ignoré\n » func="powflocon.(*defaultLogger).Errorf" file="log.Go:120" oct 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time="2021-10-11T14:23:41Z" level=error msg="failed to open. Ignoré. Ouvrez /etc/telegraf/.cache/flocon de neige/ocsp_Response_cache.json : aucun fichier ou répertoire\n » func=« gosflocon.(*defaultLogger).Errorf » fichier=« log.Go:120 » oct 11 14:23:41 ip-172-31-39-47 telegraf[1827 23] : 2021-10 T1141114:! Démarrage de Telegraf 1.19.3

Il s’agit d’un problème connu. Reportez-vous à la section "Article GitHub" pour en savoir plus. Tant que Telegraf est opérationnel, les utilisateurs peuvent ignorer ces messages d’erreur.

Sur Kubernetes, mes coffee pad(s) Telegraf ont signalé l’erreur suivante : "erreur lors du traitement des informations de mountstats : échec de l’ouverture du fichier mountstats: /Hostfs/proc/1/mountstats, erreur: Ouvrir /hostfs/proc/1/mountstats: Permission refusée"

Si SELinux est activé et applique, il est probable que le ou les pod(s) Telegraf n’accèdent pas au fichier /proc/1/mountstats sur les nœuds Kubernetes. Pour détendre cette restriction, modifiez l’agent (kubectl edit agent agent-monitoring-netapp), et remplacer "privileged-mode: false" par "privileged-mode: true"

Sur Kubernetes, mon pod Telegraf ReplicaSet signale l’erreur suivante : [inputs.prometheus] erreur dans le plug-in : impossible de charger keypair /etc/kubernetes/pki/ETcd/Server.crt:/etc/kubernetes/pki/ETcd/Server.key : ouvrir /etc/kubernetes/pki/ETcd/Server.crt : aucun fichier ni répertoire

Le pod Télégraf ReplicaSet est conçu pour s’exécuter sur un nœud désigné comme maître ou pour ETCD. Si le pod ReplicaSet n’est pas en cours d’exécution sur l’un de ces nœuds, vous obtenez ces erreurs. Vérifiez si vos nœuds maître/ETCD ont des astuces sur eux. S’ils le font, ajoutez les tolérances nécessaires à Telegraf ReplicaSet, telegraf-RS. Par exemple, modifiez le ReplicaSet…​ kubectl edit RS telegraf-RS …​et ajoutez les tolérances appropriées à la spécification. Redémarrez ensuite le pod ReplicaSet.

J’ai un environnement PSP/PSA. Cela affecte-t-il mon opérateur de surveillance ?

Si votre cluster Kubernetes est exécuté avec une politique de sécurité Pod (PSP) ou un système d’admission à la sécurité Pod (PSA), vous devez effectuer une mise à niveau vers le dernier opérateur de surveillance NetApp Kubernetes. Procédez comme suit pour effectuer la mise à niveau vers le NKMO actuel avec la prise en charge de PSP/PSA : 1. Désinstaller L’opérateur de surveillance précédent : kubectl delete agent-monitoring-netapp -n netapp-monitoring kubectl delete ns netapp-monitoring kubectl delete crd agents.monitoring.netapp.com kubectl delete clusterrole agent-gestionnaire-rôle agent-proxy-rôle agent-metrics-lecteur kubectl delete clusterleagent-responsable-roleagent-proxy-proxy-roleagent-Reliure-agent-proxy—​agent-Reliure-agent-agent-proxy-rogle2. Installer la dernière version du moniteur.

J’ai rencontré des problèmes lors de la tentative de déploiement du NKMO, et j’ai utilisé PSP/PSA.

1. Modifiez l’agent à l’aide de la commande suivante : kubectl -n <name-space> edit agent 2. Marquez « Security-policy-enabled » comme « false ». Cela désactive les stratégies de sécurité Pod et l’admission de sécurité Pod et permet au NKMO de se déployer. Confirmez en utilisant les commandes suivantes : kubectl get psp (devrait afficher Pod Security Policy supprimé) kubectl get all -n <namespace>

grep -i psp (doit montrer que rien n’a été trouvé)

Erreurs « ImagePullBackoff » détectées

Ces erreurs peuvent se produire si vous disposez d’un référentiel docker personnalisé ou privé et si vous n’avez pas encore configuré l’opérateur de surveillance NetApp Kubernetes pour le reconnaître correctement. En savoir plus a propos de la configuration pour repo personnalisé/privé.

J’ai un problème avec mon déploiement d’opérateur de surveillance, et la documentation actuelle ne m’aide pas à le résoudre.