StatefulSet 必须用 headless Service，因其需稳定网络标识（如 mysql-0.mysql-headless.default.svc.cluster.local），而 headless Service（clusterIP: None）支持 DNS 直接解析各 Pod 的独立 A 记录，普通 ClusterIP 会负载均衡导致无法唯一寻址。
StatefulSet 为什么必须用 headless Service
这背后的核心逻辑在于网络标识的稳定性。StatefulSet 的设计精髓，就是为每个 Pod 提供一个持久且唯一的“身份证”，比如那个经典的域名格式：mysql-0.mysql-headless.default.svc.cluster.local。问题来了，普通的 ClusterIP 类型 Service 天生就是个“负载均衡器”，它会隐藏后端所有 Pod 的真实 IP，客户端访问的永远是一个虚拟 IP。这样一来，你想精准定位到 mysql-0 这个具体的 Pod，就完全不可能了。
而 headless Service（通过设置 clusterIP: None 实现）则走了另一条路：它放弃负载均衡，允许 Kubernetes 的 DNS 服务直接为每个 StatefulSet Pod 返回独立的 A 记录。这才是实现唯一网络寻址的关键。
实践中，一个非常典型的错误现象就是：mysql-0 这个 Pod 启动后反复重启，状态一直是 CrashLoopBackOff。查看日志，经常会发现 Can‘t find hostname mysql-0 或者 getaddrinfo failed 这类错误。遇到这种情况，十有八九是配套的 Service 没有配置成 headless 模式，或者 DNS 解析环节出了问题。
- 首要检查点：Service 配置里的
metadata.name，必须和 StatefulSet 定义中spec.serviceName字段的值一字不差。比如，两者都叫mysql-headless。 - 域名格式要记牢：
. . .svc.cluster.local - 最后，别忘了确认集群的 DNS 组件（如 CoreDNS）运行正常。执行命令
kubectl -n kube-system get pods -l k8s-app=kube-dns看一眼，心里就踏实了。
MySQL 实例间如何自动发现主从角色
这里有个重要的认知前提：StatefulSet 只负责提供稳定的身份和存储，它本身并不具备MySQL主从复制编排的智能。谁当主库，从库又该去连接谁，这些逻辑需要外部来实现。
最轻量、直接的做法，就是利用 StatefulSet 赋予 Pod 的稳定序号来约定规则。例如，我们可以硬性规定：序号为 0 的 Pod（即 mysql-0）就是主库，其他所有 Pod 都是从库。从库在启动脚本里，直接执行 CHANGE MASTER TO MASTER_HOST='mysql-0.mysql-headless' 即可。
然而，这种做法隐藏着一个大坑。想象一下，如果主库 mysql-0 所在的节点突然宕机，Kubernetes 会在其他节点上重建一个新的 mysql-0 Pod。虽然名字没变，但这个新 Pod 的数据是全新的，二进制日志位置和 GTID 集合都已重置。此时，从库依然尝试向这个“新主库”同步，就会抛出类似 Could not find first log file name in binary log index file 的错误，复制链路就此中断。
- 基础配置不能忘：主库必须启用
log-bin并设置server-id=1；从库则需要设置不同的server-id，可以利用环境变量$HOSTNAME的后缀来动态生成。 - 启动顺序有讲究：从库的启动脚本里，一定要加入对主库可用性的等待检查。简单依赖 Kubernetes 的 readinessProbe 可能不够，最好用
mysqladmin ping这样的命令进行轮询，确认主库的 MySQL 服务确实就绪了，再从库再进行连接。 - GTID 模式下的细节：如果使用 GTID 复制，从库首次启动执行
CHANGE MASTER后，先别急着START SLA VE。通常需要先执行SET GLOBAL gtid_purged = '...'来设置从主库获取到的已清除的 GTID 集合，否则复制会因 GTID 不连续而失败。
PVC 拓扑绑定失败导致 Pod 卡在 Pending
这是云环境下部署有状态服务时的一个经典陷阱。StatefulSet 的每个 Pod 都会绑定一个独立的 PersistentVolumeClaim。问题出在存储上：许多云服务商提供的块存储（如 AWS 的 EBS、Azure 的 Managed Disk）默认不支持跨可用区挂载。
假设这样一个场景：mysql-0 被调度到可用区 A，并成功绑定和挂载了该区的一块磁盘。随后，mysql-1 被调度器分配到了可用区 B。此时，为 mysql-1 创建的 PVC 会试图去绑定 mysql-0 所用的存储类，但该存储类在可用区 B 没有可用资源，或者策略禁止跨区挂载，导致 mysql-1 的 Pod 永远卡在 Pending 状态。
相关的错误信息通常类似于：Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data default-token-xxx]: timed out waiting for the condition。
- 关键配置：务必在 StorageClass 中设置
volumeBindingMode: WaitForFirstConsumer。这个设置能延迟 PVC 与 PV 的绑定，直到真正使用该 PVC 的 Pod 被调度到某个节点之后。这样，绑定操作就会发生在 Pod 所在的可用区，完美避免了跨区问题。 - 创建策略：保持 StatefulSet 的
podManagementPolicy为默认的OrderedReady。这种“顺序创建”的策略，本身就降低了多个 Pod 同时争抢跨区存储资源的风险。 - 拓扑匹配：检查集群节点的标签是否包含
topology.kubernetes.io/zone这类拓扑域标签，并确保 StorageClass 中allowedTopologies的配置与集群实际的可用区分布相匹配。
滚动更新时如何避免主从切换中断写入
StatefulSet 的默认滚动更新策略是按 Pod 序号逆序进行（从最高序号到最低序号）。对于 MySQL 主从集群，如果 mysql-0 是主库，它会在最后被更新，表面上看似乎很安全。
但真正的风险点不在于“更新能否完成”，而在于“更新期间业务写入是否会中断”。尤其是在应用直接连接 mysql-0 这个主库域名，而没有通过中间件进行读写分离和故障转移的场景下。在更新过程中，旧的主库 Pod 可能正在终止，而新的主库 Pod 尚未完成启动并准备好接收写入，这中间会出现一个不可写的空窗期。
- 主动锁定（适用于短时维护）：在触发更新前，可以手动连接到主库，执行
SET GLOBAL super_read_only=ON;并配合FLUSH TABLES WITH READ LOCK;来暂时锁定写入。请注意，这会影响业务，仅适合计划内的维护窗口。 - 就绪探针精细化：为 MySQL 容器配置的 readinessProbe，不能只检查端口通不通。应该让其执行一个 SQL 查询，比如检查
SELECT @@read_only。确保从库返回 1（只读），主库返回 0（可写）。这样可以防止流量在更新期间被误打到处于只读状态的实例上。 - 客户端要有韧性：应用的数据库连接池配置至关重要。确保开启了类似
autoReconnect=true的参数，并设置合理的连接超时和重试机制。业务端的容错能力，不能完全依赖 Kubernetes Endpoints 的刷新速度。
说到底，StatefulSet 提供的是基础设施层的稳定性：稳定的网络标识和持久的存储。但 MySQL 真正的高可用——包括主从自动切换、故障检测、数据一致性校验等——这些更上层的逻辑，还需要依靠额外的组件（如 Orchestrator、Vitess）或者精心设计的运维脚本来实现。指望一个 StatefulSet YAML 文件解决所有问题，是不现实的。
