Surveillance de Kubernetes
Instana peut vous aider à accéder à des informations détaillées sur l' Kubernetes, à analyser les appels Kubernetes, à associer les services Kubernetes et les services logiques, à utiliser des règles de santé intégrées ou personnalisées pour les alertes d'entités Kubernetes, et à suivre les charges de travail déployées sur les maillages de services.
Versions prises en charge
Instana prend actuellement en charge les versions stables les plus récentes d' Kubernetes Conformément à la politique de compatibilité des versions d' Kubernetes, Instana prend en charge la dernière version d' Kubernetes ainsi que les quatre versions précédentes. Toutefois, les deux premières versions sont considérées comme étant en voie de dépréciation progressive.
Par exemple, si la dernière version disponible est 1.31, alors Instana prend en charge les versions 1.31, 1.30, 1.29, 1.28 et 1.27, les versions 1.28 et 1.27 étant considérées comme obsolètes (mais toujours compatibles).
Services Kubernetes gérés pris en charge
- IBM Cloud Kubernetes Service Surveillance et gestion des performances
- Amazon Elastic Container Service for Kubernetes (EKS)
- Azure Kubernetes Service (AKS)
- Google Kubernetes Engine (GKE)
- IBM Cloud Kubernetes Service
- VMware Tanzu Kubernetes Grid (TKG) et VMware Tanzu Kubernetes Grid Integration (TKGI), anciennement connu sous le nom de Pivotal Container Service (PKS)
Maillages de services pris en charge
Instana prend en charge les trois dernières versions stables d' Istio
Installation de l'agent Instana dans Kubernetes
Pour surveiller Kubernetes à l'aide d' Instana, vous devez installer l'agent hôte Instana dans votre cluster Kubernetes.
Pour plus d'informations sur les étapes d'installation de l'agent hôte, consultez la page « Installation de l'agent hôte » sur Kubernetes.
L'installation des agents d' Instana ation sur VMware Tanzu Kubernetes Grid est entièrement automatisée par la tuile « Microservices Application Monitoring » de l' Instana pour VMware Tanzu.
Kubernetes capteurs
Instana propose les capteurs d' Kubernetes s suivants :
- Capteur hérité Kubernetes
- Nouvelle génération K8sensor
Le capteur Legacy Kubernetes est un produit en fin de vie (EOL). Toutes les nouvelles fonctionnalités et corrections sont disponibles sur K8sensor; veuillez donc mettre à jour vos environnements pour pouvoir en profiter.
Le K8sensor de nouvelle génération présente les avantages suivants :
- Haute disponibilité
- Meilleur contrôle des limites de ressources dans un déploiement
- Nouvelles fonctionnalités et corrections qui ne sont pas rétroportées vers l'ancien capteur
Pour activer la mise à l'échelle automatique horizontale (HPA) pour K8sensor, consultez la section « Activation de la mise à l'échelle automatique (HPA) pour k8sensor » (solution de contournement).
Le capteur Legacy Kubernetes est désactivé par défaut. Pour vérifier, consultez le fichier de configuration.yaml l'agent :
com.instana.plugin.kubernetes:
enabled: false
Pour vous assurer que cette configuration est effective, suivez les étapes décrites dans Vérification de l'état et de la version de l'ancien capteur. Si le capteur est correctement désactivé, le capteur « Legacy Kubernetes » n'apparaîtra pas dans l'interface utilisateur d' Instana.
Le K8sensor de nouvelle génération est automatiquement installé par défaut après l'installation de l'agent. Pour déterminer si le K8sensor fonctionne sur un cluster, exécutez la commande décrite dans la section Vérification de l'état et de la version de K8sensor.
Capteur hérité Kubernetes
Le capteur Legacy Kubernetes est en fin de vie (EOL). La dernière version est toujours disponible au téléchargement.
Installation
Si vous devez tout de même réinstaller le capteur Legacy Kubernetes sur un système qui n'a pas encore été migré vers la plateforme Next Generation K8sensor, vous pouvez utiliser la version finale du graphique 1.2.74 de l'agent obsolète 1.X Helm avec le --set k8s_sensor.deployment.enabled=false paramètre correspondant lors de l'installation.
Vérification de l'état et de la version du capteur existant
Pour vérifier l'état et la version en cours d'exécution du capteur Legacy Kubernetes, procédez comme suit :
- Dans le menu de navigation, sélectionnez Infrastructure.
- Dans l'onglet Maps, cliquez sur votre nœud Kubernetes.
- Dans le panneau des détails du nœud, développez « Agent d' Instana » (1), puis cliquez sur votre agent.
- Sur le panneau de l'agent, cliquez sur Ouvrir le tableau de bord.
- Sur la page de l'agent, cliquez sur Info capteurs dans la zone Info.
- Dans la fenêtre Info capteurs, recherchez
Instana - Kubernetes - Sensordans le champ de recherche.
Si le capteur est correctement activé, une correspondance apparaît dans le tableau. La colonne State affiche la valeur Active, et la colonne Version indique le numéro de version, par exemple, 1.2.143.
Traitement des incidents
Si la recherche et Instana - Kubernetes - Sensor le filtrage des journaux de l'agent com.instana.sensor-kubernetes ne donnent aucun résultat, vérifiez la carte de configuration de l'agent Instana en exécutant la commande suivante :
kubectl -n instana-agent get cm instana-agent -o yaml
Assurez-vous que le paramètre suivant n'est pas présent :
com.instana.plugin.kubernetes:
enabled: false
Si la colonne État du Instana - Kubernetes - Sensor affiche Waiting pendant plusieurs minutes, cela signifie que le capteur n'a pas réussi à s'activer.
Recherchez les journaux de l'agent, filtrez pour com.instana.sensor-kubernetes, et cherchez Activating Kubernetes Sensor. Plus précisément, vérifiez si le message suivant s'affiche :
ERROR : bundle com.instana.sensor-kubernetes:1.2.143 (246)[com.instana.agent.kubernetes.sensor.Kubernetes(479)] : The activate method has thrown an exception
io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://10.43.0.1/apis/apps/v1/deployments?labelSelector=app%3Dk8sensor. Message: Forbidden!Configured serv
ice account doesn't have access. Service account may have been revoked. deployments.apps is forbidden: User "system:serviceaccount:instana-agent:instana-agent" cannot list resource "deployme
nts" in API group "apps" at the cluster scope.
Ce message d'erreur indique qu'un compte de service ne peut pas être utilisé pour accéder au serveur Kubernetes API.
Nouvelle génération K8sensor
Installation
Lorsque vous installez l'agent, l' K8sensor de nouvelle génération est installée automatiquement par défaut via la icr.io/instana/k8sensor:latest balise. Si vous indiquez la k8s_sensor.deployment.enabled valeur, assurez-vous qu'elle est définie sur true (la valeur par défaut).
Optimiser l'ingestion des données grâce à la configuration de l'intervalle d'interrogation
Vous pouvez configurer la fréquence d'interrogation de l' K8sensor en effectuant le réglage k8s_sensor.pollrate à l'un des emplacements suivants :
- Helm graphique (par exemple,
--set k8s_sensor.pollrate=15s) InstanaAgentressource personnalisée (par exemple,k8s_sensor.pollrate: "15s")
1s et 30s. Les valeurs situées en dehors de cette plage sont automatiquement ajustées à la valeur seuil la plus proche.| Paramètre | Idéal pour | Considérations |
|---|---|---|
| 1s | Diagnostic approfondi, détection rapide des transitoires | Génère davantage de bruit et augmente les coûts d'infrastructure; peut faire apparaître des anomalies transitoires |
| 10s | La plupart des cas d'utilisation des clients | Offre un bon équilibre entre réactivité et qualité du signal; détecte les changements importants sans accorder trop d'importance aux pics de courte durée |
| 30s | environnements à grande échelle, où le coût est un facteur déterminant et qui sont stables | Détection plus lente des problèmes; les problèmes passagers risquent de ne pas être détectés |
Vérification de l'état et de la version d' K8sensor
Pour déterminer si le K8sensor est exécuté sur un cluster, exécutez la commande suivante pour répertorier les déploiements avec l'étiquette app: k8sensor.
kubectl get deployments --all-namespaces -l app=k8sensor
Si K8sensor figure dans la liste, alors K8sensor est activé. Lorsque K8sensor est activé, le capteur Legacy Kubernetes est automatiquement désactivé. Dans le fichier configuration.yaml, vous pouvez voir que la valeur enabled est remplacée par false comme suit :
com.instana.plugin.kubernetes:
enabled: false
La version K8sensor est mieux identifiée par le hachage sha256 de son image. Pour vérifier le hachage de l'image du conteneur K8sensor en cours d'exécution, exécutez la commande suivante :
kubectl get po -n instana-agent -l app=k8sensor -o jsonpath='{ .items[0].status.containerStatuses[0].imageID }'
Activation de l'auto-scaling (HPA) pour « K8sensor » (solution de contournement)
Instana ne propose actuellement pas de fonctionnalité intégrée d'auto-scaling (modèle HPA) pour l' K8sensor de nouvelle génération. Vous pouvez toutefois activer la mise à l'échelle automatique en appliquant une instance HPA ( Kubernetes ) standard HorizontalPodAutoscaler au déploiement k8sensor. Cette solution de contournement nécessite un cluster sur lequel le serveur de métriques est installé.
L'opérateur de l'agent « Instana » gère le nombre initial de répliques du déploiement « k8sensor » à partir de la ressource InstanaAgent personnalisée (CR). Pour éviter tout conflit avec HPA, définissez une seule fois le nombre de répliques CR et veillez à ce qu'il corresponde à celui de HPA minReplicas.
Prérequis
Assurez-vous que le serveur de métriques est installé et fonctionne correctement dans votre cluster.
Procédure
Pour activer la mise à l'échelle automatique, procédez comme suit :
- Définissez les demandes de ressources et le nombre de répliques stables dans le
InstanaAgentCR : définissez le nombre de répliques du déploiement dans le CR sur le minimum requis et ne le modifiez pas. Pour la tarification HPA basée sur l'utilisation, définissez les demandes de CPU et de mémoire pour le conteneur « k8sensor » comme indiqué dans l'exemple suivant :kubectl patch agents.instana.io instana-agent -n instana-agent \ --type='merge' -p '{ "spec": { "k8s_sensor": { "deployment": { "replicas": 2, "pod": { "requests": { "memory": "512Mi", "cpu": "200m" } } } } } }'Adaptez le nombre de répliques, la mémoire et la puissance du processeur en fonction de votre environnement. Assurez-vous que l'espace de noms et le nom du CR (
instana-agent) correspondent à votre installation. Appliquer le manifeste HPA :
Créez un fichier
k8sensor-hpa.yamlcomme indiqué dans l'exemple suivant. Mettez à jour l'espace de noms, s'il est différent.apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: instana-agent-k8sensor namespace: instana-agent spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: instana-agent-k8sensor minReplicas: 2 maxReplicas: 8 behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Percent value: 100 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 50 periodSeconds: 60 metrics: - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 75Appliquez le manifeste en exécutant la commande suivante :
kubectl apply -f k8sensor-hpa.yamlRemarque : Définir les demandes relatives aux objectifs d'utilisation. Si vous ne pouvez pas définir de requêtes, utilisez « AverageValue » à la place de « Utilization » avec une cible en octets (par exemple, averageValue: 800Mi ). La mémoire est généralement le facteur déterminant; le processeur peut être ajouté à titre de mesure de sécurité.
Vérifiez si HPA est activé en exécutant les commandes suivantes :
kubectl get hpa instana-agent-k8sensor -n instana-agentkubectl get deploy instana-agent-k8sensor -n instana-agent -o jsonpath='{.spec.replicas}'; echokubectl top pods -n instana-agent | grep k8sensorSi vous modifiez ultérieurement le
InstanaAgentCR, l'opérateur de l'agent Instana pourrait se réinitialiser brièvement.spec.replicas. Cependant, le HPA synchronise et rétablit le nombre requis de répliques. Les paramètres de comportement dans HPA empêchent le battement.
Traitement des incidents
Si la liste des déploiements avec l'étiquette app: k8sensor ne renvoie aucun résultat, le cluster n'exécute pas K8sensor. Ce problème signifie que K8sensor a été désactivé lors du déploiement de l'agent. Pour résoudre ce problème, redéployez l'agent avec K8sensor activé.
Accès aux informations Kubernetes
Une fois l'agent déployé dans votre cluster, le détecteur Kubernetes fournit des données détaillées sur le cluster et les ressources qui y sont déployées.
Instana détecte et surveille automatiquement toutes les ressources en cours d'exécution dans le cluster d' Kubernetes :
- Clusters
- CronJobs
- Noeuds
- Espaces de nom
- Déploiements
- DaemonSets
- StatefulSets
- services
- Pods
Les informations Kubernetes sont facilement accessibles et solidement intégrées dans tous les aspects de votre application.
Kubernetes page
Cliquez sur « Platforms > Kubernetes » dans le menu de navigation de l'interface utilisateur d' Instana. Vous pourrez alors consulter les informations relatives à vos clusters et espaces de noms Kubernetes.
Tableaux de bord Kubernetes
Sur la page Kubernetes , cliquez sur un cluster ou un espace de nom. Vous pouvez voir les tableaux de bord Kubernetes qui présentent toutes les informations pour une certaine entité Kubernetes . On peut toujours accéder au contexte via le chemin de contexte. Dans la capture d'écran suivante, vous pouvez voir un espace de nom nommé "robot-shop" dans un cluster appelé "k8s-demo-cluster".
Les tableaux de bord Kubernetes sont structurés comme suit:
Récapitulatif affiche les informations les plus pertinentes pour une entité donnée. Ce tableau de bord commence par une ligne de statut qui affiche le statut et les informations associées, telles que l'âge. Dans la section suivante, vous pouvez voir les informations d'UC, de mémoire et de pod, qui fournissent les ressources consommées, y compris les pods. Les sections telles que Top Deployments et Top Pods de la capture d'écran suivante montrent des points de repère potentiels que vous souhaiterez peut-être consulter. La section Journaux présente le graphique de distribution des journaux pertinents pour cette entité, qui complète les métriques d'entité. Le graphique est interactif et permet de sélectionner et de mettre en évidence toutes les valeurs mesurées. Vous pouvez vous concentrer sur la période sélectionnée ou accéder à la section Analyser les incidents pour poursuivre le processus de traitement des incidents.
Détails (Details) affiche des informations détaillées telles que "libellés", "annotation" et "spécification".
Evénements (Events) affiche tous les événements Kubernetes pertinents et les associe aux tableaux de bord respectifs.
Entités associées telles que "Déploiements", "K8s Services" et "Pods" sont affichées sous forme d'onglets des tableaux de bord Kubernetes . Les éléments affichés dépendent de l'entité que vous avez sélectionnée.
Utilisation de l'UC et de la mémoire
Pour les pods, les déploiements, les services, les espaces de nom et les noeuds Kubernetes , vous pouvez afficher l'utilisation actuelle de l'UC et de la mémoire lorsqu'elle est comparée aux limites et aux demandes de l'UC et de la mémoire définies pour ces ressources.
Si elles sont disponibles, les informations d'utilisation sont calculées à partir des données collectées à partir de l'environnement d'exécution de conteneur qui exécute les conteneurs qui constituent les ressources.
Page Applications
Cliquez sur « Applications » dans le menu de navigation de l'interface utilisateur d' Instana, puis cliquez sur l'onglet « Applications » ou « Services ». Si le service ou l'application s'exécute sur un cluster d' Kubernetes, vous pouvez consulter les informations de contexte correspondantes dans l'onglet Infrastructure :
Pour les conteneurs, le pod et l'espace de nom sont affichés et directement liés ; pour les hôtes, le cluster et le noeud sont également affichés et liés.
Page Infrastructure
Cliquez sur « Infrastructure » dans le menu de navigation de l'interface utilisateur d' Instana. Dans la carte « Infrastructure », vous pouvez consulter les informations d' Kubernetes s dans la barre latérale, que ce soit pour l'hôte ou pour le conteneur que vous sélectionnez.
Vous pouvez utiliser Dynamic Focus pour filtrer les données. Par exemple, recherchez un déploiement spécifique dans un cluster. En outre, les mots clés entity.kubernetes.cluster.distribution et entity.kubernetes.cluster.managedBy permettent de rechercher un cluster Kubernetes par distribution et couche de gestion. Les valeurs prises en charge pour entity.kubernetes.cluster.distribution sont gke, eks, openshiftet kubernetes. Les valeurs admises pour entity.kubernetes.cluster.managedBy sont rancher et none.
Kubernetes Assistant IA
Vous pouvez utiliser l'assistant IA d' Kubernetes pour le dépannage des clusters d' Kubernetes. Posez des questions en langage naturel concernant l'état de santé du cluster, les problèmes liés aux pods, les ressources des espaces de noms et l'état du déploiement. Il comprend une bibliothèque de commandes prédéfinies et permet de générer des scripts d'automatisation ou des actions manuelles qui peuvent être enregistrés dans le catalogue d'actions afin de résoudre les incidents.
Avant d'utiliser l'assistant IA d' Kubernetes, assurez-vous que les conditions préalables suivantes sont remplies :
- SaaS Environnements : pour les environnements d' SaaS, Instana fournit des passerelles LLM par défaut. Aucune configuration supplémentaire n'est nécessaire pour utiliser cette fonctionnalité. Si nécessaire, vous pouvez configurer des passerelles distinctes pour votre propre environnement d'exécution. Pour plus d'informations, consultez le site SaaS.
Cette fonctionnalité utilise le drapeau de feature.kubernetes.ai.agent.enabledfonctionnalité, qui est activé (réglé sur « true ») par défaut.
- Environnements auto-hébergés : pour les éditions « Standard Edition » et «Custom Edition», vous devez configurer les passerelles LLM afin de pouvoir utiliser cette fonctionnalité. Pour plus d'informations, consultez la section « Auto-hébergé ».
Pour utiliser l'assistant IA, procédez comme suit :
- Dans la vue « Clusters » (Clusters) de l' Kubernetes, cliquez sur un cluster.
- Cliquez sur l'icône IA pour ouvrir l'interface de discussion. La fenêtre de discussion s'ouvre. Vous pouvez saisir vos requêtes en langage naturel ou utiliser la bibliothèque de prompts existante.
Analyse des appels d' Kubernetes
Unbounded Analytics vous offre des outils puissants pour analyser en détail chaque appel de votre cluster d' Kubernetes. Si vous cliquez sur Analyser les appels dans un tableau de bord Kubernetes , le filtre et le regroupement appropriés sont déjà définis. Dans ce cas, vous pouvez voir tous les appels dans l'espace de nom robot-shop qui sont regroupés par pods:
Analyse des journaux d' Kubernetes
Unbounded Analytics vous offre des outils puissants pour analyser en profondeur chaque journal de votre cluster d' Kubernetes. Si vous cliquez sur Analyser les journaux dans un tableau de bord Kubernetes , le filtrage approprié est déjà défini. Dans ce cas, vous pouvez voir tous les journaux dans l'espace de nom robot-shop comme suit:
Afin de fournir des informations pertinentes sans modifier le contexte, Instana enrichit les messages de journalisation avec des métadonnées relatives à l'infrastructure et à l' Kubernetes, qui s'affichent dans le tableau des balises une fois le message de journalisation développé. Voir le tableau de balises suivant:
Liaison des services Kubernetes et des services logiques
Liaison d'un service Kubernetes unique à plusieurs services logiques
Plusieurs services logiques peuvent être associés à un seul service Kubernetes lorsque les règles de mappage de service correspondent et que des appels sont générés sur ce service Kubernetes . Par exemple, un service de type « Kubernetes » avec le sélecteur de "service=my-service" balises pourrait contenir des pods dotés des balises "env=dev" supplémentaires et, "env=staging" associées à une configuration personnalisée de mappage de service dans Instana avec les balises kubernetes.container.namesuivantes : kubernetes.pod.label,, et key: env. Cela donne lieu à plusieurs services logiques qui sont associés à ce service « Kubernetes » unique et affichés sur le tableau de bord « Kubernetes Service ».
Liaison d'un service logique unique à plusieurs services Kubernetes
Plusieurs services Kubernetes peuvent être associés à un seul service logique lorsque ces services Kubernetes sont détruits et recréés au fil du temps. Par exemple, si le Kubernetes shop-service-a avec les appels générés est remplacé au fil du temps par shop-service-b avec les appels générés, les deux services sont affichés sur le tableau de bord du service logique lorsque la période sélectionnée chevauche les appels générés.
Affichage des mesures
Instana recueille des informations sur le cluster Kubernetes, CronJob, DaemonSet, le déploiement, la tâche, Kubernetes le service, l'espace de noms, le nœud, StatefulSet, l'Horizontal Pod Autoscaler, le volume persistant et la revendication de volume persistant.
Cluster
| Métrique | Description |
|---|---|
| Allocation de pods | Rapport entre les pods alloués et la capacité des pods |
| Allocation des demandes d'UC | Rapport entre les demandes d'UC et la capacité d'UC |
| Allocation des limites d'UC | Rapport entre les limites d'UC et la capacité d'UC |
| Allocation des demandes de mémoire | Rapport entre les demandes de mémoire et la capacité de mémoire |
| Allocation des limites de mémoire | Rapport entre les limites de mémoire et la capacité de mémoire |
| Demandes d'UC | Demandes d'UC agrégées de tous les conteneurs en cours d'exécution |
| Limites d'UC | Limites d'UC agrégées de tous les conteneurs en cours d'exécution |
| Capacité d'UC | Capacité d'UC agrégée de tous les nœuds |
| Demandes de mémoire | Demandes de mémoire agrégées de tous les conteneurs en cours d'exécution |
| Limites de mémoire | Limites de mémoire agrégées de tous les conteneurs en cours d'exécution |
| Capacité de mémoire | Capacité de mémoire agrégée de tous les nœuds |
| Pods en cours d'exécution | Nombre de tous les pods en cours d'exécution dans ce cluster |
| Pods en attente | Nombre de tous les pods en attente dans ce cluster |
| Pods alloués | Nombre de tous les pods alloués dans ce cluster |
| Capacité des pods | Capacité des pods agrégée de tous les nœuds |
| Nœuds à court d'espace disque | Nombre de nœuds à court d'espace disque dans le cluster |
| Nœuds avec dépassement de mémoire | Nombre de nœuds avec dépassement de mémoire dans le cluster |
| Nœuds avec dépassement de disque | Nombre de nœuds avec dépassement de disque dans le cluster |
| Nœuds pour lesquels Kubelet est désactivé | Nombre de nœuds kubelet dont l'état est « Ready=False » dans ce cluster |
| Nœuds Kubelet pas prêts | Nombre de nœuds kubelet dont le statut est « Ready=Unknown » ou « Ready=False » dans ce cluster |
| Répliques disponibles | Répliques disponibles à partir de tous les déploiements |
| Répliques souhaitées | Répliques souhaitées à partir de tous les déploiements |
| Nombre de nœuds | Nombre de nœuds dans ce cluster |
CronJob
| Métrique | Description |
|---|---|
| Durée du dernier travail | Durée de la dernière exécution du travail |
| Travaux actifs | Nombre de travaux actifs |
| Heure du dernier travail planifié | Depuis combien de temps un travail pour ce cronjob a été planifié |
DaemonSet
| Métrique | Description |
|---|---|
| Répliques disponibles | Nombre de répliques disponibles |
| Répliques souhaitées | Nombre de répliques souhaitées |
| Répliques disponibles | Nombre de répliques non disponibles |
| Répliques planifiées incorrectement | Nombre de répliques planifiées incorrectement |
| Rapport entre les répliques désirées et les répliques souhaitées | Rapport entre les répliques désirées et les répliques souhaitées |
Déploiement
| Métrique | Description |
|---|---|
| Répliques disponibles | Nombre de répliques disponibles |
| Répliques souhaitées | Nombre de répliques souhaitées |
| Rapport entre les répliques désirées et les répliques souhaitées | Rapport entre les répliques désirées et les répliques souhaitées |
| Pods en attente | Nombre de pods en attente |
| Pods non planifiés | Nombre de pods non planifiés |
| Pods non prêts | Nombre de pods non prêts |
| Durée de la phase d'attente | Durée de la phase en attente |
| Nombre de pods | Nombre de pods de ce déploiement |
| Demandes de mémoire | Demandes de mémoire agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
| Limites de mémoire | Limites de mémoire agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
| Demandes d'UC | Demandes d'UC agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
| Limites d'UC | Limites d'UC agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
Travail
| Métrique | Description |
|---|---|
| Pods actifs | Nombre de pods actif dans ce travail |
| Pods ayant échoué | Nombre de pods ayant échoué dans ce travail |
| Pods ayant abouti | Nombre de pods ayant abouti dans ce travail |
| Durée du travail | Durée de l'exécution du travail |
Service Kubernetes
| Métrique | Description |
|---|---|
| Demandes d'UC | Demandes d'UC agrégées pour ce service |
| Limites d'UC | Limites d'UC agrégées pour ce service |
| Demandes de mémoire | Demandes de mémoire agrégées pour ce service |
| Limites de mémoire | Limites de mémoire agrégées pour ce service |
Espace de nom
| Métrique | Description |
|---|---|
| Capacité des demandes de mémoire | Mémoire maximale prise en charge pour les demandes de mémoire sur cet espace-noms |
| Demandes de mémoire utilisées | Quantité de mémoire allouée aux demandes de mémoire utilisées |
| Capacité des limites de mémoire | Mémoire maximale prise en charge pour les limites de mémoire sur cet espace-noms |
| Limites de mémoire utilisées | Quantité de mémoire allouée aux limites de mémoire utilisées |
| Capacité des demandes d'UC | Nombre maximal d'UC prises en charge pour les demandes d'UC sur cet espace-noms |
| Demandes d'UC utilisées | Quantité d'UC allouée aux demandes d'UC utilisées |
| Capacité des limites d'UC | Nombre maximal d'UC prises en charge pour les limites d'UC sur cet espace-noms |
| Limites d'UC utilisées | Quantité d'UC allouée aux limites d'UC utilisées |
| Pods utilisés | Nombre de pods utilisés pour cet espace de nom |
| Capacité des pods | Nombre de pods l'espace-noms peut prendre |
| Allocation de pods utilisés | Rapport entre les pods utilisés et la capacité des pods |
| Allocation des demandes d'UC | Rapport entre les demandes d'UC et la capacité d'UC |
| Allocation des limites d'UC | Rapport entre les limites d'UC et la capacité d'UC |
| Allocation des demandes de mémoire | Rapport entre les demandes de mémoire et la capacité des demandes de mémoire |
| Allocation des limites de mémoire | Rapport entre les limites de mémoire et la capacité des limites de mémoire |
| Allocation de pods | Rapport entre les pods alloués et la capacité de pod |
Noeud
| Métrique | Description |
|---|---|
| Pods alloués | Nombre de pods alloués sur ce nœud |
| Capacité des pods | Nombre de pods que le nœud peut prendre |
| Demandes de mémoire | Demandes de mémoire agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
| Limites de mémoire | Limites de mémoire agrégées de tous les conteneurs en cours d'exécution de cette configuration de déploiement |
| Capacité de mémoire | Mémoire maximale prise en charge sur ce nœud |
| Demandes d'UC | Demandes d'UC agrégées de tous les conteneurs en cours d'exécution sur ce nœud |
| Limites d'UC | Limites d'UC agrégées de tous les conteneurs en cours d'exécution sur ce nœud |
| Capacité d'UC | Nombre maximal d'UC prises en charge sur ce nœud |
| Allocation de pods | Rapport entre les pods alloués et la capacité de pod |
| Allocation des demandes d'UC | Rapport entre les demandes d'UC et la capacité d'UC |
| Allocation des limites d'UC | Rapport entre les limites d'UC et la capacité d'UC |
| Allocation des demandes de mémoire | Rapport entre les demandes de mémoire et la capacité de mémoire |
| Allocation des limites de mémoire | Rapport entre les limites de mémoire et la capacité de mémoire |
Pod
| Métrique | Description |
|---|---|
| Nombre de conteneurs | Nombre de conteneurs pour ce pod |
| Demandes d'UC | Demandes d'UC agrégées sur tous les conteneurs de ce nœud |
| Limites d'UC | Limites d'UC agrégées sur tous les conteneurs de ce nœud |
| Demandes de mémoire | Demandes de mémoire agrégées sur tous les conteneurs de ce nœud |
| Limites de mémoire | Limites de mémoire agrégées sur tous les conteneurs de ce nœud |
| Nombre de redémarrages | Redémarrages agrégés sur tous les conteneurs de cet nœud |
StatefulSet
| Métrique | Description |
|---|---|
| Répliques disponibles | Nombre de répliques disponibles |
| Répliques souhaitées | Nombre de répliques souhaitées |
| Rapport entre les répliques désirées et les répliques souhaitées | Pourcentage disponible pour les répliques souhaitées |
Autoscalers de pods horizontaux (HPA)
Pour activer spécifiquement le HPA pour les instances « Next Generation » d' K8sensor, consultez la section « Activation de l'autoscaling (HPA) pour les instances « k8sensor » (solution de contournement) ».
Les indicateurs suivants concernant l'HPA sont disponibles :
| Métriques | Description |
|---|---|
| Répliques en cours | Nombre de répliques disponibles |
| Répliques souhaitées | Nombre de répliques souhaitées |
| Nombre maximal de répliques | Le nombre maximal de répliques jusqu'auquel l'autoscaler peut augmenter la capacité |
| Nombre minimal de répliques | Le nombre minimum de répliques jusqu'auquel l'autoscaler peut réduire la capacité |
| Répliques actuelles / Nombre maximal de répliques | Rapport entre le nombre actuel de répliques et le nombre maximal de répliques |
| Répliques actuelles / Nombre minimum de répliques | Rapport entre le nombre actuel de répliques et le nombre minimum de répliques |
| Observed Generation | La dernière génération de répliques prise en compte par l'autoscaler |
Vous pouvez surveiller les autoscalers de pods horizontaux (HPA) à l'aide de la fonction d'infrastructure analytique. Pour plus d'informations, consultez la section « Analyser l'infrastructure ». Sur la page « Analyser l'infrastructure », vous pouvez rechercher les Horizontal Pod Autoscalers et consulter leur nombre total. 
Pour consulter la liste des HPA, sélectionnez « Kubernetes Horizontal Pod Autoscalers » dans la liste des types d'infrastructure. 
Vous pouvez créer des alertes intelligentes pour les mesures liées à l'HPA. Pour plus d'informations, consultez la section « Alertes intelligentes ». Vous pouvez créer des alertes intelligentes à partir des indicateurs HPA suivants : nombre actuel de répliques, nombre souhaité de répliques, nombre maximal de répliques, nombre de messages et nombre minimal de répliques. 
Vous pouvez configurer des alertes en fonction de l'utilisation des répliques pour les indicateurs suivants :
Current Replicas / Maximum ReplicasCurrent Replicas / Minimum Replicas
Par exemple, si Current Replicas l'indicateur atteint 80 % de sa Maximum Replicas valeur, 0.8 celle-ci Current Replicas / Maximum Replicas peut alors déclencher une alerte. De même, si Current Replicas l'indicateur atteint 100 % de sa Minimum Replicas valeur, 1.0 celle-ci Current Replicas / Minimum Replicas peut déclencher une alerte.
Volume persistant (PV)
Le tableau suivant répertorie les indicateurs disponibles liés à la production photovoltaïque :
| Métriques | Description |
|---|---|
| Nom de classe de stockage | Nom de StorageClass l'objet utilisé pour créer ce PV |
| Capacité totale ( GiB ) | Capacité totale du parc photovoltaïque d' GiB |
| Capacité utilisée ( GiB ) | Capacité photovoltaïque exploitée à l' GiB |
| Utilisation | Rapport entre la capacité utilisée de l'installation photovoltaïque et sa capacité totale, exprimé en pourcentage |
| Phase | Phase actuelle du PV, qui peut être Available, Bound, Released, ou Failed |
| Mode d'accès | Mode d'accès au PV |
Surveillance des installations photovoltaïques
Pour surveiller un PV, procédez comme suit dans l'interface utilisateur d' Instana :
Dans le menu de navigation, sélectionnez Infrastructure.
Dans le tableau de bord Infrastructure, cliquez sur « Analyser l'infrastructure ».
Dans le tableau de bord « Analyze Infrastructure », recherchez le volume persistant « Kubernetes » et consultez le nombre total, comme indiqué dans l'image suivante :
Pour afficher la liste des volumes persist ants, sélectionnez « Volume persistant d' Kubernetes » dans la liste des types d'infrastructure, comme illustré dans l'image suivante :
Pour consulter les indicateurs d'un PV, sélectionnez-le dans la liste. Vous pouvez consulter la liste des indicateurs PV avec leur type et leur valeur actuelle.
Configurer une alerte intelligente pour le photovoltaïque
Pour configurer une alerte intelligente pour les indicateurs PV, procédez comme suit dans l'interface utilisateur d' Instana :
Dans le menu de navigation, sélectionnez Infrastructure > Alertes intelligentes > Créer une alerte intelligente.
Dans la fenêtre « Créer une alerte intelligente », sélectionnez l'un des indicateurs de puissance apparente disponibles, tel que « % de capacité utilisée », puis appliquez un filtre en fonction de l'entité souhaitée.
Pour plus d'informations sur la configuration des alertes intelligentes, consultez la section « Alertes intelligentes ».
Prise en charge des classes de stockage
Instana prend en charge les classes de stockage les plus courantes proposées par la plupart des fournisseurs de services cloud, tant pour l'allocation statique que pour l'allocation dynamique. Le tableau de compatibilité ci-dessous présente les différentes classes de stockage dont la prise en charge a été vérifiée.
| Fournisseur de cloud | Nom | Fournisseur | Support |
|---|---|---|---|
| GCP | PersistentDisk | pd.csi.storage.gke.io | ✅ |
| GCP | Hyperdisk | pd.csi.storage.gke.io | ✅ |
| GCP | Compartiment | gcsfuse.csi.storage.gke.io | ✅ |
| GCP | fileStore | filestore.csi.storage.gke.io | ✅ |
| AWS | Elastic Block Storage (EBS) | ebs.csi.aws.com | ✅ |
| AWS | File Storage d'Elastic ( EFS ) | efs.csi.aws.com | ✅ |
| AWS | Amazon FSx / Amazon File Cache | filecache.csi.aws.com | ✅ |
| AWS | S3 | s3.csi.aws.com | ✅ |
| Azure | CSI géré | disk.csi.azure.com | ✅ |
| Azure | CSI Premium géré | disk.csi.azure.com | ✅ |
| Azure | CSI Azure File | file.csi.azure.com | ✅ |
| Azure | Azure File CSI Premium | file.csi.azure.com | ✅ |
| IBM | Block Storage | vpc.block.csi.ibm.io | ✅ |
| IBM | File Storage | vpc.file.csi.ibm.io | ✅ |
| IBM | Cloud Object Storage | ibm.io/ibmc-s3fs | ✅ |
| Openshift | Ceph RBD Block Storage | openshift-storage.rbd.csi.ceph.com | ✅ |
| Openshift | CephFS | openshift-storage.cephfs.csi.ceph.com | ✅ |
| Openshift | Ceph RGW | openshift-storage.object.csi.ceph.com | ✅ |
| Openshift | Nooba | openshift-storage.noobaa.io/obc | ✅ |
Réservation de volume persistant (PVC)
Le tableau suivant répertorie les indicateurs disponibles liés au PVC :
| Métriques | Description |
|---|---|
| Capacité totale ( GiB ) | Capacité totale de l'usine de PVC d' GiB |
| Capacité utilisée ( GiB ) | Capacité de production de PVC utilisée à l' GiB |
| Utilisation | Rapport entre la capacité utilisée du PVC et sa capacité totale, exprimé en pourcentage |
| Phase | Phase actuelle du PVC, qui peut être Available, Bound, Released, ou Failed |
| Mode d'accès | Mode d'accès au PVC |
Tant que le PVC est associé à un PV, la plupart des indicateurs affichés sont les mêmes que ceux disponibles pour le PV correspondant.
Surveillance du PVC
Pour surveiller un PVC, procédez comme suit dans l'interface utilisateur d' Instana :
Dans le menu de navigation, sélectionnez Infrastructure.
Dans le tableau de bord Infrastructure, cliquez sur « Analyser l'infrastructure ».
Dans le tableau de bord « Analyze Infrastructure », recherchez le volume persistant « Kubernetes » et consultez le nombre total, comme indiqué dans l'image suivante :
Pour afficher la liste des PVC, sélectionnez « Kubernetes : Persistent Volume Claim » dans la liste des types d'infrastructure, comme illustré dans l'image suivante :
Pour consulter les indicateurs relatifs à un PVC, sélectionnez-le dans la liste des PVC. Vous pouvez consulter une liste des indicateurs PVC avec leur type et leur valeur.
Configurer une alerte intelligente pour le PVC
Pour configurer une alerte intelligente pour les métriques PVC, procédez comme suit dans l'interface utilisateur d' Instana :
Dans le menu de navigation, sélectionnez Infrastructure > Alertes intelligentes > Créer une alerte intelligente
Dans la fenêtre « Créer une alerte intelligente », sélectionnez l'un des indicateurs de puissance apparente disponibles, tel que « Capacité utilisée en % », puis appliquez un filtre en fonction de l'entité souhaitée.
Pour plus d'informations sur la configuration des alertes intelligentes, consultez la section « Alertes intelligentes ».
Pour en savoir plus sur la surveillance des extrasystoles ventriculaires (PV) et des extrasystoles auriculaires (PVC), ainsi que sur son utilité, consultez l 'article de blog « Demystifying PVCs and PVs » (Tout savoir sur les PVC et les PV) sur IBM.
Surveillance du plan de contrôle
Instana offre des fonctionnalités de surveillance complètes pour les composants du plan de contrôle d' Kubernetes, vous permettant ainsi de bénéficier d'une visibilité approfondie sur l'état et les performances de l'infrastructure centrale de votre cluster. La surveillance du plan de contrôle vous aide à identifier les goulots d'étranglement, à résoudre les problèmes et à garantir la fiabilité de votre environnement d' Kubernetes.
- API Serveur : interface utilisateur du plan de contrôle d' Kubernetes, qui met à disposition l'interface Kubernetes API.
- Planificateur : affecte les pods aux nœuds en fonction des besoins en ressources et des contraintes.
- Etcd : base de données clé-valeur distribuée qui stocke toutes les données du cluster.
- Gestionnaire de contrôleurs : exécute les processus de contrôle qui régulent l'état du cluster.
Accéder à la surveillance du plan de contrôle dans l'interface utilisateur
- Dans le menu de navigation, sélectionnez « Platforms » > « Kubernetes ».
- Sélectionnez votre cluster dans la liste.
- Accédez à l'onglet « Control plane » sur le tableau de bord du cluster.
Le tableau de bord du plan de contrôle affiche les indicateurs en temps réel et les tendances historiques pour tous les composants surveillés.
Informations de débogage
Lorsque vous consultez un cluster d' Kubernetes s dans l'interface utilisateur d' Instana, l'onglet « Control Plane » affiche des informations de débogage qui fournissent des détails sur l'état de surveillance et la configuration du cluster. Ces informations vous aident à comprendre l'état actuel de la surveillance et à résoudre les problèmes.
- Couverture de l'hôte
La couverture des hôtes indique le pourcentage de nœuds de votre cluster d' Kubernetes s sur lesquels l'agent d' Instana est installé et qui transmettent activement des données. Cet indicateur est calculé en divisant le nombre de nœuds surveillés par le nombre total de nœuds du cluster.
Par exemple, si vous voyez « 3 sur 6 - 50.0 % », cela signifie :- Trois nœuds sur lesquels l'agent Instana est installé font l'objet d'une surveillance.
- Le cluster compte au total 6 nœuds.
- 50 % des nœuds de votre cluster sont couverts par la surveillance.
Un faible pourcentage de couverture des hôtes pourrait indiquer :- Conformément à la configuration fournie, les agents ne sont délibérément pas installés sur les nœuds. Cela concerne en particulier les nœuds du plan de contrôle, mais peut également affecter d'autres nœuds présentant des taints. Pour plus d'informations, consultez la section « Déploiement et planification des agents ».
- Certains agents ne fonctionnent pas ou rencontrent des problèmes de connexion.
- Les nœuds qui ont été récemment ajoutés au cluster et les agents n'ont pas encore été déployés.
Pour améliorer la couverture des hôtes, assurez-vous que l'agent d' Instana s est correctement installé sur les nœuds concernés de votre cluster. Pour plus d'informations, consultez la section « Installation de l'agent d' Instana » sur Kubernetes.
- UUID de cluster
L'UUID du cluster est un identifiant unique attribué à votre cluster Kubernetes. Cet identifiant est utilisé en interne par Instana pour distinguer les différents clusters et mettre en corrélation les données de surveillance. L'UUID est généré automatiquement et reste inchangé pendant toute la durée de vie du cluster.
- Moniteur d'agent
Le champ « Agent monitor » affiche le nom ou l'identifiant de l'agent d' Instana s chargé de surveiller les composants du plan de contrôle d' Kubernetes. Ces informations sont utiles pour résoudre les problèmes spécifiques à un agent ou pour vérifier quelle instance d'agent collecte les métriques du plan de contrôle.
- Version du capteur K8s
La version du capteur « K8s » indique la version du capteur « Kubernetes » actuellement déployée dans votre cluster. Le capteur « Kubernetes » est chargé de collecter les métadonnées et les indicateurs provenant du serveur Kubernetes API.
Le numéro de version vous permet de vérifier que vous utilisez bien la dernière version prise en charge. Pour plus d'informations sur les capteurs d' Kubernetes s et sur la manière de vérifier leur état, consultez la page Kubernetes sensors.
- Accéder aux informations de débogagePour consulter les informations de débogage du cluster « Kubernetes » via l'interface utilisateur d' Instana
- Dans le menu de navigation de l'interface utilisateur d' Instana, sélectionnez ».
- Dans l'onglet « Clusters » (en mode tableau ou en mode fiches), cliquez sur le nom du cluster pour ouvrir le tableau de bord correspondant.
- Dans le tableau de bord du cluster, cliquez sur l'onglet « Control Plane ».
- Les détails des informations de débogage s'affichent à la fin de la liste des détails du plan de contrôle.
Règles d'intégrité
Intégré
Il existe quelques règles de santé intégrées qui déclenchent un problème pour les entités Kubernetes .
- Cluster
- Kubernetes signale qu'un composant principal (serveur API, planificateur et gestionnaire de contrôleurs) présente un dysfonctionnement. Instana filtre l'état de santé du composant maître, sans déclencher d'alerte, mais en affichant uniquement cet état sur la page de détails du cluster.
- Noeud
- L'unité centrale demandée approche de la capacité maximale. Le rapport entre la capacité de l'unité centrale demandée et la capacité de l'unité centrale est supérieur à 80%.
- La mémoire demandée approche de la capacité maximale. Le rapport de capacité mémoire / mémoire demandé est supérieur à 80%.
- Les pods alloués approchent de la capacité maximale. Le rapport entre la capacité des pods alloués et celle des pods est supérieur à 80%. Pour un noeud, les pods des phases'En cours d'exécution'et'Inconnu'sont comptabilisés comme étant alloués. Pour plus d'informations sur la capacité des noeuds, voir la documentationKubernetes.
- Le noeud signale une condition qui n'est pas prête pendant plus d'une minute et toutes les conditions de ce noeud dépassent la condition "Prêt". Pour plus d'informations sur toutes les conditions des nœuds, consultez la documentation de Kubernetes.
- Espace de nom
- L'unité centrale demandée approche de la capacité maximale. Le rapport entre la capacité de l'unité centrale demandée et la capacité de l'unité centrale est supérieur à 80%.
- La mémoire demandée approche de la capacité maximale. Le rapport de capacité mémoire / mémoire demandé est supérieur à 80%.
- Les pods alloués approchent de la capacité maximale. Le rapport entre la capacité des pods alloués et celle des pods est supérieur à 80%. Pour un espace de nom, les pods dans les phases'En attente','En cours d'exécution'et'Inconnu'sont comptabilisés comme alloués. Les valeurs de capacité d'espace de nom sont basées sur des ResourceQuotas qui peuvent être définis par espace de nom. Pour plus d'informations, voir la documentationKubernetes.
- Déploiement
- Les répliques disponibles sont inférieures aux répliques souhaitées.
- Pod
- Un pod doit être prêt dans la minute qui suit son déploiement, mais s'il n'est pas prêt dans la minute qui suit, ce n'est pas parce qu'il a terminé sa tâche (PodCondition=Ready, Status=False, Reason!= PodCompleted). Pour plus d'informations sur toutes les conditions relatives aux pods, consultez la documentation sur Kubernetes.
Personnalisé
En plus des règles intégrées, vous pouvez également créer des règles personnalisées sur les métriques d'un cluster, d'un espace de nom, d'un déploiement et d'un pod. Par exemple, si le seuil déclenchant les alertes de capacité des nœuds est trop élevé, vous pouvez les désactiver et créer une règle personnalisée avec une valeur de seuil inférieure. Pour plus d'informations, consultez la section « Configuration des événements et des incidents ».
Contrôle d'accès basé sur les rôles (RBAC) requis pour l'installation de l'agent d' Instana
L'opérateur d'agent d' Instana s installe et gère trois composants principaux. Chaque composant nécessite des autorisations RBAC spécifiques pour surveiller votre cluster d' Kubernetes :
Instana opérateur
L'opérateur doit disposer de droits à l'échelle du cluster pour effectuer les tâches suivantes :
- Gérer les déploiements d'agents : créer et mettre à jour les déploiements d' DaemonSets,, les secrets d' ConfigMaps, et les ServiceAccounts dans tous les espaces de noms.
- Configurer le RBAC : créer les rôles « ClusterRoles » et « ClusterRoleBindings » pour les composants « agent » et « k8sensor ».
- Gérer les ressources personnalisées d' Instana : créer, mettre à jour et supprimer les ressources personnalisées de l'agent Instana (
agents.instana.ioetagentsremote.instana.io) à l'aide de finaliseurs pour assurer un nettoyage correct. - Garantir une haute disponibilité : gérez l' PodDisruptionBudgets e de l' k8sensor e afin d'éviter toute interruption pendant la maintenance du cluster.
- Découvrez les ressources du cluster : consultez les ressources à l'échelle du cluster, telles que les nœuds, les espaces de noms, les pods et les services, afin de configurer correctement les agents.
- etcd de Monitor ( OpenShift ) : copiez les certificats et la configuration de etcd de l'espace
openshift-etcdde noms versinstana-agentl'espace de noms pour la collecte des métriques. - Accéder aux métriques de kubelet : consultez les URL non liées aux ressources (
/metrics,/stats/summary, et/healthz) pour vérifier l'état de santé du cluster. - Enregistrer les événements : Créez des événements pour assurer la visibilité opérationnelle et faciliter le dépannage.
- Élection du leader : gérez les baux dans l'espace de noms de l'opérateur pour assurer une haute disponibilité lorsque vous exécutez plusieurs répliques d'opérateur.
- Surveiller les points de terminaison des services : consultez la page EndpointSlices
discovery.k8s.iopour suivre les modifications apportées aux points de terminaison des services et vous assurer que les agents peuvent détecter dynamiquement les services backend.
Instana agent ( DaemonSet )
Les modules d'agent ont besoin d'autorisations pour effectuer les tâches suivantes :
- Collecter les métriques des nœuds : accéder aux points de terminaison des métriques kubelet sur chaque nœud, tels que
/metrics,/stats/summary, et/metrics/cadvisor. - Surveiller les pods : consulter les informations et les métriques relatives aux pods dans tous les espaces de noms.
- Exécuter un accès privilégié : utilisez des contextes de sécurité privilégiés pour activer la surveillance au niveau de l'hôte.
K8Sensor (déploiement)
L' k8sensor e a besoin d'autorisations en lecture seule pour effectuer les tâches suivantes :
- Surveiller toutes les ressources d' Kubernetes : lire tous les types de ressources, tels que les pods, les déploiements, les services, les ConfigMaps, et autres, à l'échelle du cluster pour une surveillance complète.
- Surveiller les ressources personnalisées : détecter et surveiller les définitions de ressources personnalisées (CRD).
- Surveiller les charges de travail : suivez tous les types de charges de travail, notamment DaemonSets,, StatefulSets, Jobs, CronJobs, et HorizontalPodAutoscalers.
- Surveillance du réseau : consulter les ressources Ingress et les politiques réseau.
- Découvrez les points de terminaison d' etcd : consultez les services et les points de terminaison dans l'espace
kube-systemde noms pour identifier les points de terminaison etcd destinés à la collecte de métriques. - Consultez les ressources d' OpenShift : lisez « DeploymentConfigs » et d'autres ressources d' OpenShift-specific ( OpenShift uniquement).
- Exécuter un accès privilégié ( OpenShift ) : utilisez des contraintes de contexte de sécurité (SCC) privilégiées sur OpenShift pour une surveillance complète.
- Suivi de la topologie des services : consultez la page EndpointSlices
discovery.k8s.iopour surveiller la répartition des points de terminaison des services au sein du cluster et obtenir une cartographie complète de la topologie du réseau.
Pour plus d'informations sur les rôles et autorisations spécifiques à ClusterRoles, créés lors de l'installation, consultez le référentiel de graphiques Helm sur Instana.
Contrôle d'accès basé sur les rôles (RBAC) requis pour le webhook « AutoTrace »
Le webhook Instana AutoTrace est un composant distinct de l'installation de l'agent Instana. Le webhook fonctionne avec deux composants, chacun ayant des exigences de sécurité spécifiques et des autorisations RBAC :
Pod de webhook en cours de mise à jour
Le pod Webhook s'exécute en tant que service hautement restreint et sans privilèges qui intercepte les demandes de création de pods. Pour effectuer les tâches suivantes, des autorisations au niveau du cluster sont requises :
- Lire les certificats TLS : accédez aux informations d'identification pour lire les certificats TLS destinés au point de terminaison du webhook HTTPS.
- Gérer les secrets de récupération d'images : créez des secrets de récupération d'images dans les espaces de noms cibles lorsque vous utilisez des registres privés.
- Lire la configuration : accéder aux secrets et aux ConfigMaps s référencés dans les variables d'environnement du conteneur.
- Gérer la configuration d' NGINX : créer et mettre à jour ConfigMaps pour l'intégration du traçage des entrées d' NGINX.
- Définir le périmètre de l'instrumentation : lire les espaces de noms et vérifier les étiquettes de ces espaces pour déterminer la logique d'activation ou de désactivation.
- Respecter les politiques de sécurité des pods : utilisez PodSecurityPolicies sur les versions d' Kubernetes antérieures à 1.25 lorsque le contrôleur d'admission PSP est activé.
Le pod Webhook fonctionne avec les restrictions de sécurité suivantes :
- S'exécute en tant qu'utilisateur non root (UID 1001) sans privilèges étendus
- Impossible d'élever les privilèges
- Toutes les fonctionnalités d' Linux s sont supprimées
- Utilise le profil seccomp de RuntimeDefault pour restreindre l'accès aux appels système
- Système de fichiers racine en lecture seule pour empêcher toute modification
Conteneur d'initialisation de l'instrumentation
Le webhook injecte le conteneur d'initialisation dans les pods de l'application afin de copier les fichiers d'instrumentation dans un volume partagé. Il ne nécessite aucune autorisation particulière et fonctionne selon les caractéristiques de sécurité suivantes :
- Hérite du contexte de sécurité du pod : utilise par défaut le contexte de sécurité du pod de l'application.
- Pas de mode privilégié : s'exécute sans privilèges élevés.
- Aucune capacité Linux requise : Ne nécessite aucune capacité particulière.
- Pas d'accès au niveau de l'hôte : ne nécessite pas
hostPIDd'accèshostIPC,hostNetwork, ou. - Écriture sur les volumes d' emptyDir : écrit uniquement sur les
emptyDirvolumes partagés, et non sur le système de fichiers de l'hôte.
Le pod Webhook et le conteneur d'initialisation d'instrumentation sont tous deux entièrement conformes à la norme de sécurité des pods restreints de l' Kubernetes, qui constitue le profil de sécurité le plus restrictif.
Pour plus d'informations sur l'installation et la configuration du webhook « AutoTrace », consultez la page InstanaAutoTrace webhook.
Suivi de l' Java, via Istio ou OpenShift ServiceMesh
Surveiller à l'aide de agent.serviceMesh.enabled l'option
Vous pouvez activer la surveillance de l'agent d' InstanaJava avec les maillages de services Istio et OpenShift à l'aide du agent.serviceMesh.enabled drapeau. Cette approche native d' Kubernetes utilise un seul port réseau dédié pour toutes les charges de travail d' Java s surveillées sur un seul hôte ou nœud. La valeur par défaut est true. Pour plus d'informations sur ce paramètre de configuration, consultez la section « Configuration des graphiques » sur Helm.
Si le paramètre de configuration « Istio » est défini sur REGISTRY_ONLY, des étapes supplémentaires sont nécessaires pour que le service de socket de l'agent fonctionne correctement.
Vous devez déployer la définition de ressource suivante pour chaque noeud de cluster individuel. Veillez à définir une propriété metadata.name unique pour chaque hôte ou noeud. Définissez également la valeur de spec.hosts sur <node-ip-address>.instana-agent-headless.instana-agent.svc, où <node-ip-address> est l'adresse IP du noeud.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: instana-agent-worker-<node-unique-counter>
spec:
hosts:
- <node-ip-address>.instana-agent-headless.instana-agent.svc
ports:
- number: 42699
name: agent
protocol: TCP
resolution: DNS
location: MESH_EXTERNAL
Surveillance à l'aide du contournement du maillage de services (obsolète)
L'approche alternative existante consiste à activer le contournement du maillage de service. L'installation par défaut d' Istio est immédiatement compatible avec Instana. Si vous déployez Istio avec une politique de refus par défaut (mode: REGISTRY_ONLY), vous pouvez activer le contournement du maillage de services d' Instana en utilisant la configuration d'agent suivante :
com.instana.container:
serviceMesh:
enableServiceMeshBypass: true
Le paramètre ignore la connectivité du réseau bloquée de deux manières différentes:
- Autorisez le trafic sortant du pod d'application vers l'agent hôte (sur toutes les adresses IPv4 sur lesquelles l'agent est à l'écoute et sur tous les ports).
- Autoriser le trafic entrant vers le pod de l'application en provenance de l'agent pour les applications d' JVM (depuis toutes les adresses ipv4 sur lesquelles l'agent hôte est à l'écoute, sur tous les ports).
Débogage de la fonction permettant d'ignorer le maillage de services
Pour déboguer le passage du maillage de service, procédez comme suit:
- Vérifiez que le contournement du maillage de service est activé.
- Vérifiez que les règles iptable sont appliquées au conteneur.
Vérifier si la fonction est activée
Pour vérifier si le contournement du maillage de services est activé, consultez les journaux de l'agent « Instana » en exécutant la commande suivante :
kubectl logs -l app.kubernetes.io/instance=instana-agent -n instana-agent -c instana-agent
Si le contournement du maillage de service est activé, vous pouvez trouver les lignes de journal suivantes, qui indiquent qu'une entrée de contournement entrante ou sortante est écrite pour le processus indiqué:
Par transfert entrant:
2021-04-26T08:13:57.065+0000 | INFO | -client-thread-2 | DefaultServiceMeshSupport | 51 - com.instana.agent - 1.1.597 | Applying inbound service mesh bypass for process '764670'
Par-passe sortant:
2021-04-26T08:13:57.140+0000 | INFO | -client-thread-2 | DefaultServiceMeshSupport | 51 - com.instana.agent - 1.1.597 | Applying outbound service mesh bypass for process '764670'
Vérifier les règles iptable
La manière la plus simple de vérifier les règles iptables consiste à se connecter via un terminal à l'agent « Instana » et à afficher les règles iptables du conteneur cible comme suit. Remplacez ${PID} par le PID du processus « JVM » :
kubectl -n instana-agent exec -it ${INSTANA_AGENT_POD} -c instana-agent -- /bin/bash
nsenter -n -t ${PID} iptables -t nat -n -L INSTANA_OUTPUT
Si les chaînes sont appliquées, vous pouvez voir une sortie comme suit:
Chain INSTANA_OUTPUT (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 10.128.15.237
ACCEPT tcp -- 0.0.0.0/0 10.64.0.1
ACCEPT tcp -- 0.0.0.0/0 169.254.123.1
Vérifiez si la communication bidirectionnelle entre l'agent Instana et vos processus JVM est prise en charge en exécutant la commande suivante :
nsenter -n -t ${PID} iptables -t nat -n -L INSTANA_INBOUND
Le résultat est similaire à la sortie suivante:
Chain INSTANA_INBOUND (1 references)
target prot opt source destination
ACCEPT tcp -- 10.128.15.237 10.64.0.14
ACCEPT tcp -- 10.64.0.1 10.64.0.14
ACCEPT tcp -- 169.254.123.1 10.64.0.14
Selon le moment où les règles iptables ont été appliquées, l'instrumentation du processus et l'affichage des données dans les tableaux de bord d' Instana peuvent prendre quelques minutes.
Remarques sur le dépannage
Pourquoi est-ce que je ne vois aucun cluster ou espace de nom Kubernetes ?
Si aucun cluster ou espace de nom n'est répertorié sur la page Kubernetes , cela signifie qu'aucun cluster n'est activement surveillé car un agent n'est pas installé ou qu'aucun cluster n'est surveillé pendant la période sélectionnée.
Cliquez sur « Live » pour vérifier la présence de clusters et d'espaces de noms en mode live. Si aucun n'apparaît dans la liste, vous devez installer l'agent Instana dans Kubernetes.
Droits ClusterRole manquants
Type de problème de surveillance : kubernetes_missing_permissions
L'agent Instana requiert les droits ClusterRole appropriés pour que des ressources spécifiques puissent surveiller correctement un cluster Kubernetes. Si ces autorisations font défaut, les ressources correspondantes ne s'affichent pas sur les tableaux de bord de Instana Kubernetes. Pour résoudre ce problème, installez la dernière version d' Instana Agent YAML, d' Helm Chart ou d' Operator. Pour plus d'informations sur la dernière version de chaque méthode d'installation, consultez Kubernetes ou OpenShift.
Surveillance des ressources personnalisées
Pour surveiller les ressources personnalisées (CR) d' Kubernetes, vous devez créer une ClusterRole ressource comportant des règles spécifiques qui accordent les autorisations nécessaires à l'agent d' Instana. Cette configuration permet à k8sensor d'accéder aux ressources personnalisées de votre cluster et de les surveiller.
Création d'un service « ClusterRole » pour la surveillance des ressources personnalisées
ClusterRole qui définit les autorisations nécessaires pour surveiller vos ressources personnalisées. L'exemple suivant présente une configuration de base d' ClusterRole :apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: instana-crmon
rules:
- apiGroups: ["your.custom.group"]
resources: ["yourcustomresources"]
verbs: ["get", "list", "watch"]Vous devez remplacer your.custom.group par le groupe « API » de votre ressource personnalisée et yourcustomresources par le nom au pluriel de votre type de ressource personnalisée. Vous pouvez ajouter d'autres règles selon vos besoins pour chaque type de ressource personnalisée que vous souhaitez surveiller. Vous pouvez également utiliser le ["*"] caractère générique pour apiGroups et resources dans les systèmes de test afin de faire correspondre toutes les ressources personnalisées, si cela ne présente aucun risque pour la sécurité dans votre cas.
Il n'est pas recommandé d'utiliser un accès aussi permissif sur les systèmes de production, où il est conseillé d'appliquer le principe du privilège minimal.
Créer un fichier « ClusterRoleBinding »
ClusterRole, vous devez créer un ClusterRoleBinding pour associer le ClusterRole au ServiceAccount de l'agent Instana :apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: instana-crmon
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: instana-crmon
subjects:
- kind: ServiceAccount
name: instana-agent-k8sensor
namespace: instana-agentAssurez-vous que le namespace champ de la subjects section correspond à l'espace de noms dans lequel votre agent Instana est déployé. Si vous avez installé l'agent dans un autre espace de noms, modifiez la valeur en conséquence.
Une fois ces ressources configurées, l' Instanak8sensor dispose des autorisations nécessaires pour surveiller vos ressources personnalisées.
Collecte des journaux
Pour collecter les journaux d' k8sensor s et de l'environnement Kubernetes, vous pouvez recueillir des informations de diagnostic à l'aide du mustgather script, comme indiqué dans les étapes suivantes :
Étapes pour la collecte des journaux
Clonez le référentiel de maintenance.
Accédez au
agent/k8srépertoire.Lisez les instructions contenues dans le
README.mdfichier de ce répertoire, en vous assurant que les conditions préalables sont remplies et que vous êtes connecté au cluster.Exécutez
instana-k8s-mustgather.sh.Une fois le script exécuté, un
.tgzfichier est généré; celui-ci contient toutes les informations de diagnostic nécessaires à l'équipe d'assistance pour traiter la demande.Figure 2. MustGather résultat 
Activer la journalisation de débogage pour le dépannage
L' k8sensor e prend en charge différents niveaux de journalisation à des fins de dépannage. Par défaut, k8sensor enregistre les journaux au info niveau. Lorsque vous recherchez la cause d'un problème, vous pouvez activer temporairement la debug journalisation de niveau afin de recueillir des informations de diagnostic plus détaillées.
Vous pouvez activer la journalisation de débogage en utilisant l'une des méthodes suivantes :
Utilisation de la ressource personnalisée « agent » d' Instana
- Modifier la ressource personnalisée de l'agent « Instana » :
kubectl edit instanaagent -n instana-agent instana-agent - Ajouter ou modifier la
agent.envsection :spec: agent: env: K8S_SENSOR_LOG_LEVEL: debug - Attendez que le déploiement soit terminé. Vérifiez l'état du déploiement en exécutant la commande suivante :
kubectl rollout status deployment/instana-agent-k8sensor -n instana-agent - Vérifiez que la journalisation de débogage est activée en consultant les fichiers journaux de la commande « k8sensor » :
kubectl logs -n instana-agent deployment/instana-agent-k8sensor --tail=50 | grep -i "level.*debug" - Le cas échéant, reproduisez le problème afin de générer les journaux correspondants. Sinon, attendez quelques minutes que l' k8sensor e collecte les données selon ses intervalles d'interrogation habituels (par défaut : toutes les 10 secondes).
- Enregistrer les journaux. Pour obtenir des instructions détaillées sur la collecte des journaux, consultez la section « Collecte des journaux ».
- Pour désactiver la journalisation de débogage, modifiez à nouveau la ressource personnalisée de l'agent « Instana » et rétablissez le niveau de journalisation à
info:spec: agent: env: K8S_SENSOR_LOG_LEVEL: info
Utilisation d'un graphique « Helm »
- Mettez à jour votre installation d' Helm en activant le niveau de journalisation « debug » :
helm upgrade instana-agent \ --repo https://agents.instana.io/helm \ --namespace instana-agent \ --set agent.env.K8S_SENSOR_LOG_LEVEL=debug \ --reuse-values \ instana-agent - Attendez que le déploiement soit terminé. Vérifiez l'état du déploiement en exécutant la commande suivante :
kubectl rollout status deployment/instana-agent-k8sensor -n instana-agent - Vérifiez que la journalisation de débogage est activée en consultant les fichiers journaux de la commande « k8sensor » :
kubectl logs -n instana-agent deployment/instana-agent-k8sensor --tail=50 | grep -i "level.*debug" - Le cas échéant, reproduisez le problème afin de générer les journaux correspondants. Sinon, attendez quelques minutes que l' k8sensor e collecte les données selon ses intervalles d'interrogation habituels (par défaut : toutes les 10 secondes).
- Enregistrer les journaux. Pour obtenir des instructions détaillées sur la collecte des journaux, consultez la section « Collecte des journaux ».
- Pour désactiver la journalisation de débogage, mettez à jour à nouveau l'installation d' Helm :
helm upgrade instana-agent \ --repo https://agents.instana.io/helm \ --namespace instana-agent \ --set agent.env.K8S_SENSOR_LOG_LEVEL=info \ --reuse-values \ instana-agent