使用Kubernetes进行ProxySQL本机群集

标签：schema   script   apply   要求   ports   pattern   过程   test   api   

自v1.4.2起，ProxySQL支持本机群集。这意味着多个ProxySQL实例可识别群集; 他们了解彼此的状态，并能够通过根据配置版本，时间戳和校验和值同步最新的配置来自动处理配置更改。

ProxySQL是一个分散的代理，建议更靠近应用程序部署。这种方法甚至可以扩展到数百个节点，因为它可以在运行时轻松重新配置。为了有效地管理多个ProxySQL节点，必须确保在其中一个节点上执行的任何更改都应该应用于服务器场中的所有节点。如果没有本机群集，则必须手动导出配置并将其导入其他节点（尽管您可以自行进行自动化）。

使用ConfigMap中的集中配置方法，这种方法或多或少非常有效。无论加载到ConfigMap中的是什么都将被安装到pod中。更新配置可以通过版本控制（修改proxysql.cnf内容并将其加载到另一个名称的ConfigMap），然后根据部署方法调度和更新策略推送到pod。

但是，在快速变化的环境中，这种ConfigMap方法可能不是最好的方法，因为为了加载新配置，需要重新安排pod重新安排ConfigMap卷，这可能会危及整个ProxySQL服务。例如，假设在我们的环境中，我们的严格密码策略要求每7天强制MySQL用户密码过期，我们必须每周更新ProxySQL ConfigMap以获取新密码。另外，ProxySQL中的MySQL用户需要用户和密码才能匹配后端MySQL服务器上的用户和密码。这就是我们应该开始在Kubernetes中使用ProxySQL本机群集支持的地方，自动应用配置更改，而无需ConfigMap版本控制和pod重新安排的麻烦。

在这篇博文中，我将向您展示如何在Kubernetes上运行具有无头服务的ProxySQL本机群集。我们的高级架构可以说明如下：

我们在ClusterControl部署和管理的裸机基础设施上运行了3个Galera节点：

• 192.168.0.21
• 192.168.0.22
• 192.168.0.23

我们的应用程序都在Kubernetes中作为pod运行。我们的想法是在应用程序和数据库集群之间引入两个ProxySQL实例作为反向代理。然后，应用程序将通过Kubernetes服务连接到ProxySQL pod，这将在多个ProxySQL副本之间进行负载平衡和故障转移。

以下是我们的Kubernetes设置的摘要：

通过ConfigMap进行ProxySQL配置

让我们首先准备我们的基本配置，它将被加载到ConfigMap中。创建一个名为proxysql.cnf的文件并添加以下行：

以下部分解释了上面的一些配置行：

admin_variables

注意admin_credentials变量，我们使用非默认用户“proxysql-admin”。ProxySQL仅通过localhost为本地连接保留默认的“admin”用户。因此，我们必须使用其他用户远程访问ProxySQL实例。否则，您将收到以下错误：

我们还在admin_credentials行中附加了cluster_username和cluster_password值，以分号分隔以允许自动同步发生。所有以cluster_ *为前缀的变量都与ProxySQL本机群集相关，并且不言自明。

mysql_galera_hostgroups

这是为ProxySQL 2.x引入的新指令（我们的ProxySQL映像在2.0.5上运行）。如果您想在ProxySQL 1.x上运行，请删除此部分并改为使用调度程序表。我们已经在这篇博文中解释了配置细节，如何在Docker上运行和配置针对MySQL Galera Cluster的ProxySQL 2.0“对Galera集群的 ProxySQL 2.x支持”。

mysql_servers

所有行都是不言自明的，它基于在MySQL Galera Cluster中运行的三个数据库服务器，如以下从ClusterControl获取的拓扑截图中所概述：

proxysql_servers

这里我们定义一个ProxySQL对等列表：

• hostname - 对等方的主机名/ IP地址
• port - Peer的管理端口
• 重量 - 目前未使用，但在未来增强的路线图中
• 评论 - 免费表单评论字段

在Docker / Kubernetes环境中，有多种方法可以发现和链接容器主机名或IP地址，并将它们插入到此表中，方法是使用ConfigMap，手动插入，通过entrypoint.sh脚本，环境变量或其他方法。在Kubernetes中，根据所使用的ReplicationController或Deployment方法，在高级中猜测pod的可解析主机名有点棘手，除非您在StatefulSet上运行。

查看有关StatefulState pod序数索引的本教程，该索引为创建的pod提供稳定的可解析主机名。将此与无头服务相结合（进一步解释），可解析的主机名格式为：

{APP_NAME} - {index_number} {}服务。

其中{service}是无头服务，它解释了“proxysql-0.proxysqlcluster”和“proxysql-1.proxysqlcluster”的来源。如果要包含2个以上的副本，请通过附加相对于StatefulSet应用程序名称的升序索引号来相应地添加更多条目。

现在我们准备将配置文件推送到ConfigMap，它将在部署期间安装到每个ProxySQL pod中：

验证我们的ConfigMap是否正确加载：

创建ProxySQL监控用户

开始部署之前的下一步是在数据库集群中创建ProxySQL监控用户。由于我们在Galera集群上运行，因此在其中一个Galera节点上运行以下语句：

如果您还没有创建MySQL用户（如上面mysql_users部分所述），我们也必须创建它们：

而已。我们现在准备开始部署。

部署StatefulSet

我们将首先使用StatefulSet为冗余目的创建两个ProxySQL实例或副本。

让我们首先创建一个名为proxysql-ss-svc.yml的文本文件，并添加以下行：

上面定义有两个部分 - StatefulSet和Service。StatefulSet是从proxysql-configmap加载的pods或副本以及ConfigMap卷的挂载点的定义。下一节是服务定义，我们在其中定义如何为内部或外部网络公开和路由pod。

验证pod和服务状态：

如果你看一下pod的日志，你会发现我们被这个警告淹没了：

以上只是意味着proxysql-0无法解析“proxysql-1.proxysqlcluster”并连接到它，这是预料之中的，因为我们还没有为代理SQL间通信所需的DNS记录创建无头服务。

Kubernetes无头服务

为了使ProxySQL pod能够解析预期的FQDN并直接连接到它，解析过程必须能够查找分配的目标pod IP地址而不是虚拟IP地址。这是无头服务进入画面的地方。通过设置“ clusterIP = None ” 创建无头服务时，不会配置负载平衡，也不会为此服务分配集群IP（虚拟IP）。仅自动配置DNS。当您为无头服务运行DNS查询时，您将获得pod IP地址的列表。

如果我们查找“proxysqlcluster”的无头服务DNS记录（在此示例中我们有3个ProxySQL实例），这就是它的样子：

同时，以下输出显示名为“proxysql”的标准服务的DNS记录，该记录解析为clusterIP：

要创建无头服务并将其附加到pod，必须在StatefulSet声明中定义ServiceName，并且Service定义必须具有“ clusterIP = None ”，如下所示。创建一个名为proxysql-headless-svc.yml的文本文件，并添加以下行：

创建无头服务：

仅用于验证，此时，我们运行以下服务：

现在，查看我们的pod日志之一：

您会注意到Cluster组件能够通过名为“proxysqlcluster”的无头服务从端口6032上的其他对等端proxysql-1.proxysqlcluster解析，连接和检测新的校验和。请注意，此服务仅在Kubernetes网络中公开端口6032，因此无法从外部访问。

此时，我们的部署现已完成。

连接到ProxySQL

有几种方法可以连接到ProxySQL服务。负载均衡的MySQL连接应从Kubernetes网络内发送到端口6033，如果客户端从外部网络连接，则使用端口30033。

要从外部网络连接到ProxySQL管理界面，我们可以连接到NodePort部分30032下定义的端口（192.168.100.203是主机kube3.local的主IP地址）：

如果要从Kubernetes网络中的其他pod访问，请在端口6032上使用clusterIP 10.110.38.154（在“proxysql”服务下定义）。

然后根据需要执行ProxySQL配置更改并将其加载到运行时：

您将注意到其中一个窗格中的以下行指示配置同步完成：

请记住，只有在ProxySQL运行时中发生配置更改时才会发生自动同步。因此，在看到动作之前运行“ LOAD ... TO RUNTIME ”语句至关重要。不要忘记将ProxySQL更改保存到磁盘中以保持持久性：

局限性

请注意，此设置存在限制，因为ProxySQL不支持将活动配置保存/导出到文本配置文件中，以后我们可以将其加载到ConfigMap中以保持持久性。有一个功能要求。同时，您可以手动将修改推送到ConfigMap。否则，如果意外删除了pod，则会丢失当前配置，因为新的pod将由ConfigMap中定义的任何内容引导。

特别感谢Sampath Kamineni，他引发了这篇博客文章的想法，并提供了有关用例和实现的见解。

欢迎关注公众号：“Java架构师学习”

你会喜欢的！

使用Kubernetes进行ProxySQL本机群集

标签：schema   script   apply   要求   ports   pattern   过程   test   api   

原文地址：https://www.cnblogs.com/xueSpring/p/11557841.html