Editing Configuration for the Flexera Kubernetes Inventory Agent

The Flexera Kubernetes inventory agent is regarded as an application to be deployed into a Kubernetes cluster, and is defined by a fixed set of Kubernetes "resources". The relevant resources must be specified in a file written in the lightweight, human-readable YAML language. In the downloaded archive for the Flexera Kubernetes inventory agent (as described in Download Flexera Kubernetes Inventory Agent), there is an interactive script called generate.sh to help you define these resources in a YAML file, if you wish to use it. Alternatively, you may prefer to edit the YAML file in your preferred text editor. This topic provides extra detail about attributes specified in the YAML file, in case you want to delve deeper in your customization.

Tip:The purpose of the Flexera Kubernetes inventory agent is to monitor the activity of resources within your Kubernetes clusters — or, put another way, it is a Kubernetes resource monitor. Obviously, when reduced to an acronym, this is KRM, with potential for confusion with the more widely known Kubernetes Resource Model. In the opening two lines of the YAML file (the GVK, as described next), there is a “key: value” pair for the kind attribute. This attribute defines the kind or type of object declared in this YAML file. In our case, the object is the Flexera Kubernetes inventory agent, expressed in this declaration as:

kind: KRM 

Here, KRM should be read as “Kubernetes resource monitor”, referring directly to the Flexera Kubernetes inventory agent, for which the declarations are made in the YAML file. In other places, you may find “KRM” used as a quick reference to the Kubernetes Resource Model, so we will try to avoid confusion. If you have multiple clusters needing to share the same configuration details for Flexera Kubernetes inventory agent, you may copy the same YAML file to each of those clusters (but remember to check for a unique URL for the inventory beacon to be used within each cluster), and use it while running the install.sh script that you customize for each different cluster.

Important:Each cluster, create only one YAML file that includes declarations for Flexera Kubernetes inventory agent, for the following reason. A component within the Flexera Kubernetes inventory agent is the node agent that collects hardware information for each worker node in a cluster. Within the Flexera Kubernetes inventory agent, this is implemented as a DaemonSet to ensure that exactly one instance runs on each node. Therefore be sure that in each cluster, you have only one YAML file of resource declarations for an application/ object of:

kind: KRM 

However, if you have multiple clusters needing to share the same configuration details for Flexera Kubernetes inventory agent, you may copy the same YAML file to each of those clusters (but remember to check for a unique URL for the inventory beacon to be used within each cluster), and use it while running the install.sh script for each different cluster.

Basic Structural Elements

Every Kubernetes configuration file begins with a static preamble that defines its type and the version of the Kubernetes API that it references. This is followed by the kind attribute, declaring the kind or type of resource that is being defined. Together, these preamble elements are called the GroupVersionKind (GVK). For example:

apiVersion: agents.flexera.com/v1

kind: KRM

Next comes the standard metadata block, which typically identifies the name of the image to which this YAML file applies. This does not have any namespace, because the overall configuration file is cluster scoped (applies to the entire Kubernetes cluster within which it is defined).

metadata:

  name: instance

The rest of the configuration is nested within the spec block, and in the YAML file for the Flexera Kubernetes inventory agent, these attributes are grouped in three places:

Top-level attributes are entered directly in the spec block
Attributes for the monitor component (the part of the Flexera Kubernetes inventory agent that tracks the creation and removal of containers for other applications) are grouped in a monitor block that is a child of the spec block
Attributes for the node component (the part that collects hardware inventory from the Kubernetes working nodes, the physical or virtual computers running within the cluster) are grouped in a node block that is a child of the spec block.

Combining all these elements gives the following opening to the generated (or edited) YAML file:

apiVersion: agents.flexera.com/v1

kind: KRM

metadata:

  name: instance

spec:

  monitor:

    beaconURL: https://beacon.example.org

    storage:

      storageClass: default

      resources:

        requests:

          storage: 2Gi

To save space, attributes in following documentation are described with a dot-separated path, such as the following for the beaconURL mandatory attribute:

Item

Description

Attribute

spec.monitor.beaconURL

Type

String

Example

https://beacon.example.org

When editing the Kubernetes Resource Model in the supplied YAML file, interpret the Attribute path to say, “First find the spec block, and within that find the monitor block, and within that find [or add] the required attribute (in this case beaconURL).”

Tip:A few attributes must be specified in all KRM resources, but most attributes are optional, and do not need to be specified unless you want to alter the default behavior. Many of the optional attributes described below should be considered advanced, to be set in rare circumstances and with guidance from Flexera personnel.

Optional Kubernetes Resource Model Attributes

Tip:For mandatory Kubernetes Resource Model attributes, refer to Download Flexera Kubernetes Inventory Agent.

Container Image Registry

By default, the registry from which the container image is pulled is based on the registry component of the controller's image. The controller's image has its registry set either:

In the operator configuration, or
During the installation process.

If you would like to specify a different registry for the pods containing Flexera Kubernetes inventory agent, you can do so here.

Item

Description

Attribute

spec.image.registry

Type

String

Example

registry.example.org

Image Version

By default, the version of the agent container image is based on the version of the controller's image. The controller's image has its version set either:

In the operator configuration, or
During the installation process.

If you would like to specify a different version of the image for the pods containing Flexera Kubernetes inventory agent, you can do so here.

Item

Description

Attribute

spec.image.version

Type

String

Example

1.0.0

Pull an Image from a Private Registry

When using your own internal registry, you can add the appropriate pointers to the authentication secrets here. These will be propagated to the pods containing Flexera Kubernetes inventory agent. Each LocalObjectReference in the array is on its own line and is of the form:

     - name: thisSecretName

Notice that this attribute sits within the top level spec block.

Item

Description

Attribute

spec.imagePullSecrets

Type

Array of LocalObjectReference

Flexera Kubernetes Inventory Agent Logging Level

Specify a logging level, using one of the following case-sensitive strings:

trace
debug
info (the default value)
warn
error.

The logging level can be set as a top-level attribute on the spec block, in which case it applies to all components of Flexera Kubernetes inventory agent; or it can be set on each of the components individually. Component-level settings override top-level settings. The trace setting produces a high volume of logging information. Levels above info such as warn and error are not recommended, as these levels make troubleshooting issues considerably more difficult.

Item

Description

Attribute

spec.logLevel

spec.monitor.logLevel

spec.node.logLevel

Type

String

Example

Info

Include/Exclude Namespaces

The includeNamespaces and excludeNamespaces attributes give you granular control over what resources are visible to the Flexera Kubernetes inventory agent by controlling which namespaces are permitted.

excludeNamespaces—By default this is empty. The Flexera Kubernetes inventory agent ignores any namespace that appears in the list, including the namespace itself and all of the resources it contains.
includeNamespaces—By default this is empty. If the list is not empty, the Flexera Kubernetes inventory agent interprets the list as a complete and exclusive list of all the namespaces it is permitted to observe. Any namespace not included in the list is ignored, just as if it were included in the alternative excludeNamespaces attribute.

Note:A namespace specified in both lists is excluded.

It is valid to specify (in either list) a namespace that does not exist. This can be useful in cases where the Flexera Kubernetes inventory agent is deployed and configured before certain namespaces that should be excluded or included are created.

Tip:While namespace-based filtering allows the Flexera Kubernetes inventory agent to avoid reading filtered objects, it still needs to read the list of all namespaces in order to determine which namespaces are permitted or excluded.

Item

Description

Attribute

spec.monitor.includeNamespaces

spec.monitor.excludeNamespaces

Type

Array of strings

Example

["kube-system", "test"]

Include/Exclude Labels

Like the namespace-based filtering mechanisms above, these attributes allow fine-grained control over what resources are observed by the Flexera Kubernetes inventory agent, except that the filtering is based on labels applied to resources.

excludeLabels—By default this is empty. The Flexera Kubernetes inventory agent ignores any resource that bears any of the labels specified here.
includeLabels—By default this is empty. If the this attribute is not empty, the Flexera Kubernetes inventory agent ignores any resource that does not bear at least one of its labels.

Note:A label specified in both lists is excluded.

While namespace-based filtering (above) allows the Flexera Kubernetes inventory agent to completely avoid reading filtered resources, label-based filtering requires the Flexera Kubernetes inventory agent to read each resource to decide whether its labels permit or exclude the resource. Further, the Flexera Kubernetes inventory agent needs to try to read each parent resource (like a pod's ReplicaSet, or Deployment, for example), in order to determine whether any of the resource's parents have an operative label.

Tip:In general, label filtering requires that the resource has a matching key and a matching value. The exception is the special label key krm.flexera.com/ignore. Any resource that bears this label key (and in this case, the value is irrelevant) automatically acts as if it were filtered by excludeLabels, and the Flexera Kubernetes inventory agent does not continue to observe it.

Item

Description

Attribute

spec.monitor.includeLabels

spec.monitor.excludeLabels

Type

Key-value pairs, separated by a colon, each on its own line

Example

environment: testing

app: particular-app

The example above might look like this in a YAML file:

apiVersion: agents.flexera.com/v1

kind: KRM

metadata:

  name: instance

spec:

  monitor:

    excludeLabels:

      environment: testing

      app: particular-app

Extensions

Reserved for future development, intended to support faster delivery of features. The extensions attribute is a mapping of a string key to a LocalObjectReference that refers to a ConfigMap in the cluster.

Item

Description

Attribute

spec.extensions

Type

Key: value pairs, relating a string key to a LocalObjectReference value

Note:As there are no extensions as yet, this value is currently ignored by the controller.