
大家好，我是数据库小学妹 👋

一家互联网公司做容器化改造，找我评估MySQL上K8s的可行性。聊完他们的场景，我给了一句结论："读从库和开发环境可以上，核心交易库先别动。"

他们问为什么。我说：Pod是临时的，数据不能临时。StatefulSet、持久化存储、网络转发延迟，这三个问题不解决，上去了也跑不稳。

为了验证这个结论，我搭了一套完整的测试环境。从StatefulSet选型到持久化存储配置到Operator管理主从复制，再到sysbench压测对比。折腾了两周，得出了一堆数据和3个踩过的坑。
![封面图 (2).png](https://developer.qcloudimg.com/http-save/yehe-12362123/e8d915c0479b42d9491e137fe5906570.png)

今天我把整个过程记录下来。如果你也在考虑把数据库搬上容器平台，这篇能帮你省点时间。

## 为什么要把数据库跑在K8s上？

先说结论：不是为了赶时髦。传统虚拟机部署数据库，扩容要申请资源、装系统、装数据库、配置主从。一套流程下来至少一周。K8s上，一条命令就能拉起新实例。

故障恢复也是。传统方式要手动切主从、改VIP、通知应用。K8s上Operator自动检测、自动拉起、自动重建复制关系。但代价是什么？存储性能损耗。网络复杂度。运维方式完全不同。

不是所有数据库都适合上K8s。核心交易系统我建议先用虚拟机。读从库、开发测试环境、临时数据服务，适合先上容器。

## 为什么选StatefulSet而不是Deployment？

K8s有两种工作负载控制器。Deployment和StatefulSet。跑MySQL必须选StatefulSet。原因很简单。

**Deployment是为无状态应用设计的。** Pod挂了重新拉起，新Pod和旧Pod没有区别。IP地址变了无所谓。数据不存在本地。

**StatefulSet是为有状态应用设计的。** 每个Pod有固定的名字（mysql-0、mysql-1、mysql-2）。Pod重建后名字不变。每个Pod绑定独立的持久化存储。

| 特性 | Deployment | StatefulSet |
|------|-----------|-------------|
| Pod命名 | 随机哈希 | 固定序号 |
| 存储绑定 | 共享PVC | 每Pod独立PVC |
| 启动顺序 | 并行 | 有序（0→1→2） |
| 适用场景 | Web服务、API | 数据库、消息队列 |

如果用Deployment跑MySQL，Pod重启后PVC可能绑到别的Pod上，数据就乱了。StatefulSet保证mysql-0永远用自己的PVC。

## 持久化存储：PVC和StorageClass怎么配？

这是最关键的环节。Pod是临时的，数据必须是持久的。

**第一步，创建StorageClass。** 它告诉K8s用什么方式提供存储。我用的NFS，因为简单。生产环境建议用Ceph RBD或云盘。

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mysql-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain  # Pod删除后数据保留
```

**第二步，StatefulSet里声明PVC模板。** 每个Pod自动创建一个独立的PVC。

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3  # 1主2从
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        - name: MYSQL_REPLICATION_USER
          value: "repl"
        - name: MYSQL_REPLICATION_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: repl-password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
        resources:
          requests:
            memory: "2Gi"
            cpu: "1000m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: mysql-storage
      resources:
        requests:
          storage: 100Gi
```

这里有几个容易踩的坑。

**accessModes必须是ReadWriteOnce。** 一块存储只能被一个Pod挂载。如果用ReadWriteMany，多个Pod可能同时写同一个数据文件，直接损坏。

**reclaimPolicy设成Retain。** Pod删除后PVC保留。如果设成Delete，误删StatefulSet就等于删数据。

**资源限制要设。** 不设置limits，MySQL可能吃光节点内存，触发OOM Killer。

## 主从复制怎么在K8s上搭？

StatefulSet创建了3个Pod。但它们默认是3个独立的MySQL实例。主从复制需要额外配置。有两种方式：手动配置和Operator管理。

**手动配置：** 用ConfigMap注入my.cnf，init-container初始化主从关系。

```yaml
# ConfigMap注入主库配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
data:
  primary.cnf: |
    [mysqld]
    server-id=1
    log-bin=mysql-bin
    gtid-mode=ON
    enforce-gtid-consistency=ON
  replica.cnf: |
    [mysqld]
    server-id=2
    read-only=ON
    gtid-mode=ON
    enforce-gtid-consistency=ON
```

然后用initContainer根据Pod序号加载不同配置。mysql-0加载primary.cnf，mysql-1和mysql-2加载replica.cnf。

这种方式能跑，但运维成本大。主库挂了要手动切。从库重建要手动配。

**Operator管理：** 用现成的MySQL Operator。我试了Percona的PXC Operator和Oracle的MySQL Operator。它们自动处理主从搭建、故障切换、备份恢复。

以Percona Operator为例，部署完Operator后，只需要定义一个自定义资源：

```yaml
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: mysql-cluster
spec:
    pxc:
      size: 3
      image: percona/percona-xtradb-cluster:8.0
    proxysql:
      size: 2
      image: percona/percona-xtradb-cluster-operator:1.14.0-haproxy
```

Operator会自动创建StatefulSet、配置主从（PXC模式）、设置ProxySQL负载均衡。主库挂了自动选举新主。

## 性能损耗：容器到底慢多少？

这是我做之前最关心的问题。跑个测试对比一下。

```bash
# 容器内MySQL的sysbench测试
sysbench oltp_read_write \
  --mysql-host=mysql-0.mysql.default.svc.cluster.local \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=xxx \
  --tables=10 \
  --table-size=100000 \
  run

# 同配置虚拟机MySQL的sysbench测试
sysbench oltp_read_write \
  --mysql-host=192.168.1.100 \
  --mysql-port=3306 \
  ...
```

测试结果：

| 指标 | 虚拟机 | K8s容器 | 差异 |
|------|--------|---------|------|
| TPS | 1250 | 1180 | -5.6% |
| 平均延迟 | 8ms | 8.5ms | +6.3% |
| P99延迟 | 45ms | 52ms | +15.6% |

读写性能差距在5%到15%之间。对大多数业务可以接受。P99延迟差异稍大，主要来自网络层（kube-proxy的iptables转发）。

**网络性能损耗的来源。** K8s的Service通过iptables或IPVS做端口转发。每经过一层转发，增加一点延迟。如果用HostNetwork模式，Pod直接用宿主机网络，性能接近虚拟机。但牺牲了网络隔离性。

**存储性能损耗的深层原因。** 这不只是NFS和SSD的区别。MySQL的InnoDB在做fsync时，期望数据直接落到物理磁盘。但在K8s上，数据要经过容器存储层、CSI驱动、再到存储后端。每多一层，就多一次上下文切换和内存拷贝。我用strace追踪过MySQL的fsync调用，发现容器环境下系统调用链长了3到4层。这就是为什么即使换成Ceph RBD，P99延迟仍然比虚拟机高一点。

**CPU调度的影响。** K8s的CPU limit用的是CFS quota，不是硬隔离。当节点上多个Pod争CPU时，MySQL线程可能被频繁调度切换。我观察过perf的上下文切换计数，容器环境下的voluntary context switch比虚拟机高20%。这对InnoDB的后台线程（page cleaner、log writer）影响尤其明显，因为它们对延迟敏感。

**存储性能损耗的来源。** NFS存储的IO性能远低于本地SSD。生产环境建议用云盘或Ceph RBD。我测试过Ceph RBD，TPS差距缩小到2%以内。

## 避坑清单：部署MySQL上K8s最容易踩哪些坑？

**删除StatefulSet前一定先确认PVC策略。** 默认reclaimPolicy是Delete，我手贱删了一次StatefulSet，PVC跟着删了，测试库数据直接没了。改成Retain至少多一层保护，删之前先确认。生产环境绝对不能留Delete。

**MySQL的内存限制要算清楚。** 没设置resources.limits.memory，MySQL跑着跑着内存飙升，Linux OOM Killer把它杀了，Pod重启，无限循环。limits必须设，而且要比innodb_buffer_pool_size大至少20%。简单算法：buffer_pool +（max_connections × 2MB）。只设buffer_pool不设limits，OOM Killer随时等你。

**Headless Service必须提前创建。** StatefulSet的Pod之间用域名通信，mysql-0.mysql.default.svc.cluster.local。我一开始忘了创建Headless Service，域名解析失败，从库连不上主库。StatefulSet必须配serviceName，对应的Headless Service必须在部署前建好。

```yaml
# Headless Service（必须与StatefulSet的serviceName一致）
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None  # Headless，不分配ClusterIP
  selector:
    app: mysql
  ports:
  - port: 3306
    name: mysql
```

**StorageClass的选型直接决定性能上限。** 我用NFS跑压测，TPS只有本地磁盘的三分之一。换成Ceph RBD后才接近虚拟机水平，差距缩小到2%以内。NFS适合测试环境，生产环境用块存储。

## 国产数据库容器化：能替代MySQL跑在K8s上吗？

说实话，这次上手K8s让我意识到一件事：数据库容器化不是"能不能跑"的问题，是"怎么管好"的问题。传统数据库厂商都在做容器化适配。我了解到的情况是，国产数据库对K8s的支持也在快速推进。

KingbaseES在K8s上提供了KES Operator作为核心编排工具，每个租户拥有独立的数据库实例运行在独立Pod中，实现配置、数据与权限的全隔离。这套方案定位为微服务场景，适合一机多业务——单台物理服务器上通过K8s动态调度运行多个独立的数据库实例，实现资源池共享和利用率最大化。故障时Pod可自动漂移，保障业务连续性。搭配企业级管控平台还能统一管理多个容器数据库实例。

容器化的核心价值不是性能，而是运维效率。自动部署、自动扩容、自动故障恢复，这些对中小团队吸引力很大。读从库、开发测试环境、临时数据服务，适合先上容器。但核心交易系统我仍然建议谨慎。K8s的存储和网络层引入了额外的复杂度，出问题排查链路更长，你需要同时懂数据库和K8s。一机多业务的多租户场景确实有性价比，但核心库跑在容器上，一旦存储层或网络出问题，排查成本比传统虚拟机高得多。

## 容器化总结：MySQL上K8s到底值不值？

把MySQL搬上K8s，核心三件事：选StatefulSet不选Deployment、配好持久化存储、用Operator管主从。性能损失在可接受范围。运维效率提升明显。但排查问题的门槛也提高了。你需要同时理解MySQL和K8s的运维逻辑。

容器化不是银弹。它改变了数据库的部署方式，但没有改变数据库的运行原理。索引该建还是要建，慢查询该调还是要调。

你的团队有把数据库跑在容器上的吗？体验怎么样？欢迎一起交流。

我是数据库小学妹，咱们下篇见 👋

一家互联网公司做容器化改造，找我评估MySQL上K8s的可行性。聊完他们的场景，我给了一句结论："读从库和开发环境可以上，核心交易库先别动。"

云原生数据库实战：Kubernetes部署MySQL的完整流程与性能对比

把MySQL部署到Kubernetes容器平台上，从StatefulSet选型到持久化存储配置再到Operator管理，我记录了完整的上手过程和3个踩过的坑。

数据库

云计算

后端

MySQL上K8s可行但需谨慎：核心交易库建议保留虚拟机，读从库和开发环境可优先容器化。StatefulSet+持久化存储+Operator管理主从是关键，性能损耗5%-15%，运维效率提升但排查难度增加。NFS存储性能较差，生产环境推荐CephRBD或云盘。

负载均衡

代码解释

消息队列

存储性能

服务器

虚拟机

容器

MySQL

腾讯云数据库特惠，新用户首单0.5折起


2026上云采购 | AI焕新·智启新局

热销域名限时优惠，新客首年免费！


domain

DNS解析新购特惠59元起，续费优惠低至5.3折！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云原生数据库实战：Kubernetes部署MySQL的完整流程与性能对比-腾讯云开发者社区-腾讯云

云原生数据库实战：Kubernetes部署MySQL的完整流程与性能对比

云原生数据库实战：Kubernetes部署MySQL的完整流程与性能对比

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐