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.