Changes in NDB Operator 8.1.0-1.1.0 (2023-07-26, Innovation Release)

This is MySQL NDB Operator 8.1.0-1.1.0, an Innovation release of NDB Operator, a Kubernetes Operator for MySQL NDB Cluster.

For additional downloads and the source of MySQL NDB Operator visit https://dev.mysql.com/downloads/ndb-operator/ and https://github.com/mysql/mysql-ndb-operator.

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.1/en/mysql-cluster.html.

Bugs Fixed

• The NDB Operator initialization script contains multiple SQL statements and is executed as an init container in the mysqld pod. An issue in MySQL Server 8.1.0 meant that, when a space was present before the leading # character in a comment preceding a delimiter command included in the script (see mysql Client Commands), the command was skipped. This led to discrepancies when executing later statements, preventing the mysqld pod from starting up successfully. (Bug #35619717)

• NDB Operator utilizes Kubernetes validatingwebhookconfiguration and mutatingwebhookconfiguration objects to validate CRD requests before forwarding them to the Kubernetes API server. These webhook configurations generate an HTTP message and send it to a separate pod running an HTTP server alongside the ndb-operator pod. The responsibility of the HTTP server is to validate the user-specified specifications and provide an appropriate response to the webhook configurations. The Kubernetes webhook configurations object determines whether to accept or to reject the user's CRD request based on the response.

  To establish secure communication, the HTTP server requires a valid certificate, which makes it essential for both the HTTP server and webhook configurations to have valid certificates before initiating communication. During startup, the HTTP server generates a certificate and key, and then updates all the webhook configurations by adding this certificate to them. Subsequently, when creating the HTTP request, the webhook configurations use these certificates, and these same certificates are employed on the server side for validation.

  When installing NDB Operator using the Operator Package Manager (OPM), the ownership of the webhook configurations resided with the CSV (ClusterServiceVersion). As a result, any modifications made to the webhook configurations were not reflected since the CSV has control over the Kubernetes objects created by it. Consequently, the authentication step failed for the HTTP requests sent by the webhook configurations.

  Since OPM already possesses a Certificate Authority (CA) and creates certificates for all components, we resolve this issue by making sure that the server detects the installation mode, and if the mode is OPM, that it makes use of the certificates given by the CA rather than creating its own. (Bug #35408957)