Overview
The DPO Cloud Agent component allows support for IBM DataPower Gateways deployed in Kubernetes/OpenShift, and includes the following features:
Automatic discovery of IBM DataPower Gateways as they are deployed, scaled up or scaled down by the DataPower k8s Operator.
The collected data is stored in a persistent messaging layer until it is processed by DPOD.
The DPOD Cloud Agent is highly available and can be scaled up or down as required.
It includes the following components:
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.
Installation Mode
When installing an operator via OLM, there are two options for the Installation Mode:
All namespaces on the cluster:
AllNamespaces
(aka cluster scope)A specific namespace on the cluster:
OwnNamespace
(aka namespace scope)
In AllNamespaces
mode, the Operator will use a ClusterRole
and ClusterRoleBinding
and using that will have cluster-wide scope to manage DataPower Operations Dashboard Cloud Agent resources across all namespaces. In OwnNamespace
mode, the operator will use a Role
and RoleBinding
as its primary access (limited to the namespace it's installed in), with a limited set of ClusterRole
permissions (see Cluster-scope permissions).
Do not install the Operator in more than one mode. If AllNamespaces
is chosen, do not subsequently install a second instance in OwnNamespace
mode.
Available Versions
DPOD Version | Cloud Agent Operator Version |
---|---|
1.0.19.0 | 0.1.0 |
DPOD Cloud Agent Network Configuration
The Cloud Agent sends and receives data to / from the DataPower Operations Dashboard instance which is installed outside the Kubernetes cluster.
Currently the DPOD Cloud Agent Operator supports the following methods for exposing the Cloud Agent’s services:
NodePort - (default) The Cloud Agent operator will create services with the type of
NodePort
to expose the services externally to OCP.Custom - The Cloud Agent operator will not create any resources for exposing the services externally to OCP, 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.
Forroute
, configuration see OCP Route documentation.
Foringress
configuration see Kubernetes Ingress documentation.
Cloud Agent Inbound (ingress) Communication
The Cloud Agent inbound communication includes:
Management API invocation generated by DataPower Operations Dashboard to the
manager
component of the Cloud Agent.Kafka communication to the
messaging
component of the Cloud Agent (messaging brokers).
Manager
The manager
component has a number of properties (in the Cloud Agent CR) for controlling the communication:
incomingTrafficMethod
- The method of exposing the manager to incoming traffic from outside the cluster.
Available options are:Custom
,NodePort
,Route
(default isRoute
for OpenShift andNodePort
for Kubernetes).externalHost
- The external host for accessing the manager from outside the cluster.externalPort
- The external port for accessing the manager from outside the cluster (default is 443).incomingTrafficPort
- The port for exposing the manager to incoming traffic from outside the cluster (whenincomingTrafficMethod
isNodePort
, default is the value ofexternalPort
).
For more information, see Manager API documentation.
Messaging
The messaging component has a number of properties (in the Cloud Agent CR) for controlling the communication:
incomingTrafficMethod
- The method of exposing the messaging to incoming traffic from outside the cluster.
Available options are:Custom
,NodePort
(default isNodePort
).externalHost
- The external host for accessing the messaging from outside the cluster. This value will be published by the messaging brokers (Kafka).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).incomingTrafficPortStart
- The starting port for exposing the messaging to incoming traffic from outside the cluster (whenincomingTrafficMethod
isNodePort
). The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is the value ofexternalPortStart
).
For more information, see Messaging API documentation.
The Cloud Agent Operator will create the following Kubernetes services for the messaging component:
<CR name>-msg-bse-svc
- ANodePort
service for externally accessing the messaging bootstrap port.<CR name>-msg-dir-svc-<broker number>
- ANodePort
service for each messaging broker (starting with zero) for external direct access to this broker, which uses portexternalPortStart
+1 (e.g.: 30101, 30102, etc).