Ändern der Konfiguration für den Kubernetes-Inventarisierungsagenten von Flexera

FlexNet Manager Suite 2022 R1 (Standortgebundene Implementierung)

Der Kubernetes-Inventarisierungsagent von Flexera wird als Anwendung betrachtet, die in einem Kubernetes-Cluster bereitgestellt werden muss und die durch einen festen Satz an Kubernetes-Ressourcen definiert ist. Die entsprechenden Ressourcen müssen in einer Datei, die in der vereinfachten, von Menschen lesbaren Sprache YAML geschrieben ist, festgelegt werden. Im für den Kubernetes-Inventarisierungsagenten von Flexera heruntergeladenen Archiv (wie unter Herunterladen des Kubernetes-Inventarisierungsagenten von Flexera beschieben) gibt es ein Schnittstellen-Skript namens generate.sh, das Ihnen helfen soll, diese Ressourcen in einer YAML-Datei zu definieren, wenn Sie es verwenden möchten. Alternativ können Sie Ihre YAML-Datei natürlich auch in Ihrem bevorzugten Text-Editor ändern. In diesem Hilfethema finden Sie weitere Einzelheiten zu den in der YAML-Datei verwendeten Attributen, falls Sie tiefer in die individuelle Anpassung der Datei einsteigen möchten.

Tipp: Zweck des Kubernetes-Inventarisierungsagenten von Flexera ist die Überwachung der Ressourcenaktivität in Ihren Kubernetes-Clustern, mit anderen Worten ist er ein Kubernetes-Ressourcenmonitor. Auch der Kubernetes-Ressourcenmonitor hat als Acronym KRM, was offensichtlich leicht mit dem besser bekannten Kubernetes-Ressourcenmodell verwechselt werden kann.

In den beiden Anfangszeilen der YAML-Datei (der GVK, die als nächstes erläutert wird), gibt es ein „Schlüssel:Wert“-Paar für das Attribut kind. Dieses Attribut definiert die Art oder den Typ des Objekts, das in dieser YAML-Datei deklariert wird. In unserem Fall ist das Objekt der Kubernetes-Inventarisierungsagent von Flexera, der in dieser Deklaration angegeben wird als:

kind: KRM

Hier muss KRM als „Kubernetes-Ressourcenmonitor“ gelesen werden, der sich direkt auf den Kubernetes-Inventarisierungsagenten von Flexera bezieht, für den die Deklarationen in der YAML-Datei erstellt werden. An anderen Stellen kann „KRM“ als Akronym für das Kubernetes-Ressourcenmodell verwendet werden. W werden versuchen, Verwirrung zu vermeiden.

Wichtig: Erstellen Sie für jeden Cluster nur eine YAML-Datei, die Deklarationen für den Kubernetes-Inventarisierungsagenten von Flexera enthält, und zwar aus folgendem Grund: Eine Komponente im Kubernetes-Inventarisierungsagenten von Flexera ist der Knotenagent, der Hardwaredaten für jeden Worker-Knoten in einem Cluster sammelt. Im Kubernetes-Inventarisierungsagenten von Flexera ist dieser Agent als ein DaemonSet implementiert, um sicherzustellen, dass genau eine Instanz auf jedem Knoten ausgeführt wird. Vergewissern Sie sich daher, dass es in jedem Cluster nur eine YAML-Datei mit Ressourcendeklarationen für eine Anwendung/ein Objekt der Art

„kind: KRM“ gibt. 

Haben Sie jedoch mehrere Cluster, die gemeinsam die gleichen Konfigurationsdetails für den Kubernetes-Inventarisierungsagenten von Flexera verwenden müssen, können Sie dieselbe YAML-Datei in jeden dieser Cluster kopieren (denken Sie jedoch daran, zu prüfen, ob für die in jedem Cluster zu verwendende Inventarisierungsstation eine eindeutige URL festgelegt ist) und sie verwenden, wenn Sie das Skript install.sh für jeden unterschiedlichen Cluster ausführen.

Grundlegende Strukturelemente

FlexNet Manager Suite 2022 R1 (Standortgebundene Implementierung)

Jede Kubernetes-Konfigurationsdatei beginnt mit einer statischen Präambel, in der ihr Typ und die Version des Kubernetes-API definiert werden, auf das sie sich bezieht. Auf diese folgt das Attribut kind, das die Art oder den Typ der Ressource deklariert, die definiert wird. Zusammen werden diese Präambel-Elemente als GroupVersionKind (GVK) bezeichnet. Die folgenden GVK-Angaben sind in jeder YAML-Datei, die den Kubernetes-Inventarisierungsagenten von Flexera definieren, Pflichtangaben.

apiVersion: agents.flexera.com/v1
kind: KRM

Als nächstes folgt der Standardblock metadata, der in der Regel den Namen des Objekts nennt, für das diese YAML-Datei gilt. In diesem Fall weist der metadata-Block kein namespace-Attribut auf, weil KRM kind (für den Kubernetes-Inventarisierungsagenten von Flexera) cluster scoped lautet (es sich also auf den ganzen Kubernetes-Cluster bezieht, in dem der Agent definiert ist).

metadata:
  name: instance

Der Rest der Konfiguration befindet sich im Block spec und in der YAML-Datei für den Kubernetes-Inventarisierungsagenten von Flexera sind diese Attribute an drei Orten zusammengefasst:

• Attribute der obersten Ebene werden direkt in den Block spec eingegeben.
• Attribute für die Monitorkomponente (den Teil des Kubernetes-Inventarisierungsagenten von Flexera, der die Erstellung und Löschung von Containern für andere Anwendungen verfolgt) werden in einem monitor-Block zusammengefasst, der ein Unterblock des spec-Blocks ist.
• Attribute für die Knotenkomponente (den Teil, der Hardware-Inventar von den Kubernetes-Working-Knoten erfasst, also die physischen oder virtuellen Computer, die im Cluster ausgeführt werden) werden in einem node-Block zusammengefasst, der ein Unterblock des spec-Blocks ist.

Wenn man alle diese Elemente kombiniert, erhält man den folgenden Anfang für die generierte (oder bearbeitete) YAML-Datei:

apiVersion: agents.flexera.com/v1
kind: KRM
metadata:
  name: instance
spec:
  monitor:
    beaconURL: https://beacon.example.org
    storage:
      storageClass: default
      resources:
        requests:
          storage: 2Gi

Um Platz zu sparen, werden Attribute in der folgenden Dokumentation mit einem durch Punkt getrennten Pfad beschrieben, wie etwas folgendes Beispiel für das Pflichtattribut beaconURL:

Attribut	spec.monitor.beaconURL
Typ	String
Beispiel	https://beacon.example.org

Interpretieren Sie beim Bearbeiten der Attribute in Ihrer YAML-Datei den Attribut-Pfad folgendermaßen: Suche zuerst den spec-Block und darin den monitor-Block und darin suche [oder füge hinzu] das erforderliche Attribut (in diesem Fall beaconURL).

Tipp: Ein paar Attribute müssen in allen KRM-Ressourcen angegeben werden, die meisten Attribute jedoch sind optional und brauchen nicht angegeben zu werden, es sei denn, Sie möchten das Standardverhalten ändern. Viele der unten beschriebenen optionalen Attribute sollten als Erweiterung betrachtet werden, die nur selten und mit Anleitung von Mitarbeitern von Flexera gesetzt werden.

Optionale Konfigurationsattribute

FlexNet Manager Suite 2022 R1 (Standortgebundene Implementierung)

Tipp: Welche Konfigurationsattribute verpflichtend sind, finden Sie unter Herunterladen des Kubernetes-Inventarisierungsagenten von Flexera.

Containerimage-Registry

Per Voreinstellung basiert die Registry, von der das Containerimage abgerufen wird, auf der Registry-Komponente des Image des Controllers. Die Registry des Controllerimage wird gesetzt entweder:

• in der Operator-Konfiguration oder
• während des Installationsvorgangs.

Wenn Sie für die Pods, die den Kubernetes-Inventarisierungsagenten von Flexera enthalten, lieber eine andere Registry festlegen möchten, haben Sie dazu hier die Möglichkeit:

Attribut	spec.image.registry
Typ	String
Beispiel	registry.example.org

Imageversion

Per Voreinstellung basiert die Version des Containerimage des Agenten auf der Version des Image des Controllers. Die Imageversion des Controllers wird gesetzt entweder:

• in der Operator-Konfiguration oder
• während des Installationsvorgangs.

Wenn Sie für die Pods, die den Kubernetes-Inventarisierungsagenten von Flexera enthalten, lieber eine andere Imageversion festlegen möchten, haben Sie dazu hier die Möglichkeit:

Attribut	spec.image.version
Typ	String
Beispiel	1.0.0

Abrufen eines Image aus einer privaten Registry

Wenn Sie eine eigene, interne Registry verwenden, können Sie die entsprechenden, auf die Authentifizierungsgeheimnisse verweisenden Pointer hier hinzufügen. Diese werden an die Pods weitergeleitet, die den Kubernetes-Inventarisierungsagenten von Flexera enthalten. Jede LocalObjectReference im Array hat eine eigene Zeile und folgende Form:

     - name: thisSecretName

(Beachten Sie, dass sich dieses Attribut im spec-Block auf der obersten Ebene befindet.)

Attribut	spec.imagePullSecrets
Typ	Array von LocalObjectReference

Konfigurieren eines Clusternamens

Der Kubernetes-Inventarisierungsagent von Flexera kann den Clusternamen automatisch ermitteln, aber da es für Kubernetes keine Standardmöglichkeit gibt, den Clusternamen zu hinterlegen, kann das Ergebnis ein Name sein, der weniger Sinn ergibt als Sie es gerne hätten. Stattdessen können Sie dieses Attribut verwenden, um den von Ihnen bevorzugten Clusternamen festzulegen. (Beachten Sie, dass sich dieses Attribut im spec-Block auf der obersten Ebene befindet.)

Attribut

spec.clusterName

Typ

String

Beispiel

apiVersion: agents.flexera.com/v1
kind: KRM
spec:
  clusterName: myorg-cluster-foo

Protokollierungsebene Kubernetes-Inventarisierungsagent von Flexera

Geben Sie eine Protokollierungsebene mithilfe der folgenden Zeichenfolgen (unter Berücksichtigung von Groß- und Kleinschreibung) an:

• trace
• debug
• info (der Standardwert)
• warn
• error.

Die Protokollierungsebene kann als Attribut der obersten Ebene im spec-Block gesetzt werden. In diesem Fall gilt sie dann für alle Komponenten des Kubernetes-Inventarisierungsagenten von Flexera. Sie kann aber auch für jede Komponente einzeln gesetzt werden. Einstellungen auf Komponentenebene überschreiben Einstellungen auf oberster Ebene. Die Einstellung trace erzeugt jede Menge Protokolldaten. Ebenen oberhalb von info wie warn und error werden nicht empfohlen, da diese Ebenen das Finden und Beheben von Problemen erheblich erschweren.

Attribut

• spec.logLevel
• spec.monitor.logLevel
• spec.node.logLevel.

Typ

String

Beispiel

Info

Ein-/Ausschließen von Namensräumen

Durch die Attribute includeNamespaces und excludeNamespaces erhalten Sie eine genaue Kontrolle darüber, welche Ressourcen für den Kubernetes-Inventarisierungsagenten von Flexera sichtbar sind, indem Sie steuern, welche Namensräume zugelassen sind.

• excludeNamespaces: Per Voreinstellung ohne Wert. Der Kubernetes-Inventarisierungsagent von Flexera ignoriert alle Namensräume in dieser Liste, auch den Namensraum selbst und alle darin enthaltenen Ressourcen.
• includeNamespaces: Per Voreinstellung ohne Wert. Wenn diese Liste nicht leer ist, interpretiert der Kubernetes-Inventarisierungsagent von Flexera diese Liste als vollständige und exklusive Liste aller Namensräume, die er beobachten darf. Jeder Namensraum, der in der Liste nicht enthalten ist, wird ignoriert, gerade so, als wäre er in der Liste des alternativen Attributs excludeNamespaces enthalten.

Hinweis: Ein in beiden Listen enthaltener Namensraum wird ausgeschlossen.

Es ist (in beiden Listen) möglich, einen nicht vorhandenen Namensraum anzugeben. Da kann in Fällen hilfreich sein, in denen der Kubernetes-Inventarisierungsagent von Flexera bereitgestellt und konfiguriert wird, bevor bestimmte ein- oder auszuschließende Namensräume angelegt werden.

Tipp: Auch wenn es auf Namensräumen basierende Filter dem Kubernetes-Inventarisierungsagenten von Flexera ermöglichen, das Lesen gefilterter Objekte zu vermeiden, muss er dennoch die Liste aller Namensräume lesen, um zu ermitteln, welche Namensräume zugelassen oder ausgeschlossen sind.

Attribut

• spec.monitor.includeNamespaces
• spec.monitor.excludeNamespaces.

Typ

Array mit Zeichenfolgen

Beispiel

["kube-system", "test"]

Ein-/Ausschließen von Etiketten

Genau wie der oben beschriebene, auf Namensräumen basierende Filter stellen diese Attribute eine Möglichkeit dar, eine genaue Kontrolle darüber zu erhalten, welche Ressourcen durch den Kubernetes-Inventarisierungsagenten von Flexera überwacht werden, nur dass der Filter hier auf Etiketten basiert, die an die Ressourcen angehängt werden.

• excludeLabels: Per Voreinstellung ohne Wert. Der Kubernetes-Inventarisierungsagent von Flexera ignoriert alle Ressourcen mit einem der hier genannten Etiketten.
• includeLabels: Per Voreinstellung ohne Wert. Wenn dieses Attribut nicht leer ist, ignoriert der Kubernetes-Inventarisierungsagent von Flexera alle Ressourcen, die nicht mindestens eines der hier genannten Etiketten tragen.

Hinweis: Ein in beiden Listen enthaltenes Etikett wird ausgeschlossen.

Während das auf Namensräumen basierende Filtern (s. oben) es dem Kubernetes-Inventarisierungsagenten von Flexera ermöglicht, das Lesen gefilterter Ressourcen vollständig zu vermeiden, erfordert ein auf Etiketten basierendes Filtern, dass der Kubernetes-Inventarisierungsagent von Flexera jede Ressource liest, um zu entscheiden, ob ihre Etiketten eine Ressource zulassen oder ausschließen. Außerdem muss der Kubernetes-Inventarisierungsagent von Flexera auch versuchen, alle übergeordneten Ressourcen zu lesen (etwa das ReplicaSet eines Pods oder Deployment), um zu bestimmen, ob eine der eigentlichen Ressource übergeordnete Ressource ein aktives Etikett trägt.

Tipp: Generell erfordert ein Filtern nach Etiketten, dass die Ressource über einen passenden Schlüssel und einen passenden Wert verfügt. Eine Ausnahme bildet der spezielle Etikettenschlüssel krm.flexera.com/ignore. Jede Ressource, die diesen Etikettenschlüssel trägt (und in diesem Fall ist der Wert nicht relevant), verhält sich automatisch so, als wäre sie durch excludeLabels ausgeschlossen und der Kubernetes-Inventarisierungsagent von Flexera beobachtet sie deshalb nicht weiter.

Attribut

• spec.monitor.includeLabels
• spec.monitor.excludeLabels.

Typ

Schlüssel-Wert-Paare, durch Doppelpunkt getrennt, jedes Paar in seiner eigenen Zeile

Beispiel

environment: testing
app: particular-app

Das oben genannte Beispiel könnte in einer YAML-Datei folgendermaßen aussehen:

apiVersion: agents.flexera.com/v1
kind: KRM
metadata:
  name: instance
spec:
  monitor:
    excludeLabels:
      environment: testing
      app: particular-app

Verwalten der Patches für die config.ini

Die Datei config.ini ist eine Pseudo-Registry, die vom Kubernetes-Inventarisierungsagenten von Flexera verwendete Einstellungen enthält. Der Kubernetes-Inventarisierungsagent von Flexera bietet eine Möglichkeit, Patches für die config.ini aufzunehmen, um diese im Container zu aktualisieren (siehe Einspielen von Patches in die Datei config.ini mithilfe des Kubernetes-Inventarisierungsagenten von Flexera). Eine oder mehrere einzelne Patch-Dateien werden in einer configmap hinterlegt und diese Einstellung konfiguriert den Kubernetes-Inventarisierungsagenten von Flexera, um sich anhand des Namens auf diese configmap zu beziehen, den Sie für diese anlegen (in diesem Beipsiel „agent-config“).

Attribut

spec.monitor.configPatch

Typ

Eine ConfigMapVolumeSource, also ein Kubernetes-Typ, der beschreibt, wie eine configmap in ein Volume umgewandelt werden soll. In der Regel muss der Wert nur durch den Namen auf die configmap verweisen.

Beispiel

apiVersion: agents.flexera.com/v1
kind: KRM
spec:
  monitor:
    configPatch:
      name: agent-config

Bezugnahme auf ein Geheimnis (Secret)

Eine Möglichkeit, ein Speicher-Volume in einem Container festzulegen, ist als Kubernetes-Typ VolumeSource, Geheimnis (secret) genannt, der die Lebensspanne des Pods teilt. Wenn Sie beispielsweise benutzerdefinierte Zertifikate zur Authentifizierung von HTTPS-Kommunikation zwischen dem Kubernetes-Inventarisierungsagenten von Flexera und seiner registrierten Inventarisierungsstation hinterlegen möchten, können Sie diese Zertifikate in einem Geheimnis speichern, das Sie zum Beispiel myorg-certificates nennen. (Einzelheiten zum Einrichten des Zertifikats und des Geheimnisses finden Sie unter Supporting Custom Certificates for HTTPS.) Nachdem das Zertifikat sicher in einem Volume im Cluster hinterlegt wurde, können Sie den Kubernetes-Inventarisierungsagenten von Flexera mithilfe des Attributs spec.monitor.tlsFiles so konfigurieren, dass er dieses Volume über das Geheimnis referenziert.

Attribut

spec.monitor.tlsFiles

Typ

Ein VolumeSource-Typ, der als Geheimnis bezeichnet wird, also ein Kubernetes-Typ, der beschreibt, wie die Inhalte im RAM-basierten Speicher hinterlegt werden sollen. Der Wert braucht nur durch den Namen auf das Geheimnis (secret) zu verweisen.

Beispiel

apiVersion: agents.flexera.com/v1
kind: KRM
spec:
  monitor:
    tlsFiles:
      secret:
        secretName: myorg-certificates

Erweiterungen

Für die künftige Entwicklung reserviert, soll eine schnellere Auslieferung von Funktionen unterstützen. Das Attribut extensions ist eine Zuordnung eines String-Schlüssels zu einer LocalObjectReference, die sich auf eine ConfigMap im Cluster bezieht.

Attribut	spec.extensions
Typ	„Schlüssel: Wert“-Paare, die einen Schlüssel in Form einer Zeichenfolge zu einem LocalObjectReference-Wert in Beziehung setzen.

Hinweis: Da es noch keine Erweiterungen gibt, wird dieser Wert derzeit vom Controller ignoriert.