Control-M for Kubernetes – Preparation

As promised in the first blog of this series, here we are with the second blog to show you how to prepare the Control-M for Kubernetes solution, this solution allow to create and start Kubernetes pods using Control-M jobs.

To implement Control-M for Kubernetes you will need to verify and prepare some prerequisites, like check access, compatibility with OS, persistent storage, memory, firewall, aso.

The compatibility between Control-M components has been shown in the previous blog.

Access

First of all, the following access should be delivered to the expert(s) to allow a smooth implementation of Control-M for Kubernetes:

• Full admin access to Control-M UI
• Access on the servers hosting the Control-M Server and Control-M EM
• Sudo to Control-M EM user, and Control-M/Server user
• Access to OpenShift or Kubernetes cluster
• A valid account to access BMC Support Central / Electronic Product Distribution to download Control-M plugins.

Compatibility

Additionally to the Control-M components compatibility, the Control-M Automation API Command Line Interface (CLI) will not be available on the following platforms as they do not support a secure version of Node.js:

• Amazon Linux 2
• SUSE Linux 12
• Red Hat 7
• Oracle Linux 7
• CentOS 7

Please be sure that you are on a version compatible with the Control-M Automation API CLI.

Persistent Storage

Prepare a persistent Storage that will be used by Control-M Agents for storage on OpenShift or Kubernetes cluster. Basically, the persistent volume ensures that job data and Agent state are kept during pod restarts.

BMC recommends that you run multiple Agents on separate nodes in the namespace. The default is two Agents.

To support multiple Agents, the storage class (and underlying storage technology) must support ReadWriteMany access mode. The recommended storage size is minimum 5Gi per agent (by default 10Gi).

If NFS Storage Class is used, ensure that the UID and GID, which are Storage Class parameters for dynamic provisioning, are set to the following values:

• UID=1000  
• GID=0

Memory

By default, there could be some limitation in your cluster, please review the limitations on pods/containers memory.

For example, via the OpenShift console, adapt the maximum memory authorized to allow 2Gi of memory, which is the default value of Helm Control-M Agent installation.

Firewall

Some rules need to be configured on Firewall level, to authorize the agent to reach out to Control-M. The list of ports depends on your organization, in mine the ports opened where 7005-7015 + 13075.

There is no need to open the Firewall from server to agent, or to configure any ingress, as it uses the cluster API entry point.

When all prerequisites are ready, you can move forward to publish Plug-In, get the API Token, prepare and deploy the Control-M agent on Kubernetes. These steps will be shared in the next blog so stay connected 😉

For further reading, please find all blogs around Control-M, and Kubernetes.