Preparing your cluster

Before you install any of the automation containers, you must prepare a cluster for the patterns that you want to use.

About this task

Use the following checklist to prepare your cluster.

For GKE: If you plan to enable Gateway API in place of Ingress routes for Business Automation Insights deployment then you must Reserve the Gateway static IP, and provide the created GATEWAY IP name during Gateway routes creation with deployment scripts.

Table 1. Server requirements
Requirement More information
A cluster IBM Business Automation Insights includes entitlement to use Red Hat® OpenShift® Container Platform, Rancher , Tanzu, and GKE.

You can also use ROKS classic on IBM Cloud®.

Note: Virtual Private Cloud (VPC) Generation 2 compute infrastructure is supported if you use OpenShift Data Foundation (ODF) as your storage provider.

Before you deploy an automation container on IBM Cloud (your target cluster platform is ROKS), you must create an OpenShift cluster.

  1. If you do not have an account, create an account on IBM Cloud External link opens a new window or tab .
  2. If you do not have a cluster, then create one. From the IBM Cloud Overview External link opens a new window or tab page, in the OpenShift Cluster tile, click Create Cluster. Refer to the IBM Cloud documentation External link opens a new window or tab to create a Kubernetes cluster. The cluster that you create includes attached storage.
IBM® Entitled Registry entitlement key
  1. Log in to MyIBM Container Software Library External link opens a new window or tab with the IBMid and password that is associated with the entitled software.
  2. In the Container software library tile, verify your entitlement on the View library page, and then go to Get entitlement key to retrieve the key.
Remember: Take a note of the key so that the installer can enter it with the deployment script.
Capacity The administrator must make sure that the target cluster has the capacity for all of the capabilities that you plan to install.

See System requirements for IBM Business Automation Insights.
Secrets You are going to need to create secrets to store and manage sensitive information, such as passwords and ssh keys. Storing confidential information in a secret is safer and more flexible than putting it in a pod definition or in a container image. For more information, see Security considerations.
Dynamic and block storage classes The installation needs a dynamic storage class and a block storage class. The administrator must make a note of the storage classes to use, and provide the names to the user who runs the deployment script. All the container images require persistent volumes (PVs) and persistent volume claims (PVCs), so review the topics on preparing these PVs and PVCs.

For IBM Business Automation Insights, see Storage considerations.

You must set a Default Storage Class for block type storage on your OpenShift Container Platform cluster. When you have multiple storage classes, make sure that you set a default storage class.

The available storage classes can be found by running the following command:

kubectl get storageclass

The default storage class is marked as (default). The foundational services installer uses the default storage class to install MongoDB and Logging services. If you want to change the default storage class, see Change the default StorageClass External link opens a new window or tab.
OpenSearch To ensure OpenSearch pods reach a running state on a Rancher, Tanzu, or GKE cluster, set the vm.max_map_count kernel parameter to at least 262144 on each worker node. This value must be configured individually on every node in the cluster.

Use SSH to access each worker node and run the following command:

ssh root@<worker1>
sysctl -w vm.max_map_count=262144

Repeat this step for every worker node in your Rancher, Tanzu, or GKE cluster.

See the OpenSearch documentation page Important settings External link opens a new window or tab.

For more details, see Kernel parameters External link opens a new window or tab.

Note: Contact your platform vendor for assistance setting this parameter.
Nginx Ingress Controller For Rancher, create or update the HelmChartConfig object for Ingress Controller to include the enable-ssl-passthrough annotation for Kafka.
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      config:
        use-forwarded-headers: true
      extraArgs:
        enable-ssl-passthrough: true
The daemonset and pods for "ingress-nginx-controller" are automatically recreated and include the enable-ssl-passthrough flag in rke2-ingress-nginx-controller.
spec:
  containers:
    - name: nginx-ingress-controller
      image: your-nginx-ingress-image
      args:
        - /nginx-ingress-controller
        - --election-id=rke2-ingress-nginx-leader
        - --controller-class=k8s.io/ingress-nginx
        - --ingress-class=nginx
        - --configmap=$(POD_NAMESPACE)/rke2-ingress-nginx-controller
        - --validating-webhook=:8443
        - --validating-webhook-certificate=/usr/local/certificates/cert
        - --validating-webhook-key=/usr/local/certificates/key
        - --watch-ingress-without-class=true
        - --enable-ssl-passthrough=true

For more details, see the Rancher documentation page Leveraging RKE2 with TLS Passthrough External link opens a new window or tab.

For Tanzu, ensure your Ingress Controller is enabled for ssl passthrough. For more formation, see the ingress-nginx documentation External link opens a new window or tab. If there is a Load Balancer in front of the Ingress Controller, and it performs TLS termination, disable this feature so that the Ingress Controller can handle the TLS termination and re-encryption. If TKGI is running on AWS, follow the corresponding AWS example External link opens a new window or tab.
Users You need a cluster admin and a non-admin user in the OpenShift identity provider to run the scripts. Use the following steps to add a non-admin user:
  1. Move to a directory where you want to put the temp files.
    cd /home
  2. Install the htpasswd command.
    yum install httpd-tools
  3. Create a user.
    htpasswd -c -B -b users.htpasswd [username] [password]

    Replace [username] with the name of the non-admin user. Replace [password] with the password for the non-admin user.

  4. Verify that it worked.
    htpasswd -b -v users.htpasswd [username] [password]
  5. Create a secret to contain the htpasswd file. You must be logged in as the admin user to the cluster.
    kubectl create secret generic htpass-secret \
--from-file=htpasswd=./users.htpasswd \
-n openshift-config
  6. Create a config file with the htpasswd identity provider settings.
    cat <<EOF | kubectl apply -f -
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
 identityProviders:
 - name: admins_htpasswd_provider
   mappingMethod: claim
   type: HTPasswd
   htpasswd:
     fileData:
       name: htpass-secret
EOF
  7. Verify that it worked. It might take a few minutes for the update to complete.
    kubectl logout
oc login -u [username] -p [password]

    If you see an Unauthorized error, wait a few minutes more and try to login again.

For more information about users on OpenShift, see Understanding identity provider configuration External link opens a new window or tab.
Multiple deployments When you install IBM Business Automation Insights, Cloud Pak foundational services is also installed in a namespace-scoped instance. The cluster admin script, by default, uses the same namespace for foundational services as the Business Automation Insights deployment. You can install multiple instances of IBM Business Automation Insights in a cluster with multiple namespace-scoped Cloud Pak foundational services.
Synchronized worker nodes clocks IBM Business Automation Insights requires that the clocks on the worker nodes are synchronized. An OCP cluster that is installed in a restricted network is configured to use a public Network Time Protocol (NTP) server by default. To avoid clock skew, reconfigure the cluster to use a private NTP server instead. Time synchronization must be enabled on all hosts in the cluster, whether using NTP or any other method. For more information, see Configuring chrony time service External link opens a new window or tab.
Optional: Proxy servers If you plan to configure a proxy for outbound connections to external services, then set the NO_PROXY environment variable in the cluster to "*.svc" to enable all the CP4BA internal connections to work in a proxy-enabled environment. For more information, see Configuring cluster security External link opens a new window or tab.
Optional: Lightweight Directory Access Protocol (LDAP) Install an instance of LDAP for your intended deployment. You can use IBM Security® Directory Server, Microsoft Active Directory, or a custom directory server.

What to do next

Go to and complete the next step in Preparing a client to connect to the cluster.