In this page:

Overview

The DPOD Cloud Agent component allows support for IBM DataPower Gateways deployed in Kubernetes/OpenShift, and includes the following features:

...

• Cloud Agent Operator - manages the installation of the Cloud Agent instances and the discovery of the DataPowerService resources in the cluster.

• Cloud Agent Manager - performs auto-discovery of the DataPower Gateway pods, exposes APIs to DPOD to interact with the Cloud Agent the the DataPower Gateways, maintains the topics in the messaging component, sends keepalive messages, etc.

• Cloud Agent Messaging - stores the collected data from the DataPower gateways until it is processed by DPOD.

• Cloud Agent Syslog Ingester - receives Syslog messages from the DataPower Gateways.

• Cloud Agent HTTP Ingester - receives HTTPS messages from the DataPower Gateways, such as WS-M payloads, API-C Analytics offload, etc.

Available Versions

Operator Installation Mode

...

Network Configuration

The Cloud Agent communicates with the DataPower Operations Dashboard instance which is installed outside the Kubernetes cluster. Therefore, proper inbound (ingress) communication must be configured for the different services of the Cloud Agent.

The firewall requirements for the Cloud Agent based on DPOD deployment type are detailed here Firewall Requirements

Custom Network Configuration

The Cloud Agent operator includes several standard types of network configuration, such as NodePort and Route (for OpenShift).

However, it is also possible to use a custom network configuration. If you choose to use a custom network configuration, the Cloud Agent operator will not create any resources for exposing the services externally to the cluster, and it is the user’s responsibility to create, update and delete these resources (e.g.: Ingress controller, LoadBalancer services, etc.).

• For more information, see the Kubernetes documentation.

• For Ingress configuration see Kubernetes Ingress documentation.

• For Route configuration see OCP Route documentation.

Cloud Agent Manager

The manager exposes APIs to interact with the Cloud Agent and the DataPower Gateways. It is using the HTTPS protocol.

The following properties (in the Cloud Agent CR) control the way DPOD communicates with the manager:

• externalHost - The external host for accessing the manager from outside the cluster. It is the user’s responsibility to configure this host as a DNS entry that is available to DPOD. You can inspect the generated host in .status.endpoints of the Cloud Agent CR (see also Endpoints).

• externalPort - The external port for accessing the manager from outside the cluster (default is 443).

• incomingTrafficMethod - The method of exposing the manager to incoming traffic from outside the cluster. Available options are:

  • Route (default and available for OpenShift only) - the operator will create a Service and a Route resources.

  • NodePort (default for Kubernetes) - the operator will create a NodePort Service resource.

  • Custom - see “Custom Network Configuration” above.

• incomingTrafficPort - The port for exposing the manager to incoming traffic from outside the cluster (when incomingTrafficMethod is NodePort, default is the value of externalPort).

For more information, see Manager API documentation.

Cloud Agent Messaging

The messaging serves the collected transactional data. It is using the Kafka protocol.

The following properties (in the Cloud Agent CR) control the way DPOD communicates with the messaging:

• externalHost - The external host for accessing the messaging from outside the cluster. This value will be published by the messaging brokers (Kafka). The bootstrap endpoint will use this host, and each messaging broker will use a consecutive host name with its number at the end of the first part of the FQDN. It is the user’s responsibility to configure these hosts as DNS entries that are available to DPOD. You can inspect the list of the generated hosts in .status.endpionts of the Cloud Agent CR (see also Endpoints).

• externalPortStart - The starting external port for accessing the messaging from outside the cluster. The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is 30100).

• incomingTrafficMethod - The method of exposing the messaging to incoming traffic from outside the cluster. Available options are:

  • NodePort (default) - the operator will create NodePort Service resources (one for the bootstrap <CR name>-msg-bse-svc and one for each messaging broker <CR name>-msg-dir-svc-<broker number>).

  • Custom - see “Custom Network Configuration” above.

• incomingTrafficPortStart - The starting port for exposing the messaging to incoming traffic from outside the cluster (when incomingTrafficMethod is NodePort). The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is the value of externalPortStart).

...