MySQL NDB Cluster, the distributed version of MySQL, is implemented as a collection of processes or nodes of the following three types:
NDB Operator provides services that allow for connections of the following two types:
NDB Operator currently does not provide a mechanism for NDB API applications to connect directly to the NDB Cluster data nodes. This means that NDB utility programs such as ndb_select_all and ndb_restore are not supported under NDB Operator.
Deploying MySQL Cluster in a Kubernetes cluster requires scheduling these nodes onto different pods using multiple workload resources, as well as time and effort to choose and create the right type of workload resources in a configuration that takes full advantage of the redundancy and fault tolerance features found in both NDB Cluster and Kubernetes Cluster.
NDB Operator is the Kubernetes Operator for MySQL NDB Cluster, and is intended to simplify the task of deploying and managing MySQL Cluster in a Kubernetes Cluster. A Kubernetes operator is an application having operational knowledge of another application. It can be deployed within the Kubernetes Cluster after which it can begin monitoring the endpoints in which they are interested, and making changes to the application being managed. NDB Operator makes it possible to deploy, manage, and makes changes to an NDB Cluster with a minimum of human intervention.
To represent an NDB Cluster, we define an
Custom Resource Definition (CRD) in the Kubernetes cluster. A custom
object of kind Ndb can now be created in the Kubernetes cluster,
representing the configuration of a desired NDB Cluster setup to be
deployed. NDB Operator watches for any changes to such custom
objects and, based on the changes to this object, deploys and
maintains the NDB Cluster nodes in the Kubernetes cluster.
NDB Operator runs a reconciliation loop at regular intervals
whenever there is a change to an
resource, as shown in the following diagram:
Each time through the loop, the operator compares the desired state (the values from the custom resource in the Kubernetes cluster) with the current state (the actual state of the MySQL Cluster installation in the Kubernetes cluster). If the current and desired states do not match, the operator makes incremental changes to the MySQL Cluster installation to move it closer to the desired state; this is repeated if and as necessary over multiple iterations until the MySQL Cluster has the desired state. In this fashion, NDB Operator is able to monitor the NDB Cluster and to ensure that it is running as expected.
NDB Operator architecture: