At a customer, I implemented Control-M for Kubernetes/OpenShift, as the customer has a hybrid environment between VM, on-premise/Cloud Kubernetes/OpenShift. This is the first blog of a series, in which I will share with you from A to Z how to implement Control-M for Kubernetes and OpenShift.

Control-M for Kubernetes enables you to execute Control-M job(s) to run one or more pods to completion in a Kubernetes cluster. This enables you to integrate Control-M capabilities, such as advanced scheduling criteria, status monitoring, and SLA management.

In fact, my story with Control-M began before Kubernetes existed, today, as a Control-M and Kubernetes expert I will be able to help you to understand and implement Control-M for Kubernetes. This first blog will be more a quick overview on these technologies and understand the implementation.

To be honest, you will need at least intermediate level on Control-M and Kubernetes to implement smoothly this solution. If you want to know more about Docker and Kubernetes, I would recommend this training.

Control-M Overview

Control-M is a workload automation solution that enables you to automate the scheduling and processing the business workflows across various platforms and applications from a single point of control. Nowadays, those platforms and application could be on VM, Kubernetes cluster, Cloud, etc.

Today, Control-M allow you to execute jobs in almost every platform, but what is a job?

A job is an execution unit, each job needs specific run information to be executed, such as scheduling criteria, post processing actions, and also job dependencies as shown in the following:

On “legacy” systems, a job could be a script or command, that is executed at the operating system level. On Kubernetes, a job take another role, which allow you at the end to deploy pods in Kubernetes. Let’s get a quick overview on Kubernetes and understand pods 😉

Kubernetes Overview

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. The smallest unit of a Kubernetes application is a pod!

A Kubernetes pod is a collection of one or more Linux containers. Any given pod can be composed of multiple, tightly coupled containers or just a single container.

Control-M for Kubernetes Overview

Now, we understood Control-M jobs and Kubernetes pods, let see how those will be connected.

The following diagram demonstrates how the components of Control-M for Kubernetes are incorporated into a Kubernetes cluster and how they enable you to run one or more pods to completion.

In this example, two Control-M/Agents are deployed as cluster pods.

This setup has the following main features:

  • The Agent pods run as a StatefulSet, so that the hostname is identified consistently across pod restarts. This enables Control-M/Server to identify the Control-M/Agent continuously and consistently.
  • Agent pods use a persistent volume, so that job data and the Control-M/Agent state are kept during pod restarts.
  • The Agents belong to a host group, to ensure high availability and load balancing between the Agents.
  • Agent to Server communication is set up as a persistent connection that is initiated by the Agent. This prevents the exposure of the Kubernetes cluster to outside connections.
  • The Kubernetes plug-in adds a Kubernetes-type job to Control-M, which enables you to run one or more pods to completion in the Application namespace.

But how it works? which component allow us to create a pod inside Kubernetes?

In fact, it is mainly the role of the plug-in, which is responsible for the following stages in the execution of the Kubernetes-type job in Control-M:

  • Starts a Kubernetes job entity that runs one or more Application pods in the Application namespace in the Kubernetes cluster.
  • From Control-M, monitors the status of the job in Kubernetes until it ends when the Application pods finish running.
  • Captures the pod logs for display in the Control-M job output.
  • Deletes the Kubernetes job entity to free cluster resources.

Compatibility

Kubernetes

Control-M for Kubernetes is a generic solution for all Kubernetes-based container platforms. The following platforms were tested by BMC:

  • RedHat OpenShift
  • Amazon Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)

Supported versions of Kubernetes: 1.26-1.29

Control-M

Before any action on your system, please insure that you have at least the following versions:

ComponentMinimum version
Control-M/EM9.0.21.100
Control-M/Server9.0.20.200
Control-M Automation API9.0.21.305

Take a look on the versions that should be installed to implement Control-M for Kubernetes:

ComponentCurrent Version
Control-M9.0.21
Helm Chart9.0.21.200
Agent image9.0.21.200
Control-M Agent9.0.21.200
Kubernetes plug-in1.0.00
Java17

Conclusion

We saw together what is Control-M, OpenShift, a quick overview on how Control-M for Kubernetes will be installed, how it will work in general, and the compatibility between all versions!

In the next blog, we will start the implementation of Control-M for Kubernetes.

In the meantime, to enrich your knowledge and be ready for the next step, here are some dbi services blogs around Control-M and Kubernetes.