Editing configuration for the Flexera Kubernetes Inventory Agent

IT Asset Management (Cloud)

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.

Important: For 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.

IT Asset Management (Cloud)

Current

Basic structural elements

IT Asset Management (Cloud)

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). The following GVK is mandatory in every YAML file defining the Flexera Kubernetes Inventory Agent:

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

Next comes the standard metadata block, which typically identifies the name of the object to which this YAML file applies. In this case, the metadata block does not have a namespace attribute, because the KRM kind (for the Flexera Kubernetes Inventory Agent) 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:

Attribute	`spec.monitor.beaconURL`
Type	String
Example	`https://beacon.example.org`

So when editing the attributes in your 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 configuration attributes

IT Asset Management (Cloud)

Tip: For mandatory configuration attributes, refer back 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.

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.

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.)

Attribute	`spec.imagePullSecrets`
Type	Array of LocalObjectReference

Configuring a cluster name

The Flexera Kubernetes Inventory Agent can automatically discover the cluster name, but because there is no standard way for Kubernetes to store the cluster name, this can result is a name that is less meaningful than you prefer. Instead, you may use this attribute to specify the cluster name that you prefer. (Notice that this attribute sits within the top level spec block.)

Attribute	`spec.clusterName`
Type	String
Example	`apiVersion: agents.flexera.com/v1 kind: KRM spec: clusterName: myorg-cluster-foo`

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.

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.

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.

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

Managing patches to config.ini

The config.ini file is a pseudo-registry that contains settings used by the standard FlexNet Inventory Agent. The Flexera Kubernetes Inventory Agent provides a way to include patches for config.ini to update it within the container (see Patching config.ini through Flexera Kubernetes Inventory Agent). One or more individual patch files are stored in a configmap, and this setting configures the Flexera Kubernetes Inventory Agent to reference that configmap by the name you chose to create for it (in this example, "agent-config").

Attribute	`spec.monitor.configPatch`
Type	A ConfigMapVolumeSource, a Kubernetes type that describes how a `configmap` should be converted into a volume. Typically, the value only needs to refer to the `configmap` by name.
Example	`apiVersion: agents.flexera.com/v1 kind: KRM spec: monitor: configPatch: name: agent-config`

Referencing a Secret

One way to specify a storage volume within a container is as a Kubernetes VolumeSource type called a secret, storage that shares the life of the pod. For example, if you wish to store custom certificate(s) used to authenticate HTTPS communications between the Flexera Kubernetes Inventory Agent and its registered inventory beacon, you might store those certificate(s) in a secret that you choose to name, say, myorg-certificates. (For details about setting up the certificate and the secret, see Supporting Custom Certificates for HTTPS.) Once the certificate is safely stored in a volume within the cluster, you may configure the Flexera Kubernetes Inventory Agent to reference that volume through the secret using the spec.monitor.tlsFiles attribute.

Attribute	`spec.monitor.tlsFiles`
Type	A VolumeSource type called a `secret`, a Kubernetes type that describes how the contents should be saved in RAM-based storage. The value only needs to refer to the `secret` by name.
Example	`apiVersion: agents.flexera.com/v1 kind: KRM spec: monitor: tlsFiles: secret: secretName: myorg-certificates`

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.

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.