Download Flexera Kubernetes Inventory Agent

The Flexera Kubernetes inventory agent is used to manage inventory collection within Kubernetes clusters. To deploy the Flexera Kubernetes inventory agent to one or more Kubernetes clusters requires that you make it available within the OCI container registry (the repository, or collection of repositories, used to store container images that comply with the Open Container Initiative.) In the following process, seek the assistance of your Kubernetes administrators.

As well, the infrastructure for IT Asset Management requires that, after installation, the Flexera Kubernetes inventory agent can upload inventory (.ndi) files to an inventory beacon. That inventory beacon must then be able to upload files to the central application server. Identify the URL of the inventory beacon to be used by the Flexera Kubernetes inventory agent in your (first) Kubernetes cluster, and keep the value ready for use in the following process.

Tip:If the FlexNet inventory agent is deployed into containers to collect software inventory there, it does not require direct access to an inventory beacon. In this case, the inventory .ndi files are copied out of the containers, and uploaded by the Flexera Kubernetes inventory agent together with the other .ndi files that it produces.

To download and install the Flexera Kubernetes inventory agent

Log on to a device that:

•

Runs a supported version of Linux

•

Has a web browser with network access to the web application server for IT Asset Management, where your account must have operator privileges to see the appropriate page

•

Has a running instance of Docker

•

Either hosts an OCI container registry, or has network access to an OCI container registry, that is available to your Kubernetes cluster

Tip:This process is simplified if you log in to this device using an account that has administrative privileges for your OCI container registry (otherwise you need to hand off between separate accounts during the process); and also for the Kubernetes cluster. During installation, the account requires privileges to create the following resource types:

•

Namespaces

•

ServiceAccounts

•

ClusterRoles

•

ClusterRoleBindings

•

Deployments.

The installation process creates the accounts and permissions needed for operation of the Flexera Kubernetes inventory agent and (when it is invoked to take inventory from within a container) ndtrack.sh.

In your web browser, navigate to the Inventory Settings page (Data Collection > IT Assets Inventory Tasks > Inventory Settings).

Go to the Inventory agent for download section to see the Download Flexera Kubernetes inventory agent link.

Click Download Flexera Kubernetes inventory agent and save the downloaded archive file to a suitable location.

From the downloaded archive, extract the Flexera Kubernetes inventory agent image, for example with the following command line (replacing the placeholder x.y.z with the appropriate version numbers—at the 2021 R1.4 release, these are 1.3.0):

tar xzf flexera-krm-operator-x.y.z.tar.gz

Note:The version numbers in this command are the version numbers for the Flexera Kubernetes inventory agent you have downloaded, as shown in the name of the downloaded archive. Keep in mind that the downloaded image also includes the core inventory component of FlexNet inventory agent (ndtrack.sh), which has its own distinct version number. By default, when the Flexera Kubernetes inventory agent pod is initially run on a Kubernetes node, it first asks its assigned inventory beacon for the latest policy about your settings in the Inventory agent for automatic deployment > Version to deploy section of the Inventory Settings page. If your selected version for FlexNet inventory agent does not match the one supplied in the downloaded image, the pod downloads the specified version, and subsequently uses that version of ndtrack.sh for collecting software inventory from other pods on the node. (If you do not want Flexera Kubernetes inventory agent to honor your settings in the web interface but instead use the version of ndtrack.sh included in the archived image you have just downloaded, ask your Kubernetes administrator to change the default value of downloadFromBeacon, as described in Advanced Flexera Kubernetes Inventory Agent Attributes.)

Move into the directory that was extracted from the archive:

cd flexera-krm-operator-x.y.z

Tip:The extracted image includes multiple foundational YAML files, the generate.sh script for creating your own YAML file defining your installation, and the install.sh shell script needed later to install the resulting operator in a Kubernetes cluster.

The extracted directory structure will look as follows. Directories without the suffix “aarch64” or “s390x” in the name are for the x86_64 architecture; directories with the suffix “aarch64” are for the aarch64/arm64 architecture; and directories with the suffix “s390x” are for the s390x architecture (also known as “System z” or “z/Architecture”).

|-> imgtrack-a.b.c

|-> imgtrack-a.b.c-aarch64

|-> imgtrack-a.b.c-s390x

|-> krm-d.e.f

|-> krm-d.e.f-aarch64

|-> krm-d.e.f-s390x

|-> lwk-g.h.i

|-> lwk-g.h.i-aarch64

|-> lwk-g.h.i-s390x

If you are on the x86_64 architecture, move into the krm-d.e.f directory. If you are on the aarch64/arm64 architecture, move into the krm-d.e.f-aarch64 directory. If you are on the s390x architecture, move into the krm-d.e.f-s390x directory.

cd krm-d.e.f

cd krm-d.e.f-aarch64

cd krm-d.e.f-s390x

Import the extracted image into Docker:

docker load < flexera-krm-x.y.z.tar

Note:Only one krm architecture should be imported.

Re-tag the image for your registry.

Tip:If you have multiple container registries, complete the process for each one, and then circle back to repeat the process from this point for the next registry.

In these examples, the OCI container registry is shown as images.example.com, which you replace with the URL of your own registry.

Important:The portion of the image name flexera/krm must not be changed. Simply prepend your registry URL in front of this string as shown.

docker tag flexera/krm:x.y.z images.example.com/flexera/krm:x.y.z

10.

Ensure that you are logged into your OCI container registry, using an account with administrative privileges.

11.

Push the image for Flexera Kubernetes inventory agent to your registry:

docker push images.example.com/flexera/krm:x.y.z

Only a single container image is required, as this is shared by the controller and all components of the Flexera Kubernetes inventory agent.

Tip:Having the container image in the OCI container registry allows the controller to instantiate matching containers in the Kubernetes cluster. If, instead, the image has not been pushed to an accessible registry prior to installation, the controller pods will fail to deploy (at the end of this process). To remedy: if this failure happens, you can push the container image to the registry after the controller has been deployed. The pod will periodically attempt to pull the image again; or you can speed up the process by deleting the pod itself. The ReplicaSet that manages the pod automatically re-creates the pod and immediately restarts the image pull process.

12.

Decide how you will provide persistent storage to the Flexera Kubernetes inventory agent.

The StatefulSet used by the Flexera Kubernetes inventory agent requires a PersistentVolumeClaim (PVC) that defines its storage configuration. The storage requirements are:

•

The volume is durable/reliable across restarts and upgrades of the Kubernetes pods containing the Flexera Kubernetes inventory agent

•

The volume is not shared with any other resources in the cluster

•

A minimum of 2GB of storage is available

•

The access mode must be ReadWriteOnce (this is the default for controllers)

•

The volume mode must be Filesystem (also the default for controllers).

Any configuration that meets these requirements is valid. You declare the result of your storage decision within the YAML file, next. For more information about specifying the persistent storage, see https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims.

13.

Configure kubectl correctly to connect to the correct cluster, using the appropriate account with cluster administrative privileges. For example:

kubectl config set-context cluster-one --user=administrator

This configures kubect1 such that subsequent commands (in particular, the kubectl apply used later by the installation script) refer to the cluster defined by the cluster-one context, and use the administrator user.

14.

In the expanded archive that you first downloaded, locate the install.sh script.

The install script uses the kubectl command to communicate with the Kubernetes cluster.

When the install script is run, it creates the operator for the Flexera Kubernetes inventory agent.

Tip:In Kubernetes, an 'operator' means a controller that extends the Kubernetes API using custom resources to manage an application and its components.

To do this, the install script creates the following resources in the Kubernetes cluster:

•

The krms.agents.flexera.com CustomResourceDefinition

•

The flexera Namespace

•

A ServiceAccount in the flexera Namespace for the controller

•

A ServiceAccount in the flexera Namespace for the Flexera Kubernetes inventory agent

•

A ClusterRole that defines the permissions needed by the controller, and a ClusterRoleBinding to associate that ClusterRole with the controller's ServiceAccount

•

A ClusterRole that defines the permissions needed by the Flexera Kubernetes inventory agent

•

ClusterRoleBindings associating the agent ClusterRole and the built-in view ClusterRole with the agent’s ServiceAccount

•

A Deployment of the controller application in the flexera Namespace.

15.

Install the Kubernetes operator or the Kubernetes Operator Lifecycle Manager (OLM) operator.

Note:https://gallery.ecr.aws/flexera/krm is used by the Flexera krm OLM agent – it can also be used in option A. The image can be pulled from https://gallery.ecr.aws/flexera/krm with the version tag number (for example “docker pull public.ecr.aws/flexera/krm:1.6.8”).

Note:https://gallery.ecr.aws/flexera/lwk is not related to the Flexera krm OLM agent – it is available for use like the lightweight Kubernetes Agent which is currently distributed. See Downloading the Lightweight Kubernetes Agent for more information. The image can be pulled from https://gallery.ecr.aws/flexera/lwk with the version tag number (for example “docker pull public.ecr.aws/flexera/lwk:1.5.4”).

•

Option A: To install the Kubernetes operator, run the install.sh script with the appropriate parameters (described here).

There are one mandatory parameter and two conditional parameters for this install script.

•

Mandatory—The --registry option identifies your OCI container registry for this Kubernetes cluster, and causes the install script to update the YAML file by prepending the current registry to the container image specification (just as was done in the image import process, above). (Without this parameter given to the install script, later in the process, the controller pod fails to deploy.) Example command line, using the same placeholder as before:

./install.sh --registry images.example.com

•

Conditional—If you wish your Flexera Kubernetes inventory agent to integrate with the IBM License Service, particularly for managing VPC and PVU sub-capacity licensing for standalone products or bundles such as IBM Cloud Paks, you must include the --ibm-licensing parameter. Cumulative example command line:

./install.sh --registry images.example.com --ibm-licensing

•

Conditional—If you wish your Flexera Kubernetes inventory agent to run on the OpenShift platform (from Red Hat), you must include the --openshift parameter. On this platform, the container for Flexera Kubernetes inventory agent must be run as the root user, and this option creates an appropriate SecurityContextConstraints entry and associates it with the ServiceAccount for the Flexera Kubernetes inventory agent. Cumulative example command line:

./install.sh --registry images.example.com --ibm-licensing --openshift

If your situation changes for this Kubernetes cluster, you may re-run the install script with the parameters that now apply. This overwrites your previous installation with one matching your new requirements.

For more information, see the help provided with the installation script:

./install.sh --help

You may also see the README.md file included in the downloaded archive for the Flexera Kubernetes inventory agent.

•

Option B: To install the Kubernetes OLM operator, run the olm-install.sh script with the appropriate parameters (described here).

There are three conditional parameters for this install script.

•

Conditional—If you wish to use oc rather than kubectl, you must include the --oc-as-kubectl parameter. Cumulative example command line:

./olm-install.sh --oc-as-kubectl

•

Conditional—If you wish your Flexera Kubernetes OLM inventory agent to integrate with the IBM License Service, particularly for managing VPC and PVU sub-capacity licensing for standalone products or bundles such as IBM Cloud Paks, you must include the --ibm-licensing parameter. Cumulative example command line:

./olm-install.sh --ibm-licensing --ibm-licensing-rbac

•

Conditional—If you wish your Flexera Kubernetes OLM inventory agent to run on the OpenShift platform (from Red Hat), you must include the --openshift parameter. On this platform, the container for the Flexera Kubernetes OLM inventory agent must be run as the root user, and this option creates an appropriate SecurityContextConstraints entry and associates it with the ServiceAccount for the Flexera Kubernetes OLM inventory agent. Cumulative example command line:

./olm-install.sh --ibm-licensing --ibm-licensing-rbac --openshift

For more information, see the help provided with the install script:

./olm-install.sh --help

16.

From the expanded archive that you first downloaded, run the generate.sh script.

./generate.sh

This is an interactive script that presents each option for a YAML file defining the configuration of the Flexera Kubernetes inventory agent that you require. For each option, after reading the description, you may either accept the default value, or enter your preferred value, to configure each element. These values are read by the controller and used to correctly configure the Flexera Kubernetes inventory agent, both during initial deployment and whenever corrections to the running state are required. Most of the values in the YAML file have intelligent defaults, so that only two changes are mandatory, as described here.

Note:Currently, only a single Flexera Kubernetes inventory agent is supported for a given cluster. This means that, if you already have one active within any cluster, you must merge the configuration details for Flexera Kubernetes inventory agent into your existing configuration, rather than simply creating a new YAML file. You may complete the editing process manually, if you are expert enough – use of the generate.sh script is not mandatory. For more information about the configuration structure and optional attributes, see Editing Configuration for the Flexera Kubernetes Inventory Agent.

The two mandatory changes are:

The URL of the inventory beacon accessed by the two agents in this Kubernetes cluster:

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

The configuration you chose for the persistent storage for the Flexera Kubernetes inventory agent:

Item	Description
Attribute	spec.monitor.storage
Type	PersistentVolumeClaimSpec

Tip:If you have previously customized either the access mode or the volume mode, also restore the default values for these, as described above.

When editing is complete, save the YAML file where it is accessible by kubectl command (next). You may give it your preferred name, such as fkia.yaml, provided that you refer to the correct name in the next step. (The default krm.yaml stands for “Kubernetes resource monitor”.)

17.

Apply your prepared YAML file to the cluster (substituting your chosen YAML file name):

kubectl apply -f fkia.yaml

When this process indicates success, your Flexera Kubernetes inventory agent is installed and operational on this cluster, and the controller is initialized to maintain its desired state. For additional Kubernetes clusters, repeat this process, using modified parameters as appropriate to each one.