NDB Operator 8.0 Manual  /  Introduction to NDB Operator

Chapter 1 Introduction to NDB Operator

MySQL NDB Cluster, the distributed version of MySQL, is implemented as a collection of processes or nodes of the following three types:

  • Management nodes (ndb_mgmd): Provision of configuration data

  • Data nodes (ndbmtd): User data storage

  • SQL nodes (mysqld): SQL frontend to the data nodes.

NDB Operator provides services that allow for connections of the following two types:

  • Connections to NDB Cluster management nodes by applications which use the MGM API such as ndb_mgm and ndb_config.

  • Connections to NDB Cluster SQL nodes by MySQL client applications such as mysql.

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.

See NDB Cluster Core Concepts, for more information about NDB Cluster node processes. See also NDB Cluster Programs.

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 Ndb 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 Ndb custom resource, as shown in the following diagram:

Figure 1.1 NDB Operator reconciliation loop

Reconciliation loop in which NDB Operator monitors an NDB Cluster running in a Kubernetes cluster

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:

Figure 1.2 NDB Operator architecture

NDB Operator running an NDB Cluster in a Kubernetes cluster: Architecture