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:
Component | Minimum version |
Control-M/EM | 9.0.21.100 |
Control-M/Server | 9.0.20.200 |
Control-M Automation API | 9.0.21.305 |
Take a look on the versions that should be installed to implement Control-M for Kubernetes:
Component | Current Version |
Control-M | 9.0.21 |
Helm Chart | 9.0.21.200 |
Agent image | 9.0.21.200 |
Control-M Agent | 9.0.21.200 |
Kubernetes plug-in | 1.0.00 |
Java | 17 |
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.