怎么基于k8s 进行开发高可靠服务，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：做网站、成都网站制作、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的云阳网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

MySQL on k8s

应用的设计和开发不能脱离业务需求，对 MySQL 应用的需求如下：

1. 数据高可靠

2. 服务高可用

3. 易使用

4. 易运维

为了实现上述需求，需要依靠 k8s 和应用两方面协同工作，即开发基于 k8s 高可靠应用，既需要 k8s 相关的知识，也需要应用领域内的知识。

下述将根据上述需求来分析相应的解决方案。

1.数据高可靠

数据的高可靠一般依赖于这几方面： • 冗余 • 备份/恢复

我们使用 Percona XtraDB Cluster 作为 MySQL 集群方案，它是 multi-master 的 MySQL 架构，实例间基于 Galera Replication 技术实现数据的实时同步。这种集群方案可以避免 master-slave 架构的集群在主从切换时可能出现的数据丢失现象，进一步提升数据的可靠性。

备份方面，我们使用 xtrabackup 作为备份/恢复方案，实现数据的热备份，在备份期间不影响用户对集群的正常访问。

提供「定时备份」的同时，我们也提供「手动备份」，以满足业务对备份数据的需求。

2.服务高可用

这里从「数据链路」和「控制链路」两个角度来分析。

「数据链路」是用户访问 MySQL 服务的链路，我们使用 3 主节点的 MySQL 集群方案，通过 TLB (七牛自研的四层负载均衡服务) 对用户提供访问入口。TLB 既实现了访问层面对 MySQL 实例的负载均衡，又实现了对服务的健康检测，自动摘除异常的节点，同时在节点恢复时自动加入该节点。如下图：

基于上述 MySQL 集群方案和 TLB，一个或两个节点的异常不会影响用户对 MySQL 集群的正常访问，确保 MySQL 服务的高可用。

「控制链路」是 MySQL 集群的管理链路，分为两个层面： • 全局控制管理 • 每个 MySQL 集群的控制管理 全局控制管理主要负责「创建/删除集群」「管理所有 MySQL 集群状态」等，基于 Operator 的理念来实现。每个 MySQL 集群有一个控制器，负责该集群的「任务调度」「健康检测」「故障自动处理」等。

这种拆解将每个集群的管理工作下放到每个集群中，降低了集群间控制链路的相互干扰，同时又减轻了全局控制器的压力。 如下图：

这里简单介绍下 Operator 的理念和实现。

Operator 是 CoreOS 公司提出的一个概念，用来创建、配置、管理复杂应用，由两部分构成：   Resource • 自定义资源 • 为用户提供一种简单的方式描述对服务的期望  Controller • 创建 Resource • 监听 Resource 的变更，用来实现用户对服务的期望

工作流程如下图所示：

即：

1. 注册 CR (CustomResource) 资源

2. 监听 CR objects 的变更

3. 用户对该 CR 资源进行 CREATE/UPDATE/DELETE 操作

4. 触发相应的 handler 进行处理

我们根据实践，对开发 Operator 做了如下抽象：

CR抽象为这样的结构体：

对 CR ADD/UPDATE/DELETE events 的操作，抽象为如下接口：

在上述抽象的基础上，七牛提供了一个简单的 Operator 框架，透明化了创建 CR、监听 CR events 等的操作，将开发 Operator 的工作变的更为简单。

我们开发了 MySQL Operator 和 MySQL Data Operator，分别用来负责「创建/删除集群」和「手动备份/恢复」工作。

由于每个 MySQL 集群会有多种类型的任务逻辑，如「数据备份」「数据恢复」「健康检测」「故障自动处理」等，这些逻辑的并发执行可能会引发异常，故需要任务调度器来协调任务的执行，Controller 起到的就是这方面的作用： 

通过 Controller 和各类 Worker，每个 MySQL 集群实现了自运维。

在「健康检测」方面，我们实现了两种机制： • 被动检测 • 主动检测 「被动检测」是每个 MySQL 实例向 Controller 汇报健康状态，「主动检测」是由 Controller 请求每个 MySQL 实例的健康状态。这两种机制相互补充，提升健康检测的可靠度和及时性。

对于健康检测的数据，Controller 和 Operator 均会使用，如下图所示： 

Controller 使用健康检测数据是为了及时发现 MySQL 集群的异常，并做相应的故障处理，故需要准确、及时的健康状态信息。它在内存中维护所有 MySQL 实例的状态，根据「主动检测」和「被动检测」的结果更新实例状态并做相应的处理。

Operator 使用健康检测数据是为了向外界反映 MySQL 集群的运行情况，并在 Controller 异常时介入到 MySQL 集群的故障处理中。

在实践中，由于健康检测的频率相对较高，会产生大量的健康状态，若每个健康状态都被持久化，那么 Operator 和 APIServer 均会承受巨大的访问压力。由于这些健康状态仅最新的数据有意义，故在 Controller 层面将待向 Operator 汇报的健康状态插入到一个有限容量的 Queue 中，当 Queue 满时，旧的健康状态将被丢弃。

当 Controller 检测到 MySQL 集群异常时，将会进行故障自动处理。

先定义故障处理原则： • 不丢数据 • 尽可能不影响可用性 • 对于已知的、能够处理的故障进行自动处理 • 对于未知的、不能够处理的故障不自动处理，人工介入 在故障处理中，有这些关键问题： • 故障类型有哪些 • 如何及时检测和感知故障 • 当前是否出现了故障 • 出现的故障是哪种故障类型 • 如何进行处理 针对上述关键问题，我们定义了 3 种级别的集群状态：

Green • 可以对外服务 • 运行节点数量符合预期 Yellow • 可以对外服务 • 运行节点数量不符合预期 Red • 不能对外服务

同时针对每个 mysqld 节点，定义了如下状态：

Green • 节点在运行 • 节点在 MySQL 集群中 Yellow • 节点在运行 • 节点不在 MySQL 集群中 Red-clean • 节点优雅退出 Red-unclean • 节点非优雅退出 Unknown • 节点状态不可知

Controller 收集到所有 MySQL 节点状态后，会根据这些节点的状态推算 MySQL 集群的状态。当检测到 MySQL 集群状态不是 Green 时，会触发「故障处理」逻辑，该逻辑会根据已知的故障处理方案进行处理。若该故障类型未知，人工介入处理。整个流程如下图：

由于每种应用的故障场景和处理方案不同，这里不再叙述具体的处理方法。

3.易使用

我们基于 Operator 的理念实现了高可靠的 MySQL 服务，为用户定义了两类资源，即 QiniuMySQL 和 QiniuMySQLData。前者描述用户对 MySQL 集群的配置，后者描述手动备份/恢复数据的任务，这里以 QiniuMySQL 为例。

用户可通过如下简单的 yaml 文件触发创建 MySQL 集群的操作：

在集群创建好后，用户可通过该 CR object 的 status 字段获取集群状态：

这里再引入一个概念：Helm。

Helm 是为 k8s 提供的包管理工具，通过将应用打包为 Chart，标准化了 k8s 应用的交付、部署和使用流程。

Chart 本质上是 k8s yaml 文件和参数文件的集合，这样可以通过一个 Chart 文件进行应用的交付。Helm 通过操作 Chart，可一键部署、升级应用。

由于篇幅原因及 Helm 操作的通用性，这里不再描述具体的使用过程。

4.易运维

除了上述实现的「健康检测」「故障自动处理」以及通过 Helm 管理应用的交付、部署，在运维过程中还有如下问题需要考虑： • 监控/告警 • 日志管理

我们通过 prometheus + grafana 做监控/告警服务，服务将 metric 数据以 HTTP API 暴露给 prometheus，由 prometheus server 定时拉取。开发人员在 grafana 上将 prometheus 中的监控数据可视化，根据对监控图表和应用的把握，在监控图中设置告警线，由 grafana 实现告警。

这种先可视化监控后告警的方式，极大程度上增强了我们对应用运行特征的把握，明确需要关注的指标和告警线，降低无效告警的产生量。

在开发中，我们通过 gRPC 实现服务间的通信。在 gRPC 生态系统中，有个名为 go-grpc-prometheus 的开源项目，通过在服务中插入几行简单的代码，就可以实现对 gRPC server 所有 rpc 请求的监控打点。

对于容器化服务，日志管理包括「日志收集」和「日志滚动」两方面维度。

我们将服务日志打到 syslog 中，再通过某种手段将 syslog 日志转入到容器的 stdout/stderr 中，方便外部采用常规的方式进行日志收集。同时，在 syslog 中配置了 logrotate 功能，自动进行日志的滚动操作，避免日志占满容器磁盘空间引发服务异常。

为了提升开发效率，我们使用 https://github.com/phusion/baseimage-docker 作为基础镜像，其中内置了 syslog 和 lograte 服务，应用只关心把日志打入 syslog 即可，不用关心日志的收集和日志滚动问题。

小结

通过上述描述，完整的 MySQL 应用架构如下：

在开发基于 k8s 的高可靠 MySQL 应用过程中，随着对 k8s 和 MySQL 理解的深入，我们不断进行抽象，逐步将如下通用的逻辑和最佳实践以模块的方式实现： • Operator 开发框架 • 健康检测服务 • 故障自动处理服务 • 任务调度服务 • 配置管理服务 • 监控服务 • 日志服务 • etc.

随着这些通用逻辑和最佳实践的模块化，在开发新的基于 k8s 的高可靠应用时，开发者可像「搭积木」一样将与 k8s 相关的交互快速搭建起来，这样的应用由于已经运用了最佳实践，从一开始就具备高可靠的特性。同时，开发者可将注意力从 k8s 陡峭的学习曲线转移到应用自身领域，从应用自身加强服务的可靠性。

关于怎么基于k8s 进行开发高可靠服务问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。

名称栏目：怎么基于k8s进行开发高可靠服务
链接地址：http://pwwzsj.com/article/iphjds.html