NDB Operator relies on a custom resource definition (CRD) named
NdbCluster to obtain the MySQL Cluster
configuration data that it needs to start. Whenever a user
creates, modifies, or deletes a Kubernetes object of type
NdbCluster, NDB Operator receives a change
event, and updates the NDB Cluster running in Kubernetes Cluster
accordingly. (See Chapter 1, Introduction to NDB Operator, for a
description of this mechanism.)
The NdbCluster CRD defines a Kubernetes
resource type which can be used to specify the configuration of an
NDB Cluster. See Section 5.1, “NdbCluster Resource”, for more
information.
The docs/examples directory in the NDB
Operator source tree contains several examples, including
example-ndb.yaml. This file contains an
NdbCluster specification having the
characteristics shown here, specified using YAML format:
apiVersion: mysql.oracle.com/v1
kind: NdbCluster
metadata:
name: example-ndb
spec:
redundancyLevel: 2
dataNode:
nodeCount: 2
mysqlNode:
nodeCount: 2
spec.dataNode.nodeCount sets the number of data
nodes.
spec.redundancyLevel specifies the number of
replicas as well as the number of management nodes
(ndb_mgmd processes). Since this is greater
than 1, the NDB Cluster is created with two management nodes.
The number of management nodes is not directly configurable; it
is determined solely by the value of
redundancyLevel.
spec.dataNode.nodeCount determines the number
of data nodes in the NDB Cluster.
spec.mysqld.nodeCount determines the number of
MySQL Servers attached to the NDB Cluster as SQL nodes, providing
an SQL front end to the NDB Cluster data nodes.