MySQL 和 Kubernetes 共享术语。例如，一个节点可能是一个 Kubernetes 节点或一个 MySQL 节点，一个集群可能是一个 MySQL InnoDB 集群或 Kubernetes 集群，而 ReplicaSet 是 MySQL 和 Kubernetes 中的一个特性。本文档更喜欢长名称，但这些重载的术语仍可能导致混淆；上下文很重要。
库伯内斯
Kubernetes 系统使用 控制器 来管理容器化工作负载的生命周期，方法是将它们作为 Kubernetes 系统中的 Pod 运行。控制器是通用工具，可为广泛的服务提供功能，但复杂的服务需要额外的组件，这包括操作员。Operator是运行在 Kubernetes 集群内部的软件， Operator 与 Kubernetes API 交互，观察资源和服务，协助 Kubernetes 进行生命周期管理。
Kubernetes 的 MySQL 运算符
MySQL Operator for Kubernetes 是一个专注于管理一个或多个 由一组 MySQL 服务器和 MySQL 路由器组成的MySQL InnoDB 集群的运营商。MySQL Operator 本身在 Kubernetes 集群中运行，并由 Kubernetes Deployment控制，以确保 MySQL Operator 保持可用和运行。
MySQL Operator 默认部署在 ‘mysql-operator’ Kubernetes 命名空间中；并监视 Kubernetes 集群中的所有 InnoDB 集群和相关资源。为了执行这些任务，操作员订阅 Kubernetes API 服务器以更新事件并根据需要连接到托管 MySQL 服务器实例。在 Kubernetes 控制器之上，操作员配置 MySQL 服务器、使用 MySQL Group Replication 的复制和 MySQL Router。
MySQL InnoDB 集群
一旦将 InnoDB Cluster (InnoDBCluster) 资源部署到 Kubernetes API 服务器，MySQL Operator for Kubernetes 创建的资源包括：
-
MySQL 服务器实例的 Kubernetes StatefulSet。
这管理 Pod 并分配相应的存储卷。这个 StatefulSet 管理的每个 Pod 运行多个容器。几个提供了一系列用于准备 MySQL 服务器配置和数据目录的初始化步骤，然后两个容器在操作模式下保持活动状态。其中一个容器（名为“mysql”）运行 MySQL 服务器本身，另一个容器（名为“sidecar”）是一个 Kubernetes sidecar，负责与操作员本身协调节点的本地管理。
-
MySQL 路由器的 Kubernetes 部署。
MySQL Routers 是无状态服务，根据应用程序的选择将应用程序路由到当前主节点或副本节点。运营商可以根据集群工作负载的需要增加或减少路由器的数量。
MySQL InnoDB 集群部署创建这些 Kubernetes 服务：
-
一项服务是 InnoDB 集群的名称。它充当应用程序的主要入口点，并将传入连接发送到 MySQL 路由器。它们以“{clustername}.svc.cluster.local”的形式提供稳定名称并公开特定端口。
另见 第 3.4 节，“MySQL InnoDB 集群服务说明”和 第 4 章，连接到 MySQL InnoDB 集群。
名为“{clustername}-instances”的第二个服务为各个服务器提供稳定的名称。通常不应直接使用这些；而是使用主要服务根据需要可靠地到达当前的主要或次要服务。但是，出于维护或监控目的，可能需要直接访问实例。每个 pod 实例都安装了 MySQL Shell。
MySQL Operator for Kubernetes 创建和管理不应手动修改的其他资源，包括：
-
名为“{clustername}-initconf”的 Kubernetes ConfigMap，其中包含 MySQL 服务器的配置信息。
要修改生成的
my.cnf配置文件，请参阅 第 3.3 节，“InnoDBCluster 的清单更改”。 -
一系列 Kubernetes Secret，其中包含系统不同部分的凭据；名称包括“{clustername}.backup”、“{clustername.privsecrets}”和“{clustername.router}”。
有关操作员创建的 MySQL 帐户（和相关机密）的列表，请参阅 第 3.5 节，“InnoDBCluster 部署创建的 MySQL 帐户”。
