Editing the Kubernetes Resource Model
FlexNet Manager Suite
2021 R1
(On-Premises)
The Kubernetes Resource Model (KRM) specifies the resources that together define the
application to be deployed into a Kubernetes cluster, which in this case is the Flexera Kubernetes inventory agent. The relevant resources are specified in a file written in the
lightweight, human-readable YAML language. A template YAML file, ready for your
customization, is included in the downloaded archive for the Flexera Kubernetes inventory agent
(as described in Download Flexera Kubernetes Inventory Agent). This topic
provides extra detail about attributes specified in the YAML file, in case you want to
delve deeper in your customization.
Attention: 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 described above. To avoid that
confusion, in this documentation the KRM acronym always refers to the
Kubernetes Resource Model, and most often to the specific declarations within that
model that define the Flexera Kubernetes inventory agent — always, that is, with one
exception.
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, which is a kind of
Kubernetes resource monitor, shown in this declaration as
KRM
:kind: KRM
This is the only
place where KRM
should be read as "Kubernetes resource
monitor". Everywhere else, read "KRM" as a quick reference to the
Kubernetes Resource Model, and as a shorthand reference to the declarations made
in that Model in the YAML file for the Flexera Kubernetes inventory agent.Tip: 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 KRM, 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 that you customize for each
different cluster. FlexNet Manager Suite (On-Premises)
2021 R1
Basic structural elements
FlexNet Manager Suite
2021 R1
(On-Premises)
Every KRM-related 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 KRM file applies. This does not have any
namespace, because the overall KRM 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
So when editing the KRM in the supplied YAML file, interpret the
Attribute path to say, "First find the
spec
block, and
in the KRM 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 thespec
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 thespec
block.
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 |
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.
FlexNet Manager Suite (On-Premises)
2021 R1
Optional KRM attributes
FlexNet Manager Suite
2021 R1
(On-Premises)
Tip: For mandatory KRM 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.
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.
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. EachLocalObjectReference
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 |
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
.
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 |
|
Type | String |
Example | Info |
Include/exclude namespaces
TheincludeNamespaces
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 alternativeexcludeNamespaces
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 |
|
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 |
|
Type | Key-value pairs, separated by a colon, each on its own line |
Example |
|
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. Theextensions
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.
FlexNet Manager Suite (On-Premises)
2021 R1