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.