This is MySQL NDB Operator 8.2.0-1.2.0, an Innovation release of NDB Operator, a Kubernetes Operator for MySQL NDB Cluster.
For more information on MySQL NDB Operator see the online documentation at https://dev.mysql.com/doc/ndb-operator/en/.
For more information about MySQL NDB Cluster, see https://dev.mysql.com/doc/refman/8.2/en/mysql-cluster.html.
NDB Operator now supports NDB Cluster transparent data encryption (TDE). This work includes the following changes:
Added a new
NdbClusterSpec, allowing the user to specify the name of a secret holding the required encryption key or password. If a value is provided for this field, NDB Operator enables TDE and uses the password stored in the secret as the file system password for all data nodes in the cluster. (If no such value is provided, TDE is not enabled.)
EncryptedFileSystemis now updated in the cluster
config.inifile when TDE is enabled.
NDB Operator now compares the TDE state of the current cluster configuration with that of a new incoming
NdbClusterSpec, to ensure that
config.inigeneration includes TDE configuration information and that approproiate rolling restarts are performed by any cluster nodes affected by a configuration change.
This fix addresses the following issues:
check_version()shell script function, responsible for checking the MySQL Cluster version and whether it meets the minimum required, contained errors.
The Java SDK included in the Docker file
mysql-cluster-builder:ol8was updated to version 17.
NDB Operator 8.2.0 requires Java 17 or later.
NDB Operator did not detect initiation script failures, causing it to start the mysqld container even when there were errors in the
In a multi-node Kubernetes environment, an issue arose when the user opted to use an image secret to retrieve the NDB Operator image while deploying it, leading to a situation where one or more pods encounter failures due to image pull failures. This problem emerged because all NDB Cluster pods spawned by NDB Operator include an initialization container that necessitates the presence of the
The root of the issue was that the necessary image pull secret was not included in the pod specifications. Consequently, when a pod was instantiated on any node other than the one where NDB Operator was deployed, it lacked the essential image pull secret, which meant that, since the required image could not be fetched from the repository, pod initialization could not take place.