Verwenden von Cloud Native Operations (CNO) für Transparenz

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 2 Minuten Lesedauer

    • Cloud Native Operations (CNO) für Visibility erkennt Änderungen an Ressourcen in einem Kubernetes -Cluster. Es führt eine kontinuierliche Erkennung durch, meldet alle Änderungen an Ihre Instanz zurück und aktualisiert Configuration Management Database (CMDB) mit den neuesten Daten.

    MitCNO for Visibility erhalten Sie Einblick in lokale Kubernetes -Cluster sowie in die folgenden Cloud-Bereitstellungen: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Engine (AKS), Red Hat OpenShiftund Rancher.

    Funktionsweise

    Wenn Sie CNO für Visibility bereitstellen, erstellt Kubernetes eine Bereitstellungsressource im Cluster. Diese Ressource verwendet ein in Kubernetes gespeichertes Geheimnis, um eine Verbindung zu Ihrer Instanz ServiceNow herzustellen.

    Die Bereitstellungsressource CNO enthält einen Pod namens „Informer“, der eine Verbindung zum API-Server Kubernetes herstellt und von diesem Events für die Ressourcen im Cluster empfängt. Der Informer sendet die erfassten Daten über die Tabelle „ECC-Warteschlange“ (Externer Kommunikationskanal) an die Instanz und verwendet die Tabellen-API ServiceNow, um aus der Warteschlange zu lesen und in sie zu schreiben. Der Informer aktualisiert dann die entsprechenden Tabellen in CMDB.

    Hinweis:
    Wenn der Informer die Änderungen nicht melden kann, z. B. aufgrund eines Netzwerkproblems, werden die Ressourcen, die dem Cluster während des Ereignisses hinzugefügt wurden, nach dem nächsten vollständigen Erkennungszyklus zu CMDB hinzugefügt. Die Ressourcen, die während des Events aus dem Cluster entfernt wurden, werden als Abwesend markiert und nach zwei vollständigen Erkennungszyklen gelöscht.

    Weitere Informationen zu den Kubernetes -Ressourcen, in denen der Informer Daten sammelt, und zu den CMDB -Tabellen, die er ausfüllt, finden Sie unter Von CNO für Transparenz erfasste Daten.

    Anfängliche und regelmäßige Erkennung

    Bei der ersten Erkennung findet der Informer alle Ressourcen im Cluster Kubernetes und meldet sie Ihrer Instanz. Alle 30 Sekunden sendet der Informer bis zu 1 MB Daten an die Instanz. Normalerweise dauert es bis zu zwei Minuten, um Daten in einem Cluster mit 1.000 Pods zu melden, und eine weitere Minute für jede weitere 1.000 Pods. Ein einzelner Informer-Pod kann einen Cluster mit Zehntausenden von Pods verarbeiten. Wenn der Informer aus irgendeinem Grund beendet wird, wird er von Kubernetes automatisch neu gestartet.

    Nach der ersten Erkennung überwacht der Informer kontinuierlich das Hinzufügen, Aktualisieren und Löschen von Ressourcen im Cluster. Ressourcen, die aus dem Cluster gelöscht wurden, werden mit install_status=Absent markiert und im Rahmen einer regulären Bereinigung innerhalb von Stunden aus CMDB gelöscht.

    Auswirkung des Informers auf den API-Server Kubernetes .

    Der Informer hat minimale Auswirkungen auf den API-Server Kubernetes. Die vollständige Liste der relevanten Ressourcen wird nur einmal abgerufen und im Speicher gespeichert. Von da an wird eine Synchronisierung mit dem API-Server Kubernetes durchgeführt, und die vollständige Liste wird nie wieder abgerufen. Während der regelmäßigen und vollständigen Erkennungszyklen bei Bedarf sendet der Informer die gespeicherte Liste der Ressourcen erneut an die Instanz.

    CNO für Benchmark zu Transparenzleistung und Skalierbarkeit

    Informationen zu CNO for Visibility-Benchmarks finden Sie im Artikel Performance results for CNO for Visibility [KB1555851] in der Knowledge Base von Now Support.