小xs1. 项目概述
在云原生架构逐渐成为主流的今天，如何将传统中间件服务平滑迁移到Kubernetes平台，同时保证生产级的高可用性，是每个DevOps团队都会面临的挑战。我最近刚完成一个金融项目的中间件容器化改造，其中MySQL、Kafka和Redis的高可用部署方案经过多次压力测试和线上验证，形成了这套可复用的部署模式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心需求解析
2.1 为什么选择这三大中间件
MySQL作为关系型数据库的代表，Kafka作为消息队列的事实标准，Redis作为缓存和高速数据处理的利器，这三者构成了现代分布式系统的"铁三角"。将它们部署在K8s上需要解决几个关键问题：
- 数据持久化与一致性保障
- 集群节点间的自动发现与通信
- 故障转移时的数据零丢失
- 资源隔离与弹性扩缩容
2.2 高可用部署的四个维度
我们定义的高可用方案需要满足：
- 服务可用性：99.99%的SLA要求
- 数据可靠性：RPO（恢复点目标）<=1秒
- 故障恢复：RTO（恢复时间目标）<30秒
- 横向扩展：支持分钟级集群扩容
3. MySQL高可用部署方案
3.1 架构设计
采用Group Replication模式而非传统主从复制，实现多主写入。拓扑结构如下：
- 3个Pod构成复制组
- 每个Pod挂载独立的PVC（RWO模式）
- 通过Headless Service暴露
- 使用MySQL Router实现读写分离
yaml复制# StatefulSet关键配置示例
volumeClaimTemplates:
- metadata:
name: mysql-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 100Gi
3.2 关键配置参数
在my.cnf中必须配置：
ini复制[mysqld]
server_id=#{HOSTNAME##*-} # 利用StatefulSet序号
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_group_commit_sync_delay=100
binlog_group_commit_sync_no_delay_count=10
3.3 运维注意事项
- 备份策略：每天全量备份+binlog实时同步到S3
- 监控指标：重点关注group_replication_member_status
- 升级流程：采用滚动更新，确保至少2个节点在线
重要提示：Group Replication对网络延迟敏感，建议部署在同一个可用区
4. Kafka高可用部署方案
4.1 集群拓扑设计
采用KRaft模式（去Zookeeper依赖）部署3节点集群：
- 每个Broker独占Worker节点
- 配置ephemeral存储类实现自动扩容
- 通过NodePort对外暴露9092端口
bash复制# Kafka启动参数关键配置
KAFKA_CFG_PROCESS_ROLES=broker,controller
KAFKA_CFG_NODE_ID=${HOSTNAME##*-}
KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafka-0:9093,2@kafka-1:9093,3@kafka-2:9093
4.2 性能调优要点
- 日志段设置：log.segment.bytes=1GB（减少分段数）
- 刷盘策略：flush.messages=10000（平衡性能与可靠性）
- 副本策略：min.insync.replicas=2（允许1个副本失效）
4.3 监控与运维
建议监控这些关键指标：
| 指标名称 | 告警阈值 | 说明 |
|---|---|---|
| UnderReplicatedPartitions | >0持续5分钟 | 副本同步异常 |
| RequestQueueTimeMs | P99>1000ms | 处理能力不足 |
| ActiveControllerCount | !=1 | 控制器异常 |
5. Redis高可用部署方案
5.1 集群模式选择
采用Redis Cluster而非哨兵模式，部署方案：
- 6个Pod（3主3从）
- 使用Local PV实现低延迟访问
- 配置Cluster IP对外服务
yaml复制# 初始化集群命令
redis-cli --cluster create \
$(kubectl get pods -l app=redis -o jsonpath='{range.items[*]}{.status.podIP}:6379 ')
5.2 关键参数配置
redis.conf核心配置：
conf复制cluster-enabled yes
cluster-node-timeout 5000
cluster-migration-barrier 1
appendonly yes
aof-rewrite-incremental-fsync yes
5.3 性能优化技巧
- 内存管理：设置maxmemory为物理内存的70%
- 连接池：建议HikariCP配置最小10最大100连接
- 热点Key：使用CLUSTER HOTSPOT命令定期分析
6. 统一运维管理方案
6.1 监控体系搭建
采用Prometheus Operator采集三类指标：
- MySQL：通过mysqld_exporter
- Kafka：使用kafka_exporter
- Redis：配置redis_exporter
Grafana监控看板关键指标：
- MySQL：QPS、慢查询、连接数
- Kafka：消息堆积、消费延迟
- Redis：内存使用、命中率
6.2 日志收集方案
Fluentd配置示例：
xml复制<source>
@type tail
path /var/log/mysql/mysql.log
pos_file /var/log/fluentd/mysql.log.pos
tag mysql
</source>
6.3 灾备演练流程
- 随机kill一个Pod观察自动恢复
- 模拟网络分区测试脑裂处理
- 压测期间执行滚动升级
7. 常见问题排查实录
7.1 MySQL集群脑裂处理
现象：多个节点同时认为自己是主节点
解决方法：
- 通过SELECT * FROM performance_schema.replication_group_members确认状态
- 强制指定有效主节点：SET GLOBAL group_replication_force_members="ip:port"
7.2 Kafka消息堆积
典型排查路径：
- 检查消费者lag：kafka-consumer-groups.sh --describe
- 分析分区分布是否均衡
- 检查网络吞吐量：iftop -i eth0
7.3 Redis集群节点失效
恢复步骤：
- 确认故障节点状态：CLUSTER NODES
- 手动故障转移：CLUSTER FAILOVER TAKEOVER
- 新节点加入：CLUSTER MEET
这套方案在我们生产环境支撑了日均10亿级交易请求，关键是在保证高可用的同时，保持了云原生架构的弹性优势。实际部署时建议先在小规模环境验证网络策略和存储性能，特别是跨可用区部署时的延迟问题。