Utilisation de Cloud Native Operations (CNO) pour la visibilité

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 2 minutes de lecture

    • Cloud Native Operations (CNO) pour Visibility détecte les changements sur les ressources d’une Kubernetes grappe. Il effectue une détection continue, signale tout changement à votre instance et met à jour la Base de données de gestion des configurations (CMDB) via les données les plus récentes.

    CNOfor Visibility vous permet d’obtenir une visibilité sur les clusters locaux Kubernetes ainsi que sur les déploiements Cloud suivants : Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Engine (AKS)Red Hat OpenShift, et Rancher.

    Fonctionnement

    Lorsque vous effectuez un déploiement CNO pour Visibility, Kubernetes crée une ressource de déploiement dans le cluster. Cette ressource utilise un secret stocké pour Kubernetes se connecter à votre ServiceNow instance.

    La CNO ressource de déploiement contient un pod appelé Informer, qui se connecte au serveur d’API Kubernetes et reçoit des événements sur les ressources de la grappe à partir de celui-ci. L’informateur envoie les données collectées à l’instance via la table File d’attente ECC (External Communication Channel), en utilisant l’API ServiceNow de table pour lire et écrire dans la file d’attente. L’informateur met ensuite à jour les tables appropriées dans le CMDBfichier .

    Remarque :
    Si l’informateur n’est pas en mesure de signaler les modifications, par exemple en raison d’un problème de réseau, les ressources qui ont été ajoutées au cluster pendant l’événement sont ajoutées au CMDB suivant le cycle de détection complet. Les ressources qui ont été retirées du cluster pendant l’événement sont marquées comme absentes et supprimées après deux cycles de détection complets.

    Pour en savoir plus sur les Kubernetes ressources sur lesquelles l’informateur collecte des données et les tables qu’il renseigne, reportez-vous à la CMDB section Données collectées par CNO pour la visibilité.

    Détection initiale et périodique

    Lors de sa détection initiale, l’informateur trouve toutes les ressources du Kubernetes cluster et les signale à votre instance. Toutes les 30 secondes, l’informateur envoie jusqu’à 1 Mo de données à l’instance. Il faut généralement jusqu’à deux minutes pour signaler des données sur un cluster contenant 1 000 pods et une minute de plus pour chaque tranche de 1 000 pods supplémentaires. Un seul pod Informer peut gérer un cluster avec des dizaines de milliers de pods. Si l’informateur se ferme pour une raison quelconque, Kubernetes il le redémarre automatiquement.

    Après la détection initiale, l’informateur surveille en permanence l’ajout, la mise à jour et la suppression des ressources dans le cluster. Les ressources qui ont été supprimées du cluster sont marquées avec install_status=Absent et supprimées dans les heures qui suivent dans le CMDB cadre d’un nettoyage normal.

    Impact de l’informateur sur le Kubernetes serveur API

    L’informateur a un impact minimal sur le serveur d’API Kubernetes . Il récupère la liste complète des ressources pertinentes une seule fois et l’enregistre en mémoire. À partir de ce moment-là, il se synchronise avec le Kubernetes serveur API et n’extrait plus jamais la liste complète. Au cours des cycles de détection complets périodiques et sur demande, l’informateur renvoie la liste des ressources enregistrées à l’instance.

    CNO pour un benchmark de visibilité, de performance et d’évolutivité

    Pour les CNO points de référence de Visibilité, consultez l’article Résultats de performance de CNO pour Visibility [KB1555851] dans la Now Support base de connaissances.