MySQL and Kubernetes share terminology. For example, a Node might be a Kubernetes Node or a MySQL Node, a Cluster might be a MySQL InnoDB Cluster or Kubernetes Cluster, and a ReplicaSet is a feature in both MySQL and Kubernetes. This documentation prefers the long names but these overloaded terms may still lead to confusion; context is important.
Kubernetes
The Kubernetes system uses Controllers to manage the life-cycle of containerized workloads by running them as Pods in the Kubernetes system. Controllers are general-purpose tools that provide capabilities for a broad range of services, but complex services require additional components and this includes operators. An Operator is software running inside the Kubernetes cluster, and the operator interacts with the Kubernetes API to observe resources and services to assist Kubernetes with the life-cycle management.
MySQL Operator for Kubernetes
The MySQL Operator for Kubernetes is an operator focused on managing one or more MySQL InnoDB Clusters consisting of a group of MySQL Servers and MySQL Routers. The MySQL Operator itself runs in a Kubernetes cluster and is controlled by a Kubernetes Deployment to ensure that the MySQL Operator remains available and running.
The MySQL Operator is deployed in the 'mysql-operator' Kubernetes namespace by default; and watches all InnoDB Clusters and related resources in the Kubernetes cluster. To perform these tasks, the operator subscribes to the Kubernetes API server to update events and connects to the managed MySQL Server instance as needed. On top of the Kubernetes controllers, the operator configures the MySQL servers, replication using MySQL Group Replication, and MySQL Router.
MySQL InnoDB Cluster
Once an InnoDB Cluster (InnoDBCluster) resource is deployed to the Kubernetes API Server, MySQL Operator for Kubernetes creates resources including:
-
A Kubernetes StatefulSet for the MySQL Server instances.
This manages the Pods and assigns the corresponding storage Volume. Each Pod managed by this StatefulSet runs multiple containers. Several provide a sequence of initialisation steps for preparing the MySQL Server configuration and data directory, and then two containers remain active for operational mode. One of those containers (named 'mysql') runs the MySQL Server itself, and the other (named 'sidecar') is a Kubernetes sidecar responsible for local management of the node in coordination with the operator itself.
-
A Kubernetes Deployment for the MySQL Routers.
MySQL Routers are stateless services routing the application to the current Primary or a Replica, depending on the application's choice. The operator can scale the number of routers up or down as required by the Cluster's workload.
A MySQL InnoDB Cluster deployment creates these Kubernetes Services:
-
One service is the name of the InnoDB Cluster. It serves as primary entry point for an application and sends incoming connections to the MySQL Router. They provide stable name in the form '{clustername}.svc.cluster.local' and expose specific ports.
See also Section 3.4, “MySQL InnoDB Cluster Service Explanation” and Chapter 5, Connecting to MySQL InnoDB Cluster.
A second service named '{clustername}-instances' provides stable names to the individual servers. Typically these should not be directly used; instead use the main service to reliably reach the current primary or secondary as needed. However, for maintenance or monitoring purposes, direct access to an instance might be needed. Each pod instance has MySQL Shell installed.
MySQL Operator for Kubernetes creates and manages additional resources that should not be manually modified, including:
-
A Kubernetes ConfigMap named '{clustername}-initconf' that contains configuration information for the MySQL Servers.
To modify the generated
my.cnf
configuration file, see Section 3.3, “Manifest Changes for InnoDBCluster”. -
A sequence of Kubernetes Secrets with credentials for different parts of the system; names include '{clustername}.backup', '{clustername.privsecrets}', and '{clustername.router}'.
For a list of MySQL accounts (and associated Secrets) created by the operator, see Section 3.5, “MySQL Accounts Created by InnoDBCluster Deployment”.