Attribute für Agentenfunktionen

FlexNet Manager Suite 2022 R1 (Standortgebundene Implementierung)

Mit dem YAML-Dateiformat können Sie bestimmte Funktionen und Merkmale des Kubernetes-Inventarisierungsagenten von Flexera konfigurieren, indem Sie die in diesem Hilfethema beschriebenen Einstellungen verwenden.

Integration des IBM-Lizenzservice

In Containern installierte Software von IBM erfordert die Nutzung des IBM-Lizenzservice, um die Lizenznutzung zu überwachen. Der Kubernetes-Inventarisierungsagent von Flexera ist mit dem IBM-Lizenzservice integriert und erfasst über das API des IBM-Lizenzservice die Kapazitätsnutzungsdaten des/r IBM-Produkts/e für diesen Cluster.

Zur Nutzung des IBM-Lizenzservice-API muss der Kubernetes-Inventarisierungsagent von Flexera zuerst das API suchen und dann das für die Authentifizierung verwendete Token abrufen. Dazu muss der Kubernetes-Inventarisierungsagent von Flexera mehrere unterschiedliche Ressourcentypen aus dem Cluster lesen, die er anderenfalls nicht zu lesen bräuchte. Die Berechtigungen zum Lesen dieser Ressourcen können bei der Installation aktiviert werden. Die Notwendigkeit des Hinzufügens dieser Berechtigungen kann ebenfalls umgangen werden, indem dem Kubernetes-Inventarisierungsagenten von Flexera alle benötigten Standardwerte in den Attributen der YAML-Datei bereitgestellt werden. (Die unter Erweiterte Attribute für den Kubernetes-Inventarisierungsagenten von Flexera aufgeführten Attribute sind darin nicht enthalten.)

Hinweis: Es muss der gesamte Satz an Werten zur Verfügung gestellt werden. Ist der Satz nicht vollständig, versucht der Kubernetes-Inventarisierungsagent von Flexera die fehlenden Werte zu ermitteln. Ausnahmen zu dieser generellen Aussage bilden die Einstellungen enable und tlsVerify (die auf jeden Fall erforderlich sind).

Bei Aktivierung (im Folgenden beschrieben) ermittelt der Kubernetes-Inventarisierungsagent von Flexera zuerst das Vorhandensein des IBM-Lizenzservice im Kubernetes-Cluster durch Suche nach der CustomResourceDefinition:

ibmLicensings.operator.ibm.com.

Tipp: Der Plural ibmLicensings ist in diesem Kontext kein Rechtschreibfehler, sondern hält sich an die Benennungskonvention von Kubernetes, bei der die Pluralform verwendet wird, wenn auf einen vollständig qualifizierten Ressourcentyp Bezug genommen wird.

Anschließend lädt er alle fehlenden Konfigurationswerte herunter, die erforderlich sind, um das API zu lokalisieren und sich bei ihm zu authentifizieren. Dazu liest er die Ressourcenkonfiguration ibmLicensing, sucht mithilfe der Etikettenauswahl nach Services im Kubernetes-Cluster und liest das Geheimnis, in dem das Token für die Authentifizierung enthalten ist.

Tipp: Wenn dieser Vorgang fehlschlägt oder der IBM-Lizenzservice im Kubernetes-Cluster nicht installiert ist, versucht der Kubernetes-Inventarisierungsagent von Flexera alle 5 Minuten, den Vorgang erneut durchzuführen. Der Grund dafür ist, dass Ihre Einstellungen in der YAML-Datei festlegen, dass Sie die Integration mit dem IBM-Lizenzservice aktivieren möchten. Wenn dieser erst zu einem späteren Zeitpunkt bereitgestellt wird, bewirken die regelmäßigen Überprüfungen durch den Kubernetes-Inventarisierungsagenten von Flexera, dass die Integration ohne weiteres Zutun Ihrerseits die Funktion aufnimmt. Wenn Sie das nicht beabsichtigt haben, setzen Sie die (als nächstes beschriebene) Einstellung einfach auf false zurück, um die Integration zu deaktivieren, da so auch der Vorgang der Überprüfung ausgeschaltet wird.

Der Kubernetes-Inventarisierungsagent von Flexera fragt bei folgenden Gelegenheiten nach dem API des IBM-Lizenzservice:

• Sofort nach dem Start
• Sofort nach der erfolgreichen Ermittlung des Service und der Konfiguration
• Jeden Tag um 01:00 nachts (Ortszeit des Clusters)

Der Kubernetes-Inventarisierungsagent von Flexera verlangt bei jeder Abfrage des API einen Snapshot der Nutzung der letzten 180 Tage.

Aktivieren der Integration

Wenn dieses Attribut auf true gesetzt ist, ist die Integration des Kubernetes-Inventarisierungsagenten von Flexera mit dem IBM-Lizenzservice aktiv.

Wichtig: Voreingestellt ist der Wert false, bei dem der Kubernetes-Inventarisierungsagent von Flexera nicht mit dem IBM-Lizenzservice interagiert. Denken Sie daran, dass die Nutzung des IBM-Lizenzservice für die Compliance bei IBM-Lizenzen von Produkten, die in Kubernetes-Clustern ausgeführt werden, verpflichtend ist. Wenn Sie die Lizenzdaten, die vom IBM-Lizenzservice erfasst wurden, für Berichte in FlexNet Manager Suite importieren möchten, müssen Sie dieses Attribut auf true setzen.

Attribut	spec.ibmLicensing.enable
Typ	Boolescher Ausdruck
Beispiel	true

Mit dieser Einstellung sieht der entsprechende Abschnitt in der YAML-Datei ähnlich wie nachfolgend dargestellt aus:

apiVersion: agents.flexera.com/v1
kind: KRM
metadata:
  name: instance
spec:
  ibmLicensing:
    enable: true
...

Der Namensraum des IBM-Lizenzservice

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem vom IBM-Lizenzservice verwendeten Namensraum. Alternativ können Sie den Namensraum in diesem Attribut ausdrücklich angeben.

Attribut	spec.ibmLicensing.namespace
Typ	String
Beispiel	ibm-common-services

Der Service-Name

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem Service-Namen, der zur Anzeige des API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie den Namen in diesem Attribut ausdrücklich angeben.

Attribut	spec.ibmLicensing.serviceName
Typ	String
Beispiel	ibm-licensing-service-instance

Der Service-Port

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem TCP-Port im Service, der zur Anzeige des API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie den Port in diesem Attribut ausdrücklich angeben.

Attribut	spec.ibmLicensing.servicePort
Typ	Ganze Zahl (Integer)
Beispiel	8080

Das Service-Token

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem Token, das zur Authentifizierung beim API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie das Token in diesem Attribut ausdrücklich angeben.

Attribut	spec.ibmLicensing.token
Typ	String
Beispiel	VoOMWJijBWuCxSxwgON11w7z

Das Service-Protokoll

Wenn dieses Attribut ausgelassen wird, durchsucht der Kubernetes-Inventarisierungsagent von Flexera automatisch die Konfiguration, um zu ermitteln, ob das API des IBM-Lizenzservice über HTTPS bedient werden muss. Alternativ können Sie das Protokoll in diesem Attribut ausdrücklich angeben.

Attribut	spec.ibmLicensing.https
Typ	Boolescher Ausdruck
Beispiel	true

Das Service-Zertifikat

Wenn das API des IBM-Lizenzservice seine Dienste unter Verwendung eines nicht vertrauenswürdigen Zertifikats über HTTPS zur Verfügung stellt, kann diese Einstellung auf false gesetzt oder unbearbeitet gelassen werden (da der Standardwert „false“ lautet).

• Wenn dieser Wert false (oder unspezifisch) lautet, versucht der Kubernetes-Inventarisierungsagent von Flexera nicht, die Echtheit des Zertifikats zu überprüfen.
• Wenn dieser Wert true lautet, überprüft der Kubernetes-Inventarisierungsagent von Flexera das Zertifikat. Eine Verbindung mit dem IBM-Lizenzservice kann nicht hergestellt werden, wenn Folgendes gilt:
  • Das Zertifikat ist nicht gültig.
  • Das Zertifikat wurde von einem unbekannten Aussteller unterzeichnet.

Attribut	spec.ibmLicensing.tlsVerify
Typ	Boolescher Ausdruck
Beispiel	false

Erweiterte Attribute für den Kubernetes-Inventarisierungsagenten von Flexera

FlexNet Manager Suite 2022 R1 (Standortgebundene Implementierung)

Die folgenden Attribute steuern unbedeutendere Aspekte des Verhaltens des Kubernetes-Inventarisierungsagenten von Flexera. Alle haben sinnvolle Voreinstellungen, sodass es keinen triftigen Grund gibt, diese Attribute zu ändern, es sei denn, Sie benötigen eine sehr detaillierte Steuerung der Konfiguration in Ihrer Umgebung.

Inventarisierungsintervall

Legt die Zeitspanne fest, nach der der Kubernetes-Inventarisierungsagent von Flexera Inventar erfasst und hochlädt. Der Kubernetes-Inventarisierungsagent von Flexera legt die neuesten Daten zu jeder Cluster-Ressource, an deren Beobachtung er interessiert ist, in einem Zwischenspeicher (Cache) ab und behält Ressourcen in seinem Cache (selbst wenn diese gelöscht wurden), bis er sein Inventar das nächste Mal hochladen kann. Die Intervalleinstellung ist ein Kompromiss zwischen dem Datenvolumen, das im Cache zurückgehalten wird und bei einer bestimmten Inventarisierung hochgeladen werden kann, und der Anzahl der Inventarisierungen, die hochgeladen und importiert werden. Die Voreinstellung lautet 24h, sodass der Kubernetes-Inventarisierungsagent von Flexera sein festgelegtes Inventar einmal täglich erfasst und hochlädt.

Der Wert dieser Einstellung ist eine Zeichenfolge (String), bei der die von Kubernetes und der Programmiersprache Go etablierte Konvention beachtet wird. Diese schreibt eine ganze Zahl gefolgt von einem Einheitensuffix wie „s“ für Sekunden, „m“ für Minuten oder „h“ für Stunden vor, z. B. 12h für 12 Stunden.

Attribut	spec.monitor.interval
Typ	Dauer
Beispiel	6h

Eigenständige Aktualisierungen des Agenten und Richtlinien-Updates

Das Attribut downloadFromBeacon steuert, ob der Kubernetes-Inventarisierungsagent von Flexera Datenflüsse von seiner Inventarisierungsstation abwärts zulässt, wozu drei wichtige Kommunikationsarten gehören, die Einfluss auf den FlexNet-Inventarisierungsagenten haben, wenn er zur Software-Inventarisierung innerhalb des Containers angestoßen wird:

• Updates der Agentenrichtlinie, die durch Inventarisierungsstationen als neue Versionen der Datei config.ini zur Verfügung gestellt werden, die vom zentralen Anwendungsserver verteilt wird
• Weitere Erweiterungen der Inventarisierungsfunktionen, die als aktualisierte Versionen der InventorySettings.xml verteilt werden
• Aktualisierte Versionen des FlexNet-Inventarisierungsagenten selbst

Der Standardwert dieses Attributs lautet true (wahr), unter der Annahme, dass Sie eine Software-Inventarisierung in Ihren Containern mit optimalen, vollständig aktualisierten Funktionen erwarten würden.

• Wenn downloadFromBeacon auf true gesetzt oder ohne Spezifizierung gelassen wird, führt der Kubernetes-Inventarisierungsagent von Flexera die Richtlinienkomponente des FlexNet-Inventarisierungsagenten aus, um nach der neuesten Agentenrichtlinie (config.ini), nach Updates der Komponente für die Inventarisierung ohne Fußabdruck (ndtrack.sh) und nach der jüngsten Version der Datei mit Erweiterungsfunktionen InventorySettings.xml zu suchen und diese ggf. herunterzuladen.
• Wenn downloadFromBeacon auf false gesetzt ist, lässt der Kubernetes-Inventarisierungsagent von Flexera diese Updates nicht zu. Stattdessen verwendet er die Version von ndtrack.sh, die mit dem Containerimage ausgeliefert wurde, und verwendet keine Kopie von InventorySettings.xml. Er verwendet außerdem die Datei config.ini, die mit dem Containerimage ausgeliefert wurde, auch wenn diese mit lokalen Patches für den Cluster aktualisiert werden kann (siehe Einspielen von Patches in die Datei config.ini mithilfe des Kubernetes-Inventarisierungsagenten von Flexera). Auch wenn es die empfohlene Herangehensweise ist, downloadFromBeacon in Situationen, in denen der Container während der Laufzeit unverändert bleiben muss, auf false (falsch) zu setzen, kann dies die Vollständigkeit des Inventars beeinflussen, das für Containerimages im Cluster erzeugt wird, insbesondere für Software von Anbietern wie Oracle und Microsoft.

Attribut	spec.monitor.downloadFromBeacon
Typ	Boolescher Ausdruck
Beispiel	false

Erfassen von Software-Inventar

Das Attribut imageInventory steuert die Erfassung von Software-Inventar der OCI-Containerimages:

• Wenn es auf true (der Standardwert) gesetzt oder ohne Spezifizierung gelassen wird, injiziert der Kubernetes-Inventarisierungsagent von Flexera die Inventarisierungskomponente des FlexNet-Inventarisierungsagenten (ndtrack.sh) in die Container im Cluster, um das Software-Inventar ihres Inhalts zu erhalten. Anschließend wird der Tracker (die Inventarisierungskomponente) wieder vollständig entfernt. Dieser Vorgang nennt sich Inventarerfassung ohne Fußabdruck.
• Lautet die Einstellung false, deaktiviert der Kubernetes-Inventarisierungsagent von Flexera dieses Verhalten. Das bedeutet dann, dass der Kubernetes-Inventarisierungsagent von Flexera kein Software-Inventar aus einem Container im Cluster melden kann.
  Wichtig: Wenn keine andere Inventardatenquelle die Software-Inventarisierung der Container übernimmt, kann der Lizenzstatus nicht korrekt ermittelt werden, was bei einem zukünftigen Compliance-Audit zu Problemen führen kann. Denken Sie daran, dass der IBM-Lizenzservice nur Software von IBM überwacht. Beachten Sie die Pflicht, den Verbrauch von Lizenzen anderer Software-Unternehmen zu überwachen.

Attribut	spec.monitor.imageInventory
Typ	Boolescher Ausdruck
Beispiel	true

Knotenkomponente

Das Attribut enable im node-Block der YAML-Datei bestimmt, ob die Komponente des Kubernetes-Inventarisierungsagenten von Flexera zur Überwachung von Knoten eingesetzt wird:

• Bei der Einstellung true (der Standardwert) oder keiner Spezifizierung sind die normalen Vorgänge aktiviert.
• Bei der Einstellung false wird die Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera nicht eingesetzt. Das bedeutet, dass kein Hardware-Inventar von den Worker-Knoten erfasst werden kann.

Warnung: Zwar steht die Option zum Deaktivieren der Knotenkomponente derzeit im Kubernetes-Inventarisierungsagenten von Flexera zur Verfügung, sie wird im Rest von FlexNet Manager Suite jedoch nicht unterstützt. Deaktivieren Sie die Knotenkomponente daher erst, wenn diese Warnung in einer künftigen Version nicht mehr vorhanden ist.

Attribut	spec.node.enable
Typ	Boolescher Ausdruck
Beispiel	true

Inventarisierungsintervall für Knoten

Das Attribut interval im node-Block der YAML-Datei legt fest, wie häufig (in welchen Zeitabständen) Hardware-Inventar für die Worker-Knoten im/in den Cluster(n) erfasst wird. Im Allgemeinen kann dieses Attribut ohne Spezifizierung gelassen werden, selbst wenn:

• Sie über eine modifizierte Lizenz verfügen, die die Nutzung von FlexNet Manager Suite zur Bewertung des Sub-Capacity-Verbrauchs von IBM PVU-Lizenzen autorisiert (wenn die Bedingungen dieser modifizierten Lizenz verlangen, dass die zugrundeliegende Hardware alle 30 Minuten ausgewertet und ihr Bestand gemeldet wird), und
• Sie IBM-Produkte auf einem oder mehreren Worker-Knoten ausführen, die durch IBM PVU-Lizenzen lizenziert sind und für Berechnungen des Sub-Capacity-Verbrauchs infrage kommen.

Das liegt daran, dass die Voreinstellung bereits auf 30m gesetzt ist, sodass es nicht nötig ist, eine Spezifizierung vorzunehmen, um die IBM-Anforderungen für die Meldung von Sub-Capacity-PVU-Punkten zu erfüllen.

Attribut	spec.node.interval
Typ	Dauer
Beispiel	30m

Inventarisierungsberechtigung für Knoten

Das Attribut privileged im node-Block der YAML-Datei legt fest, ob die Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera die Hardware-Daten von Worker-Knoten vollständig erfassen kann, insbesondere die Daten aus dem BIOS. Um dies zuzulassen, muss für die Container, die als Bestandteil der Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera eingesetzt werden, das Attribut privileged in ihrem Sicherheitskontext gesetzt sein.

• Bei der (Standard-)Einstellung true oder keiner Spezifizierung sind die normalen Vorgänge aktiviert.
• Wenn die Einstellung false lautet, verfügen die Container der Knotenkomponente nicht über das Attribut privileged und können die entsprechenden Daten daher nicht melden.

Attribut	spec.node.privileged
Typ	Boolescher Ausdruck
Beispiel	true

Kontrollknoten erzwingen

In Kubernetes kann die Markierung (taint) node-role.kubernetes.io/master verwendet werden, um Pods zurückzuweisen, damit sie auf den Knoten der Kontrollebene (control plane) nicht eingeplant werden.

• Wenn forceControlPlane auf true gesetzt ist, werden die Pods der Knotenkomponente mit einer entsprechenden Toleranz erstellt, um zu erzwingen, dass sie auf den Knoten der Kontrollebene ebenso eingeplant werden wie auf den Worker-Knoten.
• Wenn dieser Wert auf „false“ (Standardwert) gesetzt oder nicht spezifiziert ist, wird die Toleranz auf die Pods der Knotenkomponente nicht angewendet. Inventar wird dann nur von den Worker-Knoten erfasst.

Attribut	spec.node.forceControlPlane
Typ	Boolescher Ausdruck
Beispiel	true

Erneute Versuche, eine Verbindung mit dem Knoten herzustellen

Diese Attribute brauchen nur selten gesetzt zu werden. Zusammen legen Sie das Verhalten der Knotenkomponente fest, während sie auf den Start der Monitorkomponente wartet:

1. Beim Start versucht ein Pod der Knotenkomponente, sich mit der Monitorkomponente zu verbinden.
2. Wenn der Verbindungsversuch fehlschlägt, wartet er für readyWait Sekunden und versucht dann erneut, eine Verbindung herzustellen.
3. Er wiederholt die Versuche readyRetries Mal, danach werden die Versuche eingestellt und der Pod ist fehlgeschlagen.
4. Die Knotenkomponente DaemonSet startet den Pod automatisch neu.

Attribut	spec.node.readyWait
Typ	Dauer
Beispiel	10s

Attribut	spec.node.readyRetries
Typ	Ganze Zahl (Integer)
Beispiel	20

Hochladen vom Knoten gescheitert

Dieses Attribut braucht nur selten gesetzt zu werden. Der Standardwert ist false, was bei einem Scheitern des Hochladens von Inventar dazu führt, dass der Pod weiter ausgeführt wird und den Upload des Inventars später erneut versuchen kann. Wenn dieses Attribut auf true gesetzt ist, führt ein fehlgeschlagenes Hochladen von Inventar dazu, dass der Pod der Knotenkomponente fehlschlägt.

Attribut	spec.node.mustUpload
Typ	Boolescher Ausdruck
Beispiel	true