Skip to main contentIBM DataPower Operator Documentation

Prerequisites

Ensure your environment meets the following requirements prior to installing the DataPower Operator and deploying Custom Resources.

Container environment

Supported platforms

The DataPower Operator currently supports:

  • OpenShift Container Platform (OCP) 4.6+
  • Kubernetes 1.19+

Worker node configuration

Installation of the DataPower Operator does not support adding Tolerations to the Operator Deployment resource out-of-the-box. To install properly, there must be one worker in the desired availability zone that is not tainted. If Tolerations are nonnegotiable, you can install the DataPower Operator using the helm chart and add the Tolerations to the Deployment template manually.

Resource requirements

Operator

The DataPower Operator’s Deployment uses the following resource spec:

resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: 2
memory: "2Gi"

For more information on what this spec means, see Managing Resources for Containers.

Operand

  • The minimum resource requirements for a single DataPower container are 1 CPU and 4 GB memory.
  • For API Connect workloads, a minimum of 8 GB of memory is required per container.
  • For production high-availability, a minimum of 3 replicas (one per node) are recommended.

Cluster-scope permissions

The DataPower Operator requires the following cluster-scope permissions. These are brought in by a ClusterRole and bound to the operator’s ServiceAccount via ClusterRoleBinding.

Permissions to manage CustomResourceDefinition defaulting and validating webhooks:

  • API Groups: admissionregistration.k8s.io
  • Resources: mutatingwebhookconfigurations, validatingwebhookconfigurations
  • Verbs: create, delete, get, list, patch, update, watch

Permissions needed for reconciliation of admission controllers (webhooks):

  • API Groups: rbac.authorization.k8s.io
  • Resources: clusterroles, clusterrolebindings
  • Verbs: get, list

Permissions needed for management of owned CustomResourceDefinitions:

  • API Groups: apiextensions.k8s.io
  • Resources: customresourcedefinitions
  • Verbs: get, update

Permissions needed for management of conversion webhook, which can exist in other namespaces:

  • API Groups: (none)
  • Resources: namespaces
  • Verbs: get, list

Permissions needed for management of conversion webhook, which can exist in other namespaces:

  • API Groups: (none)
  • Resources: services, secrets
  • Verbs: create, delete, get, list, patch, update, watch

Permissions needed for management of conversion webhook, which can exist in other namespaces:

  • API Groups: apps
  • Resources: deployments
  • Verbs: create, delete, get, list, patch, update, watch

Permissions needed for conversion webhook implementation across namespaces:

  • API Groups: datapower.ibm.com
  • Resources: *
  • Verbs: create, delete, get, list, patch, update, watch

Permissions needed for OCP platform related checks:

  • API Groups: config.openshift.io
  • Resources: clusterversions
  • Verbs: get

Optional: Multiple Failure Zones

The DataPower Operator Deployment is designed to pods evenly across multiple Kubernetes zones. To take advantage of this functionality, follow the prerequisites for Pod Topology Spread Constraints.

With EvenPodsSpread enabled in the cluster, no more than one DataPower Operator pod will be deployed per zone. If replicaCount is higher than the number of available zones, the remaining replicas will not be scheduled.

Optional: Vertical Pod Autoscaler

The DataPower Operator supports Vertical Pod Autoscaling of the DataPowerService operand. If you wish to utilize this functionality, the Vertical Pod Autoscaler must be first installed and configured in your Kubernetes or OpenShift cluster.

Installing on Kubernetes

For traditional Kubernetes clusters, reference the Kubernetes documentation for installation.

Installing on OpenShift

For OpenShift clusters, reference the OpenShift documentation for installation.

Configure RBAC

To enable the VPA to provide scaling recommendations for the DataPowerService operand, a ClusterRole and ClusterRoleBinding must be created and links to the vpa-recommender Service Account installed with VPA.

Depending on whether you are installing on normal Kubernetes or OpenShift (OCP), the namespace of the vpa-recommender Service Account may vary. For Kubernetes, it is most likely kube-system, and for OCP it is most likely openshift-vertical-pod-autoscaler.

  1. Determine the namespace of the vpa-recommender Service Account. If you are not sure, you can find it with the following:

    $ kubectl get sa --all-namespaces | grep vpa-recommender
    openshift-vertical-pod-autoscaler vpa-recommender 2 177m

    The first column indicates the namespace, i.e. openshift-vertical-pod-autoscaler.

  2. Create the ClusterRole resource, using the following YAML:

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: datapower-operator-vpa-recommender
    rules:
    - apiGroups:
    - datapower.ibm.com
    resources:
    - datapowerservices/scale
  3. Create the ClusterRoleBinding resource, using the following YAML as a template. The namespace under subjects must match the namespace determined in Step 1.

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: datapower-operator-vpa-recommender
    subjects:
    - kind: ServiceAccount
    name: vpa-recommender
    namespace: openshift-vertical-pod-autoscaler
    roleRef:

Optional: Certificate Manager

Certificates used by the operator and webhook pods will be configured to be automatically managed by cert-manager when cert-manager version v1.0 or later deployment is detected in the cluster during operator installation.