Two FlexNet Kubernetes Agents

FlexNet Manager Suite 2023 R2 (On-Premises)

The two Kubernetes agents from Flexera are standalone applications specifically designed to capture inventory data from Kubernetes clusters. There are two implementations to choose from:

• The Flexera Kubernetes inventory agent (sometimes called the 'full' Kubernetes agent) is the primary implementation that is recommended for most organizations.
• The lightweight Kubernetes agent is intended for high security environments, omitting some features, automation, and capabilities present in the other agent in order to have the smallest possible footprint, and to provide the maximum manual control of its configuration and operation (this agent is the main focus of this section of the document you are reading).

One instance of either agent is deployed into each Kubernetes cluster as a native containerized application, and is managed using standard Kubernetes tooling. Either agent observes the cluster into which it is deployed, produces inventory files containing the observed data, and uploads the files to an existing FlexNet inventory beacon. The agent collects its information by connecting to the Kubernetes API, and using the watch interfaces to subscribe to event streams for the resources it needs to monitor. It extracts the data it needs from the API data and stores it in a local cache (either in persistent storage or in memory), periodically flushing the data out into an inventory (.ndi) file. Because both of these agents target the standard Kubernetes API, they can operate with minimal configuration on any platform based Kubernetes version 1.16 or later.

Either agent collects the following information from the cluster where its container is installed:

• Basic cluster metadata:
  • Kubernetes version
  • A unique ID for the cluster
• The nodes that compose the cluster:
  • Hardware resources
  • Serial number of the underlying server (Flexera Kubernetes inventory agent only, optional)
  • Cloud instance metadata for the underlying server (Flexera Kubernetes inventory agent only, optional)
• The Pods that are deployed in the cluster:
  • The images on which the containers are based
  • Resource limits applied to containers
  • Usage: when, how many, and for how long Pods are used
  • Software-identifying annotations applied to Pods
  • Kubernetes resources that own Pods for contextualization (optional)
• Data from the IBM License Service about IBM software (in particular, IBM Cloud Paks) running in the cluster (optional)
• Additional software content of images (Flexera Kubernetes inventory agent only, optional).

Supported architectures

The following hardware architectures are supported:

• The x86_64 architecture, which is designed for AMD and Intel 64-bit computers.
• The s390x architecture, also known as "System z", "zSystems", or "z/Architecture", which is a mainframe architecture developed and supported by IBM.
• The ARM64 architecture, also known as the AArch64 architecture, which can run on the Amazon Graviton processors.

Relationship with the FlexNet inventory agent

The two Kubernetes agents are entirely independent of the standard FlexNet inventory agent that collects full hardware and software inventory from a variety of environments (nor do they in any sense replace that standard inventory tool). They also have a separate purpose: for example, they do not collect inventory of software that may be installed on the servers acting as nodes in the cluster. In general, it is best practice that worker nodes in a Kubernetes cluster run only Kubernetes components; but where software inventory of the node servers is required, the FlexNet inventory agent can be separately installed and operated on those servers.

Restriction: When either Kubernetes agent is collecting Kubernetes-related inventory for a cluster, and when the FlexNet inventory agent is also deployed to any node server(s), the container inventory feature of the FlexNet inventory agent should not be enabled. That feature targets a locally-running Docket daemon, so that, for nodes running Docker as a container runtime, in this scenario there will be duplicate inventory reports from the two kinds of inventory agents. Because Kubernetes supports a variety of container runtimes, it adds abstractions around the runtime which may prevent the two inventory reports being 'socialized' – that is, recognized as two reports of the one item that should be merged. The result may be a double-counting of containers – to prevent which, do not enable the container inventory feature of the FlexNet inventory agent in this scenario.

Choosing between the agents

The full Flexera Kubernetes inventory agent is recommended for most environments, because it offers relative ease of use and complete software inventory of the contents of containers. The lightweight Kubernetes agent can be considered for cases where some third-party tool is used to take inventory of container images, and where the additional requirements of the Flexera Kubernetes inventory agent are not a good fit with your enterprise policies governing your Kubernetes environment. The decision between these two agents normally involves a conversation between your ITAM team and the platform team managing your Kubernetes environment.

When choosing between the Flexera Kubernetes inventory agent and the lightweight Kubernetes agent, the following factors may assist:

Factor	Flexera Kubernetes inventory agent	lightweight Kubernetes agent
Configuration	May be automated.	Requires manual specification, either with command-line flags on the installer, or editing of .yaml files.
Persistent storage	Requires persistent storage within its container.	Primarily intended to operate without persistent storage (although this can be configured as usual within Kubernetes).
Permissions	Controlled by role, includes read/write options. Requires limited Kubernetes write permissions as part of automated management. Normally run as a root user (especially if calling the FlexNet inventory agent).	Fewest possible permissions, and read-only. Can run as a non-root user.
Operator pattern	Required option (which requires write permissions in the controller).	Not supported.
Container image	Default image supplied, including pre-configuration. Includes standard (Linux) OS layer.	"From scratch" (single, stand-alone binary executable, written in Go), with manual configuration required. Container can be immutable at run time.
Integration with IBM License Service	Supported (off by default, must be enabled).	Supported (off by default, must be enabled).
Additional software inventory	Can inject the FlexNet inventory agent temporarily into a container to collect inventory of ancillary software. Minimizes this process by assessing only one container per image.	Not supported. Other than reporting IBM Cloud Paks (through integration with IBM License Service), third-party tools are required to take inventory of software within containers.
Prerequisite software	The following software tools must be installed: yq kustomize kubectl	The following software tools must be installed: yq kubectl

Installation instructions

To download and install the Flexera Kubernetes inventory agent, see the topic "Download Flexera Kubernetes Inventory Agent" in the Online Help.

To download and install the lightweight Kubernetes agent, see The Lightweight Kubernetes Agent.