Chapitre 34. Observabilité du réseau
34.1. Notes de mise à jour de l'opérateur d'observabilité du réseau
L'opérateur d'observabilité du réseau permet aux administrateurs d'observer et d'analyser les flux de trafic réseau pour les clusters OpenShift Container Platform.
Ces notes de version suivent le développement de l'opérateur d'observabilité du réseau dans la plateforme OpenShift Container.
Pour une présentation de l'opérateur d'observabilité du réseau, voir À propos de l'opérateur d'observabilité du réseau.
34.1.1. Opérateur d'observabilité du réseau 1.2.0
L'avis suivant est disponible pour le Network Observability Operator 1.2.0 :
34.1.1.1. Préparation de la prochaine mise à jour
L'abonnement d'un opérateur installé spécifie un canal de mise à jour qui suit et reçoit les mises à jour pour l'opérateur. Jusqu'à la version 1.2 de Network Observability Operator, le seul canal disponible était v1.0.x. La version 1.2 de Network Observability Operator introduit le canal de mise à jour stable pour le suivi et la réception des mises à jour. Vous devez changer votre canal de v1.0.x à stable pour recevoir les futures mises à jour de l'opérateur. Le canal v1.0.x est obsolète et il est prévu de le supprimer dans une prochaine version.
34.1.1.2. Nouvelles fonctionnalités et améliorations
34.1.1.2.1. Histogramme dans la vue Flux de trafic
- Vous pouvez maintenant choisir d'afficher un histogramme des flux dans le temps. L'histogramme vous permet de visualiser l'historique des flux sans dépasser la limite de requêtes de Loki. Pour plus d'informations, voir Utilisation de l'histogramme.
34.1.1.2.2. Suivi des conversations
- Vous pouvez désormais interroger les flux par Log Typece qui permet de regrouper les flux réseau qui font partie de la même conversation. Pour plus d'informations, voir Travailler avec des conversations.
34.1.1.2.3. Alertes de santé relatives à l'observabilité du réseau
-
L'opérateur d'observabilité du réseau crée désormais des alertes automatiques si le site
flowlogs-pipelineabandonne des flux en raison d'erreurs à l'étape d'écriture ou si la limite du taux d'ingestion de Loki a été atteinte. Pour plus d'informations, voir Visualisation des informations de santé.
34.1.1.3. Bug fixes
-
Auparavant, après avoir modifié la valeur
namespacedans la spécification FlowCollector, les pods de l'agent eBPF fonctionnant dans l'espace de noms précédent n'étaient pas supprimés de manière appropriée. Désormais, les pods fonctionnant dans l'espace de noms précédent sont supprimés de manière appropriée. (NETOBSERV-774) -
Auparavant, après avoir modifié la valeur
caCert.namedans la spécification FlowCollector (comme dans la section Loki), les pods FlowLogs-Pipeline et les pods du plug-in Console n'étaient pas redémarrés, et n'étaient donc pas au courant du changement de configuration. Maintenant, les pods sont redémarrés, donc ils reçoivent le changement de configuration. (NETOBSERV-772) - Auparavant, les flux réseau entre les pods fonctionnant sur différents nœuds n'étaient parfois pas correctement identifiés comme étant des doublons parce qu'ils étaient capturés par différentes interfaces réseau. Cela entraînait une surestimation des mesures affichées dans le plug-in de la console. Désormais, les flux sont correctement identifiés comme étant des doublons et le plug-in de la console affiche des mesures précises. (NETOBSERV-755)
- L'option "reporter" du plug-in de la console permet de filtrer les flux en fonction du point d'observation du nœud source ou du nœud de destination. Auparavant, cette option mélangeait les flux indépendamment du point d'observation du nœud. Cela était dû au fait que les flux réseau étaient incorrectement signalés comme entrant ou sortant au niveau du nœud. Désormais, le signalement de la direction du flux réseau est correct. L'option "reporter" filtre le point d'observation source ou le point d'observation destination, comme prévu. (NETOBSERV-696)
- Auparavant, pour les agents configurés pour envoyer des flux directement au processeur en tant que requêtes protobuf gRPC, la charge utile soumise pouvait être trop importante et était rejetée par le serveur GRPC du processeur. Cela se produisait dans des scénarios de très forte charge et avec seulement certaines configurations de l'agent. L'agent enregistrait un message d'erreur, tel que : grpc: received message larger than max. En conséquence, il y a eu une perte d'informations sur ces flux. Désormais, la charge utile gRPC est divisée en plusieurs messages lorsque sa taille dépasse un certain seuil. Par conséquent, le serveur maintient la connectivité. (NETOBSERV-617)
34.1.1.4. Problème connu
-
Dans la version 1.2.0 du Network Observability Operator, utilisant Loki Operator 5.6, une transition de certificat Loki affecte périodiquement les pods
flowlogs-pipelineet résulte en des flux abandonnés plutôt qu'en des flux écrits dans Loki. Le problème se corrige de lui-même après un certain temps, mais il provoque toujours une perte temporaire de données de flux pendant la transition du certificat Loki. (NETOBSERV-980)
34.1.1.5. Changements techniques notables
-
Auparavant, vous pouviez installer le Network Observability Operator en utilisant un espace de noms personnalisé. Cette version introduit l'espace de noms
conversion webhookqui modifie l'espace de nomsClusterServiceVersion. En raison de cette modification, tous les espaces de noms disponibles ne sont plus répertoriés. De plus, pour permettre la collecte des métriques de l'opérateur, les espaces de noms partagés avec d'autres opérateurs, comme l'espace de nomsopenshift-operators, ne peuvent pas être utilisés. Désormais, l'opérateur doit être installé dans l'espace de nomsopenshift-netobserv-operator. Vous ne pouvez pas passer automatiquement à la nouvelle version de l'opérateur si vous avez précédemment installé l'opérateur d'observabilité du réseau en utilisant un espace de noms personnalisé. Si vous avez précédemment installé l'opérateur en utilisant un espace de noms personnalisé, vous devez supprimer l'instance de l'opérateur qui a été installée et réinstaller votre opérateur dans l'espace de nomsopenshift-netobserv-operator. Il est important de noter que les espaces de noms personnalisés, tels que l'espace de nomsnetobservcouramment utilisé, sont toujours possibles pourFlowCollector, Loki, Kafka et d'autres plug-ins. (NETOBSERV-907)(NETOBSERV-956)
34.1.2. Opérateur d'observabilité du réseau 1.1.0
L'avis suivant est disponible pour le Network Observability Operator 1.1.0 :
L'opérateur d'observabilité du réseau est maintenant stable et le canal de publication est mis à jour à v1.1.0.
34.1.2.1. Correction d'un bug
-
Auparavant, si la configuration de Loki
authTokenn'était pas en modeFORWARD, l'authentification n'était plus appliquée, ce qui permettait à tout utilisateur pouvant se connecter à la console OpenShift Container Platform dans un cluster OpenShift Container Platform de récupérer des flux sans authentification. Désormais, quel que soit le mode de LokiauthToken, seuls les administrateurs du cluster peuvent récupérer les flux. (BZ#2169468)
