Make sure your environment meets the following requirements prior to installing the DataPower Operations Dashboard Cloud Agent Operator and deploying the Custom Resources.

In this page:

Software Requirements

• Kubernetes 1.25-1.31 / OpenShift Container Platform (OCP) 4.12-4.17.

• Operator Lifecycle Manager (OLM) installed on the k8s cluster (OCP includes OLM by default). For more information, see OLM QuickStart.

• IBM DataPower Gateway operator v1.8.x-v1.12.x.

• The DPOD instance and the DPOD Cloud Agent operand must have the same version modification level (e.g.: 1.0.21.x).
  For example, it is possible to connect a DPOD Cloud Agent operand of version 1.0.21.2 with a DPOD instance of version 1.0.21.1.
  However, it is highly recommended that both components have exactly the same version (e.g.: 1.0.21.2).

Resource Requirements

Storage Requirements

A block storage class that provides ReadWriteOnce (RWO) access mode and 10 IOPS (Input-Output Operations per second) that is at least 50 GB, for storing the collected data in the DPOD Cloud Agent Messaging.

Network Requirements

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 the DPOD deployment type, are detailed at Firewall Requirements.

Cloud Agent Manager Network Requirements

The manager exposes APIs to interact with the Cloud Agent and the DataPower Gateways.

Network topology:

• The manager is using the HTTPS protocol.

• The manager may have a single pod or several pods/replicas.

• The replicas are identical, and incoming traffic may arrive to any of them, using any algorithm, such as Round Robin.

• The Cloud Agent operator creates a service named <CR Name>-mng-svc with port 8443 which includes all the pods/replicas of the manager for incoming traffic.

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

• externalHost - The external host for accessing the manager service from outside the cluster.
  It is the user’s responsibility to configure this host as a DNS entry that is available to DPOD.

• externalPort - The external port for accessing the manager service from outside the cluster (default for OpenShift is 443, otherwise 30120).

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

  • Route (default for OpenShift) - The operator will create an additional Route resource which will direct its incoming traffic to the manager service.

  • NodePort (default for Kubernetes) - The operator will create the manager service as a NodePort Service.

  • Custom - The operator will not create any additional resources for exposing the manager service externally, and it is the user’s responsibility to create, update and delete such resources (e.g.: Ingress controllers, LoadBalancer services, etc.).
    For more information, see the Kubernetes documentation, Kubernetes Ingress documentation and OCP Route documentation.

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

For more information, see Manager API documentation.

Cloud Agent Messaging Network Requirements

The messaging serves the collected transactional data.

Network topology:

• The messaging is using the Kafka protocol.

• The messaging may have a single pod or several pods/replicas. The replicas count must be an odd number, since Kafka must create a quorum.

• Initial connection/discovery utilizes a bootstrap endpoint that may redirect incoming traffic to any of the messaging pods.

• Each messaging pod manages its own storage, so incoming traffic must also be able to directly connect to each of the messaging pods independently.

• The Cloud Agent operator creates a service for the bootstrap named <CR Name>-msg-bse-svc with port 29092 which includes all the pods/replicas of the messaging for incoming traffic.

• The Cloud Agent operator also creates a service for each pod/replica named <CR Name>-msg-dir-svc-x (where x starts with 0) with port 29092 which included a specific pod/replica of the messaging for incoming traffic.

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

• externalHost - The external host for accessing the messaging services 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.
  For example, if the externalHost is set to dpod-cloud-agent-messaging.mycluster.com:
  - The bootstrap endpoint will use the host dpod-cloud-agent-messaging.mycluster.com
  - The first messaging broker will use the host dpod-cloud-agent-messaging-0.mycluster.com
  - The second messaging broker will use the host dpod-cloud-agent-messaging-1.mycluster.com, and so on.
  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 services from outside the cluster.
  The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is 30100).
  For example, if the externalPortStart is set to 30100:
  - The bootstrap endpoint will use port 30100
  - The first messaging broker will use port 30101
  - The second messaging broker will use port 30102, and so on.

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

  • NodePort (default) - The operator will create the messaging services as NodePort Services.

  • Custom - The operator will not create any additional resources for exposing the messaging services externally, and it is the user’s responsibility to create, update and delete such resources (e.g.: Ingress controllers, LoadBalancer services, etc.).
    For more information, see the Kubernetes documentation, Kubernetes Ingress documentation and OCP Route documentation.

• incomingTrafficPortStart - The starting port for exposing the messaging services to incoming traffic from outside the cluster (relevant only 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).

For more information, see Messaging API documentation.

Cluster-scope Permissions

The DataPower Operations Dashboard Cloud Agent Operator requires the following cluster-scope permissions. These are brought in by ClusterRoles and bound to the operator's and the manager’s ServiceAccounts via ClusterRoleBindings.